Cheers Bryan, I'm searching the archives now... Rob Cole
"Bryan Lewis" <[EMAIL PROTECTED]>
01/08/2005 14:38
To
"Tapestry users" <[email protected]>
cc
Please respond to
"Tapestry users" <[email protected]>
Subject
Re: Tapestry fails performance testing. HELP!
I'm guessing that there must be something unusual in your code, or perhaps
in the way Grinder works (not familiar with it), or in your memory
consumption. Whoops, I just saw Patrick's reply... checking the number of
database connections is a good suggestion too.
We had a bad performance problem after our app went live because I'd
neglected to remove a bit of debugging code in our Engine. I was calling
"Runtime.getRuntime().gc()" at the start of each page. That turned the app
to molasses when we got more than about 50 users.
As for the searchable archives, try one of these:
http://news.gmane.org/gmane.comp.java.tapestry.user
http://www.mail-archive.com/index.php?hunt=tapestry
http://marc.theaimsgroup.com/?l=tapestry-user&r=1&w=2
http://www.tapestryforums.com/ (a forum that began in March)
----- Original Message -----
From: "Robert Cole" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Monday, August 01, 2005 8:31 AM
Subject: Tapestry fails performance testing. HELP!
> Hi all,
>
> First off: Tapestry 3.0.1, Tomcat 5.5.9, JDK 1.5.0_1
>
> We've built our application in Tapestry and we're now trying to do some
performance testing to ensure that we will be able to support our user base.
However, we've hit a performance/scalability issue that we need to resolve
before we go live.
>
> The test we're doing is for a user to go to 1 page, then another page 5
times. This ensures that the session is up and running so that our
DirectLink works for the 2nd page. We're using The Grinder to test the
server. So far I've tested 1, 2, 5, 10, 20, 40 and 80 concurrent users.
>
> The results show that we are scaling nice and linearly, but the problem is
it looks like Tapestry is almost dealing with our requests sequentially
rather than in parallel. For example take the results below:
>
> Users Time(ms)
> 1 662
> 2 1280
> 5 2140
> 10 4900
> 20 9120
> 40 20200
>
> As you can see, a response time of 20.2 seconds for 40 users is a bit
much.
>
> So far I've checked the Tapestry Wiki, where the performance page is still
being built despite being a common question, the "Tapestry In Action" book
(absolutely nothing on performance) and attempted to search the archives.
The archives redirect me to a page that groups threads into months and
doesn't allow you to search. The "searchable" archive link just takes you
back to the un-searchable one.
>
> So, can anyone offer a couple of pointers as to where to go? I take it
Tapestry does NOT use the single threaded servlet model? Are there any pools
that we should configure? Is there a common coding mistake that we could
have made that will impact performance? Is there anything in particular that
Tapestry requires in Tomcat? I've checked our code for any
threading/synchronized issues and there are none that are obvious.
>
> Any ideas would be gratefully received.
>
> Thanks,
>
> Rob Cole
>
>
>
> --
>
> This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.
>
>
>
> ---------------------------------------------------------------------
> 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]
--
This e-mail may contain confidential and/or privileged information. If you are
not the intended recipient (or have received this e-mail in error) please
notify the sender immediately and destroy this e-mail. Any unauthorized
copying, disclosure or distribution of the material in this e-mail is strictly
forbidden.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
