You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Martin Makundi <ma...@koodaripalvelut.com> on 2008/11/01 13:11:51 UTC
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
Re: Should/Could ServletWebRequest.isAjax be cached?
Posted by Martin Makundi <ma...@koodaripalvelut.com>.
I tried in deployment mode... no significant difference in the load
distribution.
**
Martin
2008/11/3 James Carman <ja...@carmanconsulting.com>:
> On Mon, Nov 3, 2008 at 12:17 AM, Martin Makundi
> <ma...@koodaripalvelut.com> 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: 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
Re: Should/Could ServletWebRequest.isAjax be cached?
Posted by James Carman <ja...@carmanconsulting.com>.
On Mon, Nov 3, 2008 at 12:17 AM, Martin Makundi
<ma...@koodaripalvelut.com> 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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Should/Could ServletWebRequest.isAjax be cached?
Posted by Timo Rantalaiho <Ti...@ri.fi>.
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 Oy <URL: http://www.ri.fi/ >
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Should/Could ServletWebRequest.isAjax be cached?
Posted by Martin Makundi <ma...@koodaripalvelut.com>.
>> 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 Oy <URL: http://www.ri.fi/ >
>
> ---------------------------------------------------------------------
> 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
Re: Should/Could ServletWebRequest.isAjax be cached?
Posted by Timo Rantalaiho <Ti...@ri.fi>.
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 Oy <URL: http://www.ri.fi/ >
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Should/Could ServletWebRequest.isAjax be cached?
Posted by Martin Makundi <ma...@koodaripalvelut.com>.
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 <ma...@gmail.com>:
> 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 <ig...@gmail.com> wrote:
>> looks good, please create a jira issue.
>>
>> -igor
>>
>> On Sat, Nov 1, 2008 at 5:11 AM, Martin Makundi
>> <ma...@koodaripalvelut.com> 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: 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
>>
>>
>
> ---------------------------------------------------------------------
> 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
Re: Should/Could ServletWebRequest.isAjax be cached?
Posted by Matej Knopp <ma...@gmail.com>.
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 <ig...@gmail.com> wrote:
> looks good, please create a jira issue.
>
> -igor
>
> On Sat, Nov 1, 2008 at 5:11 AM, Martin Makundi
> <ma...@koodaripalvelut.com> 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: 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Should/Could ServletWebRequest.isAjax be cached?
Posted by Igor Vaynberg <ig...@gmail.com>.
looks good, please create a jira issue.
-igor
On Sat, Nov 1, 2008 at 5:11 AM, Martin Makundi
<ma...@koodaripalvelut.com> 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: 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