wicket-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robin Shine <ro...@pmease.com>
Subject Possible optimization of page store manager
Date Tue, 11 Jun 2013 10:23:29 GMT
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

Mime
View raw message