Hi All, We are using Wicket to develop our web application product (QuickBuild) for six years, and this makes our life a lot easier when comes to maintain our code base due to Wicket's component approach and type safe nature of Java.
As our product gets more used in companies, it is not uncommon that thousands of users are accessing the application concurrently, and at peak time the server sometimes gets stressed to have slow response time. Our benchmark shows that offen the server is busy serializing pages. This is not strange as our application uses ajax heavily and every ajax call to the server triggers the page store to persist (serialize and write) the whole page on disk. To my understanding, Wicket serializes/saves stateful pages for purpose of back button support. At commit stage of every request, all touched pages will be put into session cache, and also get persisted via page store. This mechanism works but results in a lot of unnecessary page persistence. To explain it, assume below workflow: 1. User loads the stateful page and wicket creates a page instance to put in session cache, as well as persist to disk. 2. User clicks some action links (either ajax or non-ajax) subsequently to update parts of the page, but still remains in the same page instance, and the url displayed in browser remains unchanged. For every request, Wicket updates the page instance, put it into session cache, and finally persist it to disk. 3. User clicks some other links to cause new page instance being created, and Wicket does the same to put new instance in session cache and persist the new instance. Here in step 2, page persistence seems unnecessary to me except for the last request. That is to say, if a page instance is touched by many requests before switching to a different page instance, only the last touch has to persist the instance. This is because when user goes back to previous page instance, only the last saved state of that instance will be used. Based on this assumption, I modified method "storeTouchedPages" of PageStoreManager.java to compare ids of previous page instances (stored in session cache) and touched page instances. If they are different, persist the previous page instances. I tested the modification with several cases of page refreshing/backing and it seems that they all work correctly. Although I used Wicket for some time, I seldomly digged into Wicket internals. So probably I have missed some important factors when assuming above. Can someone here take a look at attached modification and kindly let me know if this is meaningful? Thanks Robin
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
