Indeed, flush-before-detach (WICKET-6831) was a huge performance
improvement.
Sven
On 11.11.21 08:55, Korbinian Bachl wrote:
Hi Sven,
thanks a lot!
I've looked into that GaePageManagerProvider and adapted it myself. However,
during test I somehow observed that the reason why I did use the HTTPSession
store some long time ago (wicket 1.5/6?) doesn't seem to be existing anymore.
Reason was that the underlying storage of our prod server has the typical small
cloud latency. Now with wicket 9 all doing async I didnt see any benefit after
all with having or not having the custom provider. I even suspect the
HTTPSession solution to be a tad slower (1 to 10ms) from observation, but cant
really pinpoint it down.
Its really nice to see how good wicket got here so that speed is quite well
without the need for custom optimisation.
If you have any idea how to even speed things more up I'm always happy to hear
;)
Best,
KB
----- Ursprüngliche Mail -----
Von: "Sven Meier" <s...@meiers.net>
An: "users" <users@wicket.apache.org>
Gesendet: Mittwoch, 10. November 2021 20:31:52
Betreff: Re: migration from wicket 8 to 9 -> PageManagerProvider
Hi Korbinian,
it was a real breeze. I'm very impressed!
thanks, glad to hear that.
You application is persisting pages in the Http session instead of disk.
Essentially what the wicketstuff's gae-initializer does too:
https://github.com/wicketstuff/core/blob/master/gae-initializer-parent/gae-initializer/src/main/java/org/wicketstuff/gae/GaePageManagerProvider.java
InsessionPageStore has a maxBytes constructor too.
Watch out for the override of the #getKey() method - I'm not happy with
that, but your question triggers me to look into that once again.
Have fun
Sven
On 10.11.21 12:05, Korbinian Bachl wrote:
Hi,
Im currently migrating our applications from wicket 8 to wicket 9.6 and so far
it was a real breeze. I'm very impressed!
One thing however that puzzles me is the following code I had in the application
init();
setPageManagerProvider(new DefaultPageManagerProvider(this) {
protected IDataStore newDataStore() {
return new HttpSessionDataStore(getPageManagerContext(),
new MemorySizeEvictionStrategy(Bytes.megabytes(24)));
}
});
getStoreSettings().setInmemoryCacheSize(0);
I honestly dont know from when this originated but I had to disable it as it
doesnt seem to exist anymore accorting to the migration guide.
So I just let de default settings now apply. The original solution was aimed at
maximum page delivery speed and didnt care much about RAM as we got plenty of
it. Any idea if I should let the default or can I squeeze out some milliseconds
by going pure in memory again?
Best,
KB
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
