Profiling Tapestry

Discussion:

Profiling Tapestry

Luis Neves

2002-02-19 15:38:54 UTC

I'm trying out the JProbe profiler suite using a Tapestry Application
( using a "net.sf.tapestry" filter) and it seems that Tapestry spends
most of the time sleeping :-) , see here:

<http://pwp.netcabo.pt/lneves/tapestry_Run.html>

The big offender seems to be the JanitorThread used by the Tapestry
Pool.
Does this make sense? I have no idea of how to interpret the
results... it seems that using a profiler is somekind of a black art.

Best regards,
Luis Neves

-------------------------------------------------------
This SF.NET email is sponsored by: Geek Gift Procrastinating?
Get the perfect geek gift now! Before the Holidays pass you by.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/

Luis Neves

2002-02-19 20:52:42 UTC

Permalink

I stopped measuring "Elapsed Time" and started measuring "CPU Time"
and the results are making more sense, also I pick a very simple page
(it's only a static page with a Tapestry BasePage associated) in order
do reduce the noise ,and because I've always been curious as to why
Tapestry works so hard with pages that are mostly static, I mean, no
matter how complex a page is, Tapestry always seems to do the same
effort.

It looks like what's keeping Tapestry down is the use of
PrintWriter.
See:

<http://pwp.netcabo.pt/lneves/tapestry_Run2.html>

I remember sometime ago reading a paper from Sun about servlet
performance where they conclude (among other things):

- Converting chars to bytes is *very slow*
- Always use OutputStream, never PrintWriter
- Store bytes, not characters

Ok ... I know ... This is probably preaching to the choir :-)
The paper is online:
<http://java.sun.com/javaone/javaone2001/pdfs/551.pdf>

The problem is of course that PrintWriter may very well be the only
thing available that Tapestry can use ... and in that case we are
screewed :-)

Best regards,
Luis Neves

----- Original Message -----
From: "Luis Neves" <lneves-***@public.gmane.org>
To: "Tapestry Contrib" <tapestry-contrib-5NWGOfrQmneRv+***@public.gmane.org>
Sent: Tuesday, February 19, 2002 3:38 PM
Subject: [Tapestry-contrib] Profiling Tapestry

Post by Luis Neves
I'm trying out the JProbe profiler suite using a Tapestry Application
( using a "net.sf.tapestry" filter) and it seems that Tapestry spends
<http://pwp.netcabo.pt/lneves/tapestry_Run.html>
The big offender seems to be the JanitorThread used by the Tapestry
Pool.
Does this make sense? I have no idea of how to interpret the
results... it seems that using a profiler is somekind of a black art.
Best regards,
Luis Neves
-------------------------------------------------------
This SF.NET email is sponsored by: Geek Gift Procrastinating?
Get the perfect geek gift now! Before the Holidays pass you by.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/
_______________________________________________
Tapestry-contrib mailing list
https://lists.sourceforge.net/lists/listinfo/tapestry-contrib

Mindbridge

2002-12-19 21:23:28 UTC

Permalink

Hi Luis,

May I ask what JDK you are using?

-mb

----- Original Message -----
From: "Luis Neves" <lneves-***@public.gmane.org>
To: "Tapestry Contrib" <tapestry-contrib-5NWGOfrQmneRv+***@public.gmane.org>
Sent: Tuesday, February 19, 2002 10:52 PM
Subject: Re: [Tapestry-contrib] Profiling Tapestry

Post by Luis Neves
I stopped measuring "Elapsed Time" and started measuring "CPU Time"
and the results are making more sense, also I pick a very simple page
(it's only a static page with a Tapestry BasePage associated) in order
do reduce the noise ,and because I've always been curious as to why
Tapestry works so hard with pages that are mostly static, I mean, no
matter how complex a page is, Tapestry always seems to do the same
effort.
It looks like what's keeping Tapestry down is the use of
PrintWriter.
<http://pwp.netcabo.pt/lneves/tapestry_Run2.html>
I remember sometime ago reading a paper from Sun about servlet
- Converting chars to bytes is *very slow*
- Always use OutputStream, never PrintWriter
- Store bytes, not characters
Ok ... I know ... This is probably preaching to the choir :-)
<http://java.sun.com/javaone/javaone2001/pdfs/551.pdf>
The problem is of course that PrintWriter may very well be the only
thing available that Tapestry can use ... and in that case we are
screewed :-)
Best regards,
Luis Neves
----- Original Message -----
Sent: Tuesday, February 19, 2002 3:38 PM
Subject: [Tapestry-contrib] Profiling Tapestry

-------------------------------------------------------
This SF.NET email is sponsored by: Geek Gift Procrastinating?
Get the perfect geek gift now! Before the Holidays pass you by.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/
_______________________________________________
Tapestry-contrib mailing list
https://lists.sourceforge.net/lists/listinfo/tapestry-contrib

Luis Neves

2002-02-19 21:46:57 UTC

Permalink

Sorry for not including up front that information.

I'm using Sun JDK 1.4.1_01 and JRockit8.0beta, on Windows2K and Linux
Red-Hat (AS) 2.1.
The results are similar no matter what OS/JDK combo used.

Best regards,
Luis Neves

----- Original Message -----
From: "Mindbridge" <mindbridgeweb-/***@public.gmane.org>
To: "Tapestry Contrib" <tapestry-contrib-5NWGOfrQmneRv+***@public.gmane.org>
Sent: Thursday, December 19, 2002 9:23 PM
Subject: Re: [Tapestry-contrib] Profiling Tapestry

Post by Mindbridge
Hi Luis,
May I ask what JDK you are using?
-mb

Howard M. Lewis Ship

2002-12-19 23:20:45 UTC

Permalink

Hm.

That might be an area to look into. Since all Tapestry output is run
through IMarkupWriter .... we don't absolutely have to base it on a
PrintWriter. Still, if we read templates as bytes, we'd have to do a lot of
our own conversion back to char just to parse the damn thing. I guess the
templates start as binary, convert to char, and convert back to binary on
the way to the browser.

How is this different than JSP? Most of the JSP implementations put the
template into strings and have endless out.print("....") statements.

----- Original Message -----
From: "Luis Neves" <lneves-***@public.gmane.org>
To: "Tapestry Contrib" <tapestry-contrib-5NWGOfrQmneRv+***@public.gmane.org>
Sent: Tuesday, February 19, 2002 3:52 PM
Subject: Re: [Tapestry-contrib] Profiling Tapestry

Luis Neves

2002-02-20 01:05:09 UTC

Permalink

On Thursday, December 19, 2002 11:20 PM,

Post by Howard M. Lewis Ship
Hm.
That might be an area to look into. Since all Tapestry output is run
through IMarkupWriter .... we don't absolutely have to base it on a
PrintWriter. Still, if we read templates as bytes, we'd have to do a lot of
our own conversion back to char just to parse the damn thing. I guess the
templates start as binary, convert to char, and convert back to binary on
the way to the browser.

How does XMLC solves the issue? They are doing
something similar to what Tapestry does, but more efficiently.

Post by Howard M. Lewis Ship
How is this different than JSP? Most of the JSP implementations put the
template into strings and have endless out.print("....") statements.

I am not sure that I understand you on this, but Resin doesn't do that.
Resin takes the template and does something like this:

jsp_string = "\r\n<HTML>\r\n<BODY>\r\n".getBytes();

and then writes the jsp_string to a OutputStream.

Best regards,
Luis Neves

-------------------------------------------------------
This SF.NET email is sponsored by: Geek Gift Procrastinating?
Get the perfect geek gift now! Before the Holidays pass you by.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/

Luis Neves

2002-12-20 10:10:25 UTC

Permalink

Post by Howard M. Lewis Ship
Hm.
That might be an area to look into. Since all Tapestry output is run
through IMarkupWriter .... we don't absolutely have to base it on a
PrintWriter. Still, if we read templates as bytes, we'd have to do a lot
of our own conversion back to char just to parse the damn thing. I guess
the templates start as binary, convert to char, and convert back to binary
on the way to the browser.

There is a new O'Reilly article that talks about "Servlet Best Practices" in
which the overhead of using PrintWriter is discussed and a solution is
presented:

http://www.onjava.com/lpt/a/2825

The case they talk about is just serving a file, and not doing much else with
it, so I don't know how usefull the article is for Tapestry, but a 50%
improvement[1] is kind of cool :-)

Best regards,
Luis Neves

[1] - in the best case

-------------------------------------------------------
This SF.NET email is sponsored by: The Best Geek Holiday Gifts!
Time is running out! Thinkgeek.com has the coolest gifts for
your favorite geek. Let your fingers do the typing. Visit Now.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/

Howard M. Lewis Ship

2002-12-20 11:33:26 UTC

Permalink

I agree with Marlcom; test under load in a real application. I'm fairly
confident that once you add any EJB or database access, the whole Tapestry
slice of the pie will become pretty thin.

I do think that, with enough work, we could do a lot less unicode-to-ascii
conversions. That is, template objects (RenderTemplateHTML instances) could
do the conversion just once and emit ascii-binary after that ... but its a
lot of work. I'd want to see that this conversion is really causing a
visible hotspot when the application is running under load.

----- Original Message -----
From: "Luis Neves" <lneves-***@public.gmane.org>
To: "Howard M. Lewis Ship" <hlship-***@public.gmane.org>; "Tapestry Contrib"
<tapestry-contrib-5NWGOfrQmneRv+***@public.gmane.org>
Sent: Friday, December 20, 2002 5:10 AM
Subject: Re: [Tapestry-contrib] Profiling Tapestry

Post by Howard M. Lewis Ship
Hm.
That might be an area to look into. Since all Tapestry output is run
through IMarkupWriter .... we don't absolutely have to base it on a
PrintWriter. Still, if we read templates as bytes, we'd have to do a lot
of our own conversion back to char just to parse the damn thing. I guess
the templates start as binary, convert to char, and convert back to binary
on the way to the browser.

There is a new O'Reilly article that talks about "Servlet Best Practices" in
which the overhead of using PrintWriter is discussed and a solution is
presented:

http://www.onjava.com/lpt/a/2825

The case they talk about is just serving a file, and not doing much else
with
it, so I don't know how usefull the article is for Tapestry, but a 50%
improvement[1] is kind of cool :-)

Best regards,
Luis Neves

[1] - in the best case

-------------------------------------------------------
This SF.NET email is sponsored by: The Best Geek Holiday Gifts!
Time is running out! Thinkgeek.com has the coolest gifts for
your favorite geek. Let your fingers do the typing. Visit Now.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/

Luis Neves

2002-12-20 12:35:11 UTC

Permalink

Post by Howard M. Lewis Ship
I agree with Marlcom; test under load in a real application. I'm fairly
confident that once you add any EJB or database access, the whole Tapestry
slice of the pie will become pretty thin.

I think you (and Malcom) are downplaying the impact of the web
presentation framework in the overall performance of an application,
which I think is a huge mistake.

I already tested Tapestry "real applications" under load, and I can
assure you that your confidence is misguided, Tapestry applications
absolutely collapse under load.
And not only in laboratory conditions, I see this every day at work.

We have an application (no EJB, simple database access) that people
use to book the lunch at the cafeteria (they browse the menu and make
a choice) and every day between 11:30-12:00 the web server CPU
get pegged at 100% trying to handle requests for about 3500 users,
while the database server just sits pretty with a 1.1 load average.
This didn't happened when the application was written in PHP, and
didn't happen when the application was written in JSP.

Post by Howard M. Lewis Ship
I do think that, with enough work, we could do a lot less unicode-to-ascii
conversions. That is, template objects (RenderTemplateHTML instances) could
do the conversion just once and emit ascii-binary after that ... but its a
lot of work. I'd want to see that this conversion is really causing a
visible hotspot when the application is running under load.

What proof do you need? ... I already profiled a Tapestry application
and "PrintWriter" appears to be the culprit and I showed you 2
articles that say that use of "PrintWriter" is do be avoided and that
char to byte conversions are slow.

Please don't get me wrong, I love Tapestry, I wouldn't want to use
anything else and I do understand that you have lots of other stuff in
your plate, but Tapestry does have a performance problem, and saying
that "EJB and database access" will eclipse that is just wishful
thinking.

Best regards,
Luis Neves

-------------------------------------------------------
This SF.NET email is sponsored by: The Best Geek Holiday Gifts!
Time is running out! Thinkgeek.com has the coolest gifts for
your favorite geek. Let your fingers do the typing. Visit Now.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/

Howard M. Lewis Ship

2002-12-20 13:23:22 UTC

Permalink

Again, I'm mystified that JSPs don't have the exact same problem. But it is
something to look into, for sure.

----- Original Message -----
From: "Luis Neves" <lneves-***@public.gmane.org>
To: "Tapestry Contrib" <tapestry-contrib-5NWGOfrQmneRv+***@public.gmane.org>
Sent: Friday, December 20, 2002 7:35 AM
Subject: Re: [Tapestry-contrib] Profiling Tapestry

Post by Luis Neves

I think you (and Malcom) are downplaying the impact of the web
presentation framework in the overall performance of an application,
which I think is a huge mistake.
I already tested Tapestry "real applications" under load, and I can
assure you that your confidence is misguided, Tapestry applications
absolutely collapse under load.
And not only in laboratory conditions, I see this every day at work.
We have an application (no EJB, simple database access) that people
use to book the lunch at the cafeteria (they browse the menu and make
a choice) and every day between 11:30-12:00 the web server CPU
get pegged at 100% trying to handle requests for about 3500 users,
while the database server just sits pretty with a 1.1 load average.
This didn't happened when the application was written in PHP, and
didn't happen when the application was written in JSP.

Post by Howard M. Lewis Ship
I do think that, with enough work, we could do a lot less

unicode-to-ascii

Post by Luis Neves

Post by Howard M. Lewis Ship
conversions. That is, template objects (RenderTemplateHTML instances)

could

Post by Howard M. Lewis Ship
do the conversion just once and emit ascii-binary after that ... but its a
lot of work. I'd want to see that this conversion is really causing a
visible hotspot when the application is running under load.

What proof do you need? ... I already profiled a Tapestry application
and "PrintWriter" appears to be the culprit and I showed you 2
articles that say that use of "PrintWriter" is do be avoided and that
char to byte conversions are slow.
Please don't get me wrong, I love Tapestry, I wouldn't want to use
anything else and I do understand that you have lots of other stuff in
your plate, but Tapestry does have a performance problem, and saying
that "EJB and database access" will eclipse that is just wishful
thinking.
Best regards,
Luis Neves
-------------------------------------------------------
This SF.NET email is sponsored by: The Best Geek Holiday Gifts!
Time is running out! Thinkgeek.com has the coolest gifts for
your favorite geek. Let your fingers do the typing. Visit Now.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/
_______________________________________________
Tapestry-contrib mailing list
https://lists.sourceforge.net/lists/listinfo/tapestry-contrib

-------------------------------------------------------
This SF.NET email is sponsored by: The Best Geek Holiday Gifts!
Time is running out! Thinkgeek.com has the coolest gifts for
your favorite geek. Let your fingers do the typing. Visit Now.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/

Howard M. Lewis Ship

2002-12-20 13:44:55 UTC

Permalink

This may also mandate that Tapestry only support utf-8 as a character
encoding.

----- Original Message -----
From: "Luis Neves" <lneves-***@public.gmane.org>
To: "Tapestry Contrib" <tapestry-contrib-5NWGOfrQmneRv+***@public.gmane.org>
Sent: Friday, December 20, 2002 7:35 AM
Subject: Re: [Tapestry-contrib] Profiling Tapestry

Post by Luis Neves

I think you (and Malcom) are downplaying the impact of the web
presentation framework in the overall performance of an application,
which I think is a huge mistake.
I already tested Tapestry "real applications" under load, and I can
assure you that your confidence is misguided, Tapestry applications
absolutely collapse under load.
And not only in laboratory conditions, I see this every day at work.
We have an application (no EJB, simple database access) that people
use to book the lunch at the cafeteria (they browse the menu and make
a choice) and every day between 11:30-12:00 the web server CPU
get pegged at 100% trying to handle requests for about 3500 users,
while the database server just sits pretty with a 1.1 load average.
This didn't happened when the application was written in PHP, and
didn't happen when the application was written in JSP.

Post by Howard M. Lewis Ship
I do think that, with enough work, we could do a lot less

unicode-to-ascii

Post by Luis Neves

Post by Howard M. Lewis Ship
conversions. That is, template objects (RenderTemplateHTML instances)

could

What proof do you need? ... I already profiled a Tapestry application
and "PrintWriter" appears to be the culprit and I showed you 2
articles that say that use of "PrintWriter" is do be avoided and that
char to byte conversions are slow.
Please don't get me wrong, I love Tapestry, I wouldn't want to use
anything else and I do understand that you have lots of other stuff in
your plate, but Tapestry does have a performance problem, and saying
that "EJB and database access" will eclipse that is just wishful
thinking.
Best regards,
Luis Neves
-------------------------------------------------------
This SF.NET email is sponsored by: The Best Geek Holiday Gifts!
Time is running out! Thinkgeek.com has the coolest gifts for
your favorite geek. Let your fingers do the typing. Visit Now.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/
_______________________________________________
Tapestry-contrib mailing list
https://lists.sourceforge.net/lists/listinfo/tapestry-contrib

Luis Neves

2002-12-20 15:26:03 UTC

Permalink

Post by Howard M. Lewis Ship
This may also mandate that Tapestry only support utf-8 as a character
encoding.

That would be bad.
I'm looking at the Resin source under com.caucho.vfs for ideias and
they seem to handle most of the difficult stuff, but java.io.* is not
my cup of tea.

Can you give us an overview of the Tapestry IO process?
I really don't know much about Tapestry guts.
There could be other ideias worth exploring, like DOM parsers for
example.

Best regards,
Luis Neves

-------------------------------------------------------
This SF.NET email is sponsored by: The Best Geek Holiday Gifts!
Time is running out! Thinkgeek.com has the coolest gifts for
your favorite geek. Let your fingers do the typing. Visit Now.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/

Malcolm Edgar

2002-12-20 00:21:28 UTC

Permalink

I have been involved is performance profiling and stress testing of Servlet
web applications. What we found was:

* when your app is running well, most of the CPU time will be spent
in the Servlet container code

* performance problems generally can only be identified
when under server is under a significant load

this is not an easy thing to achieve, you will need your server
getting hammered by a number of client machines running test
robots. Also be aware of the 10 TCP/IP client limit of
Windows NT Professional and Windows 2000 Professional

* take a look at the number of Object instances created to make sure
you are not doing anything silly

regards Malcolm

Post by Mindbridge
Subject: Re: [Tapestry-contrib] Profiling Tapestry
Date: Thu, 19 Dec 2002 18:20:45 -0500
Hm.
That might be an area to look into. Since all Tapestry output is run
through IMarkupWriter .... we don't absolutely have to base it on a
PrintWriter. Still, if we read templates as bytes, we'd have to do a lot
of
our own conversion back to char just to parse the damn thing. I guess the
templates start as binary, convert to char, and convert back to binary on
the way to the browser.
How is this different than JSP? Most of the JSP implementations put the
template into strings and have endless out.print("....") statements.
----- Original Message -----
Sent: Tuesday, February 19, 2002 3:52 PM
Subject: Re: [Tapestry-contrib] Profiling Tapestry

_________________________________________________________________
MSN 8 with e-mail virus protection service: 3 months FREE*.
http://join.msn.com/?page=features/virus&xAPID=42&PS=47575&PI=7324&DI=7474&SU=
http://www.hotmail.msn.com/cgi-bin/getmsg&HL=1216hotmailtaglines_eliminateviruses_3mf

-------------------------------------------------------
This SF.NET email is sponsored by: Geek Gift Procrastinating?
Get the perfect geek gift now! Before the Holidays pass you by.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/

Malcolm Edgar

2002-12-21 02:20:55 UTC

Permalink

I am not arguing that Tapestry doesn't have a performance problem under high
loads. I dont know, I am developing for Intranet environment.

I do vaguely remember someone, who wrote Sun PetStore in Tapestry and said
it hit a bit brick wall under heavy loads. Whether this was Tapestry, a poor
implementation or a database issue I don't know.

What I can tell you about my experience which was Servlet/JSP MVC style
application with an in-memory database cache.

Server: 500MB, 2 CPU, NT Server, Tomcat 3.3, JDK 1.2.x
Clients: 4-5 clients running MS WebStress Test.

1. a single call System.gc() - was crippling performance, with this
removed we saw a 10x improvement

2. a single string concatenation tight CORBA message processing loop,
occupied 1 CPU at 100% utilization

3. excessive number of client request handling CORBA threads impacted
performance (3 was optimal number)

4. replacing Vectors with ArrayLists in a HTML Table object, saw a
100% performance improvement. While this code as suspected of
causing problems, it was only detectable under heavy multi-threaded
loads

4. using CSS classes in HTML pages instead of specifing fonts
in table cells significantly improved render times, some 30-50%

5. replacing LinkedList with a ArrayList in a cached ResultSet gave
a significant performance improvement, LinkedList sequential
access really hurt

5. excessively board synchonization causes some nasty blocking

6. Moving from JDK 1.2.x to 1.3 saw a 100% performance improvement

Tapestry is unusual in that it pools pages which are quite heavy weight
objects. JSP/Servlets have a relatively short rendering pipeline, which good
for performance, but can't handle a complex design space well as Tapestry
can. With this page pooling code there could be potential for performance
issues, with synchronization, blocking and object allocation / memory churn.

From the code I have seen Howard write it is exceptionally good

(significantly better than mine), with very good attention to detail on
these issues.

There was a good article on TSS recently with regard to Borland BES
performance. Borland were using JStore as the database, because Oracles JDBC
driver was doing rediculous amounts over memory allocation and they could
identify there own performance issues with this JDBC driver in the same JVM.

This is not trivial stuff, but it is very good to do.

regards Malcolm

Subject: Re: [Tapestry-contrib] Profiling Tapestry
Date: Fri, 20 Dec 2002 15:26:03 -0000

Post by Howard M. Lewis Ship
This may also mandate that Tapestry only support utf-8 as a character
encoding.

That would be bad.
I'm looking at the Resin source under com.caucho.vfs for ideias and
they seem to handle most of the difficult stuff, but java.io.* is not
my cup of tea.
Can you give us an overview of the Tapestry IO process?
I really don't know much about Tapestry guts.
There could be other ideias worth exploring, like DOM parsers for
example.
Best regards,
Luis Neves
-------------------------------------------------------
This SF.NET email is sponsored by: The Best Geek Holiday Gifts!
Time is running out! Thinkgeek.com has the coolest gifts for
your favorite geek. Let your fingers do the typing. Visit Now.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/
_______________________________________________
Tapestry-contrib mailing list
https://lists.sourceforge.net/lists/listinfo/tapestry-contrib

_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 3 months FREE*.
http://join.msn.com/?page=features/virus&xAPID=42&PS=47575&PI=7324&DI=7474&SU=
http://www.hotmail.msn.com/cgi-bin/getmsg&HL=1216hotmailtaglines_virusprotection_3mf

-------------------------------------------------------
This SF.NET email is sponsored by: The Best Geek Holiday Gifts!
Time is running out! Thinkgeek.com has the coolest gifts for
your favorite geek. Let your fingers do the typing. Visit Now.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/

Malcolm Edgar

2002-12-21 02:22:21 UTC

Permalink

I am not arguing that Tapestry doesn't have a performance problem under high
loads. I dont know, I am developing for an Intranet environment with a small
number of users.

I do vaguely remember someone, who wrote Sun PetStore in Tapestry and said
it hit a bit brick wall under heavy loads. Whether this was Tapestry, a poor
implementation or a database issue I don't know.

What I can tell you about my experience which was Servlet/JSP MVC style
application with an in-memory database cache.

Server: 500MB, 2 CPU, NT Server, Tomcat 3.3, JDK 1.2.x
Clients: 4-5 clients running MS WebStress Test.

1. a single call System.gc() - was crippling performance, with this
removed we saw a 10x improvement

2. a single string concatenation tight CORBA message processing loop,
occupied 1 CPU at 100% utilization

3. excessive number of client request handling CORBA threads impacted
performance (3 was optimal number)

4. replacing Vectors with ArrayLists in a HTML Table object, saw a
100% performance improvement. While this code as suspected of
causing problems, it was only detectable under heavy multi-threaded
loads

4. using CSS classes in HTML pages instead of specifing fonts
in table cells significantly improved render times, some 30-50%

5. replacing LinkedList with a ArrayList in a cached ResultSet gave
a significant performance improvement, LinkedList sequential
access really hurt

5. excessively board synchonization causes some nasty blocking

6. Moving from JDK 1.2.x to 1.3 saw a 100% performance improvement

Tapestry is unusual in that it pools pages which are quite heavy weight
objects. JSP/Servlets have a relatively short rendering pipeline, which good
for performance, but can't handle a complex design space well as Tapestry
can. With this page pooling code there could be potential for performance
issues, with synchronization, blocking and object allocation / memory churn.

From the code I have seen Howard write it is exceptionally good

Subject: Re: [Tapestry-contrib] Profiling Tapestry
Date: Fri, 20 Dec 2002 15:26:03 -0000

Post by Howard M. Lewis Ship
This may also mandate that Tapestry only support utf-8 as a character
encoding.

That would be bad.
I'm looking at the Resin source under com.caucho.vfs for ideias and
they seem to handle most of the difficult stuff, but java.io.* is not
my cup of tea.
Can you give us an overview of the Tapestry IO process?
I really don't know much about Tapestry guts.
There could be other ideias worth exploring, like DOM parsers for
example.
Best regards,
Luis Neves
-------------------------------------------------------
This SF.NET email is sponsored by: The Best Geek Holiday Gifts!
Time is running out! Thinkgeek.com has the coolest gifts for
your favorite geek. Let your fingers do the typing. Visit Now.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/
_______________________________________________
Tapestry-contrib mailing list
https://lists.sourceforge.net/lists/listinfo/tapestry-contrib

Malcolm Edgar

2002-12-21 07:05:16 UTC

Permalink

One other thing I remember about this profiling stuff, was that sorting of
International strings non-UTF-8 in Java (1.2) was really slow, much better
doing it in the database. The default (en) Locale string comparitor however
was really fast.

The application we were working of was a CRM reporting app, rendering lots
of very large tables, with high update rates. A couple of things we looked
at to improve performance, but didn't use included:

1. Compressing the HTML content, like you can to today with Servlet
2.3 API filters. This actually improved response time in a LAN
environment which was surprising. Our table content generally
compressed down 90-95%

2. Sending XML and XSL straight to the browser, and have it do the
transformation and rendering. This is a IE 5.0 feature, you use
some special IE features to do client side sorting, I think this
was with HTC's.

Regards Malcolm

Post by Mindbridge
Subject: Re: [Tapestry-contrib] Profiling Tapestry
Date: Fri, 20 Dec 2002 15:26:03 -0000

Post by Howard M. Lewis Ship
This may also mandate that Tapestry only support utf-8 as a character
encoding.

That would be bad.
I'm looking at the Resin source under com.caucho.vfs for ideias and
they seem to handle most of the difficult stuff, but java.io.* is not
my cup of tea.
Can you give us an overview of the Tapestry IO process?
I really don't know much about Tapestry guts.
There could be other ideias worth exploring, like DOM parsers for
example.
Best regards,
Luis Neves
-------------------------------------------------------
This SF.NET email is sponsored by: The Best Geek Holiday Gifts!
Time is running out! Thinkgeek.com has the coolest gifts for
your favorite geek. Let your fingers do the typing. Visit Now.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/
_______________________________________________
Tapestry-contrib mailing list
https://lists.sourceforge.net/lists/listinfo/tapestry-contrib

_________________________________________________________________
The new MSN 8: smart spam protection and 3 months FREE*.
http://join.msn.com/?page=features/junkmail&xAPID=42&PS=47575&PI=7324&DI=7474&SU=
http://www.hotmail.msn.com/cgi-bin/getmsg&HL=1216hotmailtaglines_smartspamprotection_3mf

-------------------------------------------------------
This SF.NET email is sponsored by: The Best Geek Holiday Gifts!
Time is running out! Thinkgeek.com has the coolest gifts for
your favorite geek. Let your fingers do the typing. Visit Now.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/