are your dev and prod running the same number of web applications with the same number of users?
try jprofiler/jprobe or optimizeit to see what is going on > -----Original Message----- > From: Bedrijven.nl [mailto:[EMAIL PROTECTED] > Sent: 07 September 2004 09:31 > To: 'Tomcat Users List' > Subject: RE: Performance issue > > > First of all our production server is only serving our > webapps. Nothing else > (only emailserver installed as well). The searchpage search > in the DB. The > DB are also seperated of course. But we can leave out the db > since the data > is stored in hashmaps and i use connection pooling too. It > isnt the search > that give a problem, since searching is must faster in our production > environment. It's just reloading a jsp. That means a jsp page > with some > dropdownlists. This is the same on production as development > as well. When I > reload the page on the development server, it;s click and > it's there. On the > productionserver he needs some time (max 1 second) to reload > the page. It > seems it had to do something with cashing ore something??? > > Maarten > > -----Oorspronkelijk bericht----- > Van: Allistair Crossley [mailto:[EMAIL PROTECTED] > Verzonden: Tuesday, September 07, 2004 9:27 AM > Aan: Tomcat Users List > Onderwerp: RE: Performance issue > > > by load i meant that the production server may be having its > cpu/memory used > by other processes. are you saying that dev and prod servers are doing > nothing else but serving your webapp? if not you should list all the > differences, e.g what applications or software is each server > running - are > there any differences? you can take a basic look at the cpu > and memory usage > on both servers using the windows task manager. > > what does your search page search for? does it search a > database? does that > same database get searched by dev and prod? > > ADC > > > Hi ADC, > > > > First of all I use connection pooling (JSQLConnect) and put > > values in cache > > (hashmaps) so constant data retrieved once and deliver many. > > Let give an > > example of which pages this is happening: > > > > search.jsp: this jsp has multiple dropdownboxes. The data > > will be retrieved > > from the server in a Vector and this data is qua volume on both (the > > development as production) server the same. That means that > > all the content > > of the dropdownlists are the same. So I may expect that there is no > > difference in volume?? Or do you ment something different > > with that?? On a > > reload the data within the dropdownlists are retrieved from > > the servercache > > (lookup data is stored in a HashMap). So I don't know that's > > the problem. > > How do you solve this problem?? The problem now is that one > > applications > > causes an error (i don't know what, since there is nothing > > within the log) > > and tomcat restarts. > > > > Maarten > > > > > > > > -----Oorspronkelijk bericht----- > > Van: Allistair Crossley [mailto:[EMAIL PROTECTED] > > Verzonden: Tuesday, September 07, 2004 9:01 AM > > Aan: Tomcat Users List; [EMAIL PROTECTED] > > Onderwerp: RE: Performance issue > > > > > > it's an interesting one and one that we found too between our > > dev 1 cpu, > > w2k, 512mb ram, tomcat 5.0.19 and production 2 cpu, w2k, 1gb > > ram, tomcat > > 5.0.19. In both cases we use a content management system > > backend and sql > > server. > > > > for us we found that the volume of content in our cms on the > > production box > > was 10 times that of the development box and so this slowed > > the cms down > > making it look like tomcat was taking its time. also the sql > > server load on > > production is larger so database ops take longer. > > > > you ought to consider whether any dependent backend systems > like cms, > > database, crm etc.. are used in a different way between dev > > and production. > > i do not think your problem is tomcat. > > > > cheers, ADC > > > > > -----Original Message----- > > > From: Bedrijven.nl [mailto:[EMAIL PROTECTED] > > > Sent: 07 September 2004 08:30 > > > To: 'Tomcat Users List' > > > Subject: Performance issue > > > > > > > > > Hello all, > > > > > > Maybe a rare question but it's very important for us. > > What's the case: > > > > > > * I have a development environment running our applications > > > (simple server, > > > WIN 2000 Server, Tomcat 4.0.24, struts, max memorysize > appr. 320 MB) > > > * I have a production environment running our applications > > > (extended server, > > > WIN 2000 Server, Tomcat 4.0.24, struts, max memorysize > appr. 1 GB, 4 > > > processors) > > > > > > Now in our applications we have some jsp pages (i.e. > > > searchpages). So what's > > > my problem. When I reload a page (submit some action the the > > > form/actionbean > > > of struts) it's faster on our development system than on our > > > production > > > system. So normally it's should be so that jsp files should > > > be faster on our > > > production environment because the server is a lot "bigger". > > > On the other > > > hand the compilation of jsp's is faster (as expected) on the > > > production > > > environment. Are there some settings in server.xml (or > > > web.xml) that causes > > > this??? > > > > > > Thx in advanced! > > > > > > Maarten > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > > > > > > > > <FONT SIZE=1 FACE="VERDANA,ARIAL" COLOR=BLUE> > > ------------------------------------------------------- > > QAS Ltd. > > Developers of QuickAddress Software > > <a href="http://www.qas.com";>www.qas.com</a> > > Registered in England: No 2582055 > > Registered in Australia: No 082 851 474 > > ------------------------------------------------------- > > </FONT> > > > > > > > --------------------------------------------------------------------- > > 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]
