No. We have created helloworld version of .jsp and tapestry app, and we see the similar issue : tomcat log shows it is taking more time to process the get requests for tapestry hellworld page than for the .jsp version.
-----Original Message----- From: Patrick Casey [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 06, 2005 10:57 AM To: 'Tapestry users' Subject: RE: Performance problem : simple tapestry page takes long time to show up Are any of your .page, .html or other assets mounted on NFS or other non-local disks? --- Pat > -----Original Message----- > From: Manoj Prakash [mailto:[EMAIL PROTECTED] > Sent: Monday, September 05, 2005 10:22 PM > To: Tapestry users; [EMAIL PROTECTED] > Subject: RE: Performance problem : simple tapestry page takes long time to > show up > > JAVA_OPTS is blank. CATALINA OPTS is default > -Dsun.io.useCanonCaches=false > We haven't disabled caching. > > It seems my issue is related to network and somehow tapestry performance > is affected by it. > > > > -----Original Message----- > From: Mark Wilcox [mailto:[EMAIL PROTECTED] > Sent: Monday, September 05, 2005 7:53 AM > To: Tapestry users > Subject: Re: Performance problem : simple tapestry page takes long time > to show up > > Manoj, > What are your JAVA OPT settings for Tomcat? > > Mark > > On 9/4/05, Fernando Padilla <[EMAIL PROTECTED]> wrote: > > So I suppose HTML page weight isn't an issue? If tapestry behaves > just > > fine on a local network then it's probably not Tapestry's fault, look > at > > the network and tomcat. I'll also mention/remind everyone to look > into > > turning on the HTTP/1.1 Compression (very easy for tomcat). It's a > > win-win sort of option for production systems!! > > > > > > Manoj Prakash wrote: > > > Yes, I haven't disabled caching. > > > > > > In our tests, we have seen tapestry doing pretty well if client is > on > > > same network as server. > > > > > > We start to see the perf issue when: > > > 1. clients are on a separate network than the server, and in such > cases; > > > tapestry/tomcat log indeed says that it is taking as much time. > > > 2. Each time you start a new browser instance to access your page( > the > > > page has been accessed earlier from different clients, so > initialization > > > time from the backend/server perspective is not a factor). > > > > > > I don't seem to find any explanation for it: why tapestry's response > > > time is dependent on where the client is located, and if the page is > > > being requested from the browser instance for the first time? > > > > > > Btw, as I mentioned in the original post, we are still using > tapestry > > > 3.0 beta 4 version. > > > > > > Thanks, > > > Manoj > > > > > > -----Original Message----- > > > From: Adam Greene [mailto:[EMAIL PROTECTED] > > > Sent: Sunday, September 04, 2005 1:25 AM > > > To: Tapestry users > > > Subject: Re: Performance problem : simple tapestry page takes long > time > > > to show up > > > > > > I have seen this discussion on and off over the last year and each > time > > > someone almost always asks this question, it may seem obvious, but > it > > > must > > > be asked none the less :-) > > > > > > Are you sure that you have not disabled caching within tapestry with > > > the -Dorg.apache.tapestry.disable-caching command line option? > > > > > > I am currently profiling Tapestry 4.0 Beta 5 and have come up with > this > > > interesting bit of information: > > > > > > On the initial page request, it takes 72 seconds (because of > profiling > > > overhead, normally 9 secs, after loaded responses are about 1sec). > Of > > > those 72 seconds, 22-25 seconds of it is one method call: > > > java.util.Locale.getAvailableLocales(), which is totally outside the > > > scope > > > of Tapestry, but the call may be removable. I am testing that now. > The > > > second biggest CPU hog is > SpecificationSource.getApplicationNameSpace, > > > at 1 > > > second average time and ElementsProxyList.size at 3.8 seconds Base > > > Time > > > (less than 0.09sec average time). > > > > > > On subsequent calls Tapestry took only 1.89sec cummulative time with > the > > > profiler active and given the formula of 72sec vs 9sec, that would > > > normally > > > be 0.23secs per request without profiler load. And that request > renders > > > two velocity macros via hivemind services, and construct a Rich Text > > > Editor > > > from 4 different script files requiring a processing 30Kb of script > with > > > 50 string replacements and 30 asset lookups after submitting the > text > > > that > > > had > > > been edited in the Rich Text Editor. So it better than a "Hello > World" > > > test > > > and > > > shows just how fast Tapestry 4.0 can be, even when under the load of > a > > > profiler :-) > > > > > > ----- Original Message ----- > > > From: "Manoj Prakash" <[EMAIL PROTECTED]> > > > To: <[email protected]> > > > Sent: Saturday, September 03, 2005 8:28 AM > > > Subject: Performance problem : simple tapestry page takes long time > to > > > show > > > up > > > > > > > > > > > >>We have been using tapestry for over 1.5 years now for our app and > > >>recently we > > >>have started performance testing of this app. There are some > > > > > > interesting > > > > > >>observations. > > >> > > >>Background/Environment: > > >>Server : P4 2.8 GHz,1 GB RAM, Windows xp, Tomcat 4.1.30, Tapestry > 3.0 > > > > > > beta > > > > > >>4. > > >>Clients : P4 XP/Win2k machines with 512 MB RAM, accessing the server > > > > > > from > > > > > >>different network. > > >> > > >>App: The first page of the app is a simplest login page, the html > > > > > > template > > > > > >>is > > >>mostly static - has html form, refers a .css file, few images and > > > > > > input > > > > > >>validation script( using tapestry's support for validation). We > create > > > > > > a > > > > > >>session ( by calling getVisit() ) on the login page itself before it > > > > > > is > > > > > >>rendered. > > >> > > >> > > >>Problem: > > >>One a new browser instance, this login page takes consistently 18 to > > > > > > 20 > > > > > >>seconds to show up. Tomcat access log shows that it is taking upto 5 > > >>seconds > > >>to process the login page request, another 5 seconds to process the > > >>request > > >>for validator.js, and almost negligible time to process the get > > > > > > requests > > > > > >>for > > >>images and .css file. We are wondering why tomcat/tapestry is taking > 5 > > >>seconds > > >>to process the Get request for such a simple page. > > >> > > >>To rule out the network and tomcat, and other factors for this > > >>performance, we > > >>added a similar static html file, and a similar .jsp file in our > > > > > > webapp, > > > > > >>and > > >>both show up within 3-4 seconds. Tomcat log in those cases show that > > > > > > it > > > > > >>took > > >>only milliseconds to process the get request for .html and .jsp > file. > > >> > > >>Any idea why this could be happening ? Is tapestry doing some heavy > > >>initialization work when a session is created? ( View source of the > > > > > > page > > > > > >>in > > >>browser has 0 millisecond at the bottom as the render time). > > >> > > >>Thanks, > > >>Manoj > > >> > > >> > > >> > > >> > > >> > > > >>--------------------------------------------------------------------- > > >>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] > > > > > > --------------------------------------------------------------------- > 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]
