wicket-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bertrand Guay-Paquet <ber...@step.polymtl.ca>
Subject Re: Performance optimization
Date Thu, 23 Feb 2012 15:40:05 GMT
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
> <bernie@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-unsubscribe@wicket.apache.org
>>
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Mime
View raw message