Unfortunattaly no option, we are bound to a specific java version and tomcat version to gain support from the supplier...
-----Original Message----- From: Edson Alves Pereira [mailto:[EMAIL PROTECTED] Sent: 13 January 2004 17:51 To: 'Tomcat Users List' Subject: RE: dramatic performance differences on development machines Try tomcat-4.1.29 or tomcat-5.x > ---------- > De: Johan Coens[SMTP:[EMAIL PROTECTED] > Responder: Tomcat Users List > Enviada: terça-feira, 13 de janeiro de 2004 11:10 > Para: Tomcat Users List > Assunto: RE: dramatic performance differences on development machines > > A lot of network traffic, database lookups, rmi is going on, but i even > tested that by placing code on the mediasurface server with oracle > (placing > all on one box), and so limiting network traffic, but same performance > issues occured. > > I tested on websphere and everything is speedy (so, its not the code). > > It should be something in the system, a configuration which influences > tomcat performance dramatically and not webspheres performance, but what i > can't figure out what this could be. Maybe the only solution for me is > running websphere... > > Thanks for the feedback, > Johan > > -----Original Message----- > From: Donie Kelly [mailto:[EMAIL PROTECTED] > Sent: 13 January 2004 14:48 > To: 'Tomcat Users List' > Subject: RE: dramatic performance differences on development machines > > > What does the servlet do during the request. Is it a database lookup or > what? It's intresting that it's using 50-90% cpu time. If it were a > network > error or mis-configuration I'd expect to see 0% cpu used during the > timeout > period. Are you sure the application is working correctly when the > response > has come back. Maybe there is some sort of timeout running in your > application that does not yield very well, ie: a tight loop waiting for > something? Maybe your processing is not as correct as you think. > > Give us more to work with... > Donie > > -----Original Message----- > From: Ralph Einfeldt [mailto:[EMAIL PROTECTED] > Sent: 13 January 2004 13:45 > To: Tomcat Users List > Subject: RE: dramatic performance differences on development machines > > This kind of performance degration can > also have some of the following causes if > the load of the system doesn't indicate > a problem: > > - long or failing DNS Lookups. > - Missconfiguration that leads to round trips > in the network. > - locks (e.g. Database) > > I think you have to isolate one request that > takes long and find out where the time is spent. > (This doesn't mean in all cases profiling, in the > first step it might be enough to find out if the > time is spent before the request reaches the > application, in the application, or after the > application has sent the response.) > > > -----Original Message----- > > From: Johan Coens [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, January 13, 2004 2:28 PM > > To: Tomcat Users List > > Subject: RE: dramatic performance differences on development machines > > > > > > Here the specs are: > > > > It's a windows XP development Client > > Pentium 4, 2GHz, 512Mb memory > > jdk 1.3.1_06 > > tomcat 4.0.6 > > > > Tomcat is consuming 50-90% of processing time when serving > > the request. > > Notice, i tetsted the app on websphere too, it is serving > > quite fast, 400ms. > > instead of 20000ms. > > > > If anybody can point me where too look at I would be very happy. > > > > Johan > > > > -----Original Message----- > > From: Donie Kelly [mailto:[EMAIL PROTECTED] > > Sent: 13 January 2004 12:55 > > To: 'Tomcat Users List' > > Subject: RE: dramatic performance differences on development machines > > > > > > Any chance there is something else running on the machine > > that's killing the > > performance. > > > > You should post the specs of the machine if you expect a > > reasonable guess as > > to your problem. > > > > Donie > > > > -----Original Message----- > > From: Nikola Milutinovic [mailto:[EMAIL PROTECTED] > > Sent: 13 January 2004 09:43 > > To: Tomcat Users List > > Subject: Re: dramatic performance differences on development machines > > > > Johan Coens wrote: > > > > > Hello Nikola, > > > > > > Machines are not identical, the fast machine has different > > specs (less > > > memory, less disk space and less cpu) then the slow machine > > (this one has > > > better specs). > > > > Quite ironic. > > > > > One hint we've got is the carachter encoding in which the > > > file is saved, but it seems to me this cannot be the problem... > > > > It can be a problem, but not responsible for 20x degradation. > > > > > Sure, heavy > > > artillery can be used, but i don't think that would lead us > > to a solution, > > > also because the machine with lesser specs serves better, > > and we use the > > > same tomcat version, same settings and same jdk version. > > > > Agreed. The only thing you're left with is profiling. There > > were some posts > > on > > that subject. So far, we've heard of JProfiler and something from IBM. > > Borland's > > JBuilder has OptimizeIt Suite", but it costs $$$. > > > > Nix. > > > > > > --------------------------------------------------------------------- > > 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]
