Re: Should/Could ServletWebRequest.isAjax be cached?
On Mon, 03 Nov 2008, Martin Makundi wrote: > Not really, I have large chunks (containers.. actually a ListView...). OK, it doesn't look like it's that then. > Can you be more specific about this? In what context should the > parsing results be cached? Look at where IMarkupSettings.getMarkupCache() is being called. It seems that whenever a MarkupContainer is looking for its associated markup, it's using the markup cache, which in turn returns Markup objects that are already parsed markup. > You could try ajax-updating a large web page, say having a table with > 2000+ rows, and profile it. Do the results look ok for you? It would be good if you could provide a minimal quickstart on which you can reproduce this. Also, 2000+ rows in a table on a web page does not sound like very handy to me :) > I will have a look, but I am not yet very familiar with Wicket > internals... the 'what should be''s and nots Me neither, but luckily it's open source :) Best wishes, Timo -- Timo Rantalaiho Reaktor Innovations Oyhttp://www.ri.fi/ > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Should/Could ServletWebRequest.isAjax be cached?
I tried in deployment mode... no significant difference in the load distribution. ** Martin 2008/11/3 James Carman <[EMAIL PROTECTED]>: > On Mon, Nov 3, 2008 at 12:17 AM, Martin Makundi > <[EMAIL PROTECTED]> wrote: >> Can you be more specific about this? In what context should the >> parsing results be cached? >> > > Are you running in deployment or development mode? I would try your > profiling in deployment mode to see how that helps. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Should/Could ServletWebRequest.isAjax be cached?
On Mon, Nov 3, 2008 at 12:17 AM, Martin Makundi <[EMAIL PROTECTED]> wrote: > Can you be more specific about this? In what context should the > parsing results be cached? > Are you running in deployment or development mode? I would try your profiling in deployment mode to see how that helps. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Should/Could ServletWebRequest.isAjax be cached?
>> So, some streamlining might be in order there, even after this particular >> issue. > > Do you have a lot of Ajax updates of small components without > their own markup? > https://issues.apache.org/jira/browse/WICKET-1857 > might be hitting you as well and it would be interesting to > see if your problem still occurs on trunk (or 1.4-RC1). Not really, I have large chunks (containers.. actually a ListView...). I had a look at the debug output and there is one "DEBUG - MarkupCache- Markup not found: org.apache.wicket.markup.html.form.Formfi_FIhtml" and some "DEBUG - ResourceStreamLocator - Attempting to locate resource 'org/apache/wicket/markup/html/form/Form_fi_FI.html' on" or similar Most of the lines in the debug log consist of: "DEBUG - MarkupContainer- Rendering raw markup" and "DEBUG - Component - Begin render [MarkupContainer [Component id =xx" > The actual parsing results should be cached by IMarkupCache > as far as I know, so if the parsing is really the issue you > could try finding out why is the cache not working (and/or > provide a reproduceable test case in a quickstart). Can you be more specific about this? In what context should the parsing results be cached? You could try ajax-updating a large web page, say having a table with 2000+ rows, and profile it. Do the results look ok for you? I will have a look, but I am not yet very familiar with Wicket internals... the 'what should be''s and nots ** Martin > > -- > Timo Rantalaiho > Reaktor Innovations Oyhttp://www.ri.fi/ > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Should/Could ServletWebRequest.isAjax be cached?
On Sun, 02 Nov 2008, Martin Makundi wrote: > The profiler shows that for a (large) page, 40% of the effort (20 > seconds per such particular page) goes into just parsing the tags and > does not seem to process any logic. > > So, some streamlining might be in order there, even after this particular > issue. Do you have a lot of Ajax updates of small components without their own markup? If that is the case, then this issue https://issues.apache.org/jira/browse/WICKET-1857 might be hitting you as well and it would be interesting to see if your problem still occurs on trunk (or 1.4-RC1). The actual parsing results should be cached by IMarkupCache as far as I know, so if the parsing is really the issue you could try finding out why is the cache not working (and/or provide a reproduceable test case in a quickstart). Best wishes, Timo -- Timo Rantalaiho Reaktor Innovations Oyhttp://www.ri.fi/ > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Should/Could ServletWebRequest.isAjax be cached?
The profiler shows that for a (large) page, 40% of the effort (20
seconds per such particular page) goes into just parsing the tags and
does not seem to process any logic.
So, some streamlining might be in order there, even after this particular issue.
Jira issue created with attached profiler screenshot:
https://issues.apache.org/jira/browse/WICKET-1910
**
Martin
2008/11/1 Matej Knopp <[EMAIL PROTECTED]>:
> Sure this is valid but i can't imagine why this would be a bottleneck.
> Unless the webserver does something very weird while retrieving the
> header.
>
> -Matej
>
> On Sat, Nov 1, 2008 at 6:01 PM, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
>> looks good, please create a jira issue.
>>
>> -igor
>>
>> On Sat, Nov 1, 2008 at 5:11 AM, Martin Makundi
>> <[EMAIL PROTECTED]> wrote:
>>> Hi!
>>>
>>> I was profiling my Wicket application and noticed that Jetty's
>>> getHeader method was hit quite often.
>>>
>>> It turns out the ServletWebRequest.isAjax method is hit quite often by
>>> each of the page elements (I am generating a large HTML report page).
>>> Since the Servlet container may not have optimal design for processing
>>> the getHeader method, I wonder if the ServletWebRequest.isAjax -method
>>> could/should be cached within wicket.
>>>
>>> I made the following modification to the ServletWebRequest.isAjax
>>> method, and measured a notable increase in performance:
>>>
>>> public boolean isAjax() {
>>>if (ajax == null) {
>>> ajax = false;
>>>
>>> String ajaxHeader = httpServletRequest.getHeader("Wicket-Ajax");
>>> if (Strings.isEmpty(ajaxHeader) == false)
>>> {
>>>try
>>>{
>>> ajax = Strings.isTrue(ajaxHeader);
>>>}
>>>catch (StringValueConversionException e)
>>>{
>>> // We are not interested in this exception but we log it anyway
>>> log.debug("Couldn't convert the Wicket-Ajax header: " +
>>> ajaxHeader);
>>>}
>>> }
>>>}
>>>
>>>return ajax;
>>> }
>>>
>>>
>>> However, my question remains: is this a valid optimization or does it
>>> break the Wicket framework? Should it somehow be incorporated in the
>>> next releases?
>>>
>>> **
>>> Martin
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Should/Could ServletWebRequest.isAjax be cached?
Sure this is valid but i can't imagine why this would be a bottleneck.
Unless the webserver does something very weird while retrieving the
header.
-Matej
On Sat, Nov 1, 2008 at 6:01 PM, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> looks good, please create a jira issue.
>
> -igor
>
> On Sat, Nov 1, 2008 at 5:11 AM, Martin Makundi
> <[EMAIL PROTECTED]> wrote:
>> Hi!
>>
>> I was profiling my Wicket application and noticed that Jetty's
>> getHeader method was hit quite often.
>>
>> It turns out the ServletWebRequest.isAjax method is hit quite often by
>> each of the page elements (I am generating a large HTML report page).
>> Since the Servlet container may not have optimal design for processing
>> the getHeader method, I wonder if the ServletWebRequest.isAjax -method
>> could/should be cached within wicket.
>>
>> I made the following modification to the ServletWebRequest.isAjax
>> method, and measured a notable increase in performance:
>>
>> public boolean isAjax() {
>>if (ajax == null) {
>> ajax = false;
>>
>> String ajaxHeader = httpServletRequest.getHeader("Wicket-Ajax");
>> if (Strings.isEmpty(ajaxHeader) == false)
>> {
>>try
>>{
>> ajax = Strings.isTrue(ajaxHeader);
>>}
>>catch (StringValueConversionException e)
>>{
>> // We are not interested in this exception but we log it anyway
>> log.debug("Couldn't convert the Wicket-Ajax header: " + ajaxHeader);
>>}
>> }
>>}
>>
>>return ajax;
>> }
>>
>>
>> However, my question remains: is this a valid optimization or does it
>> break the Wicket framework? Should it somehow be incorporated in the
>> next releases?
>>
>> **
>> Martin
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Should/Could ServletWebRequest.isAjax be cached?
looks good, please create a jira issue.
-igor
On Sat, Nov 1, 2008 at 5:11 AM, Martin Makundi
<[EMAIL PROTECTED]> wrote:
> Hi!
>
> I was profiling my Wicket application and noticed that Jetty's
> getHeader method was hit quite often.
>
> It turns out the ServletWebRequest.isAjax method is hit quite often by
> each of the page elements (I am generating a large HTML report page).
> Since the Servlet container may not have optimal design for processing
> the getHeader method, I wonder if the ServletWebRequest.isAjax -method
> could/should be cached within wicket.
>
> I made the following modification to the ServletWebRequest.isAjax
> method, and measured a notable increase in performance:
>
> public boolean isAjax() {
>if (ajax == null) {
> ajax = false;
>
> String ajaxHeader = httpServletRequest.getHeader("Wicket-Ajax");
> if (Strings.isEmpty(ajaxHeader) == false)
> {
>try
>{
> ajax = Strings.isTrue(ajaxHeader);
>}
>catch (StringValueConversionException e)
>{
> // We are not interested in this exception but we log it anyway
> log.debug("Couldn't convert the Wicket-Ajax header: " + ajaxHeader);
>}
> }
>}
>
>return ajax;
> }
>
>
> However, my question remains: is this a valid optimization or does it
> break the Wicket framework? Should it somehow be incorporated in the
> next releases?
>
> **
> Martin
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Should/Could ServletWebRequest.isAjax be cached?
Hi!
I was profiling my Wicket application and noticed that Jetty's
getHeader method was hit quite often.
It turns out the ServletWebRequest.isAjax method is hit quite often by
each of the page elements (I am generating a large HTML report page).
Since the Servlet container may not have optimal design for processing
the getHeader method, I wonder if the ServletWebRequest.isAjax -method
could/should be cached within wicket.
I made the following modification to the ServletWebRequest.isAjax
method, and measured a notable increase in performance:
public boolean isAjax() {
if (ajax == null) {
ajax = false;
String ajaxHeader = httpServletRequest.getHeader("Wicket-Ajax");
if (Strings.isEmpty(ajaxHeader) == false)
{
try
{
ajax = Strings.isTrue(ajaxHeader);
}
catch (StringValueConversionException e)
{
// We are not interested in this exception but we log it anyway
log.debug("Couldn't convert the Wicket-Ajax header: " + ajaxHeader);
}
}
}
return ajax;
}
However, my question remains: is this a valid optimization or does it
break the Wicket framework? Should it somehow be incorporated in the
next releases?
**
Martin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
