Even if it is asynchronous, it uses up some of the total IO capacity of the server. Reading the bytes back when the page is requested again is however a synchronous operation and it depends on IO.

Anyway, if profiling shows that the slow part is the serialize call, then zipping won't help.

If all else fails, you can also write custom components that generate the HTML of each table row directly instead of using thousands of labels.

On 23/02/2012 10:05 AM, Martin Grigorov wrote:
On Thu, Feb 23, 2012 at 3:55 PM, Bertrand Guay-Paquet
<ber...@step.polymtl.ca>  wrote:
First of all, you stated that your problem what that the serialized size was
too big, so please don't be so rude.

Now, are you sure that the slow part of serialization is not the IO for
storing that 10MB? If it is, zipping the page could definitely improve
performance, even if it takes a some CPU time to do the operation.
Storing of the bytes in the disk is asynchronous by default.

Bertrand


On 23/02/2012 12:04 AM, Martin Makundi wrote:
The problem is that the SERIALIZATION takes time. So it does not help to
ZIP AFTER serialization...
I have debugged it and it's just thousands and thousands of components.
  Even printing the component paths alone take almost 10mb or more because
there is repetition ;)
**
Martin

---------------------------------------------------------------------
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

Reply via email to