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]
