You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Thomas Nybro Bolding <th...@danskebank.dk> on 2005/07/13 14:34:15 UTC
Vedr.: Pls give suggestions in tomcat tunning in production
environment
IMHO most tuning potential is in the code of the developer rather than in
the servlet container.
Use DBCP and avoid looking up contexts and datasources all the time but
simply return these from a "utility database class". If possible cache
data rather than update this upon each request (for instance user settings
and authorization, dates and other distinct common values to be shown in
combo boxes, ...)
That being said Tomcat of course may take a performance hit when GC kicks
in so to finetune the Tomcat settings use a profiler to investigate it
while running and change thread no., size etc. as well as JVM parameters accordingly. Further you may want to disable automatic recompilation when
JSP changes as well as precompile your JSP.
/Thomas
Ayyanar Inbamohan <te...@yahoo.com>
13-07-2005 13:46
Besvar venligst til "Tomcat Users List"
Til: tomcat-user@jakarta.apache.org, tomcat-dev@jakarta.apache.org,
tomcat-developer@jakarta.apache.org
cc:
Vedr.: Pls give suggestions in tomcat tunning in production environment
Hi all,
Now our webapp is running in production environment,
nearly 500 people can ask it simultaneously, so the
server performance is very low in all aspects.
so, anyone help me, how to tune the tomcat for the
production environment.
increasing memory and ...
I am using apache at the front to serve the pages.
thanks,
inr.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
<FONT SIZE=1 FACE="Arial">_______________
Vi goer opmaerksom paa, at denne e-mail kan indeholde fortrolig information. Hvis du ved en fejltagelse modtager e-mailen, beder vi dig venligst informere afsender om fejlen ved at bruge svar-funktionen. Samtidig beder vi dig slette e-mailen i dit system uden at videresende eller kopiere den.
Selv om e-mailen og ethvert vedhaeftet bilag efter vores overbevisning er fri for virus og andre fejl, som kan paavirke computeren eller it-systemet, hvori den modtages og laeses, aabnes den paa modtagerens eget ansvar. Vi paatager os ikke noget ansvar for tab og skade, som er opstaaet i forbindelse med at modtage og bruge e-mailen.
_______________
Please note that this message may contain confidential information. If you have received this message by mistake, please inform the sender of the mistake by sending a reply, then delete the message from your system without making, distributing or retaining any copies of it.
Although we believe that the message and any attachments are free from viruses and other errors that might affect the computer or IT system where it is received and read, the recipient opens the message at his or her own risk. We assume no responsibility for any loss or damage arising from the receipt or use of this message.
</FONT>
Re: Vedr.: Pls give suggestions in tomcat tunning in production
environment
Posted by Werner Punz <we...@gmx.at>.
I agree, I have an inhouse portal which is accessed by a few hundred
people constantly because it is their main entry desktop, to the whole
intranet. It is fast, with the occasional GC hickkups.
The most likely thing is a performance issue either in the app or db layer.
The most likely possibility to resolve that issue is to increase ram,
check the access algorithms which go down into the db layer, check the
db layer for performance problems and add caching if needed (good db
layers should handle that themselves)
The thing is, if you have 500 people accessing a site, you do not get
too many hits at the same time, it serving the data should be a no issue
for tomcat, it can handle bigger loads, and most likely the main problem
is application specific and even more likely database specific.
I do not thin that extensive clustering would help in this case.
Werner
Thomas Nybro Bolding wrote:
> IMHO most tuning potential is in the code of the developer rather than in
> the servlet container.
>
> Use DBCP and avoid looking up contexts and datasources all the time but
> simply return these from a "utility database class". If possible cache
> data rather than update this upon each request (for instance user settings
> and authorization, dates and other distinct common values to be shown in
> combo boxes, ...)
>
> That being said Tomcat of course may take a performance hit when GC kicks
> in so to finetune the Tomcat settings use a profiler to investigate it
> while running and change thread no., size etc. as well as JVM parameters accordingly. Further you may want to disable automatic recompilation when
> JSP changes as well as precompile your JSP.
>
> /Thomas
>
>
>
>
>
> Ayyanar Inbamohan <te...@yahoo.com>
> 13-07-2005 13:46
> Besvar venligst til "Tomcat Users List"
>
>
> Til: tomcat-user@jakarta.apache.org, tomcat-dev@jakarta.apache.org,
> tomcat-developer@jakarta.apache.org
> cc:
> Vedr.: Pls give suggestions in tomcat tunning in production environment
>
>
>
> Hi all,
>
>
> Now our webapp is running in production environment,
> nearly 500 people can ask it simultaneously, so the
> server performance is very low in all aspects.
>
> so, anyone help me, how to tune the tomcat for the
> production environment.
>
> increasing memory and ...
>
> I am using apache at the front to serve the pages.
>
> thanks,
> inr.
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>
>
>
>
> <FONT SIZE=1 FACE="Arial">_______________
> Vi goer opmaerksom paa, at denne e-mail kan indeholde fortrolig information. Hvis du ved en fejltagelse modtager e-mailen, beder vi dig venligst informere afsender om fejlen ved at bruge svar-funktionen. Samtidig beder vi dig slette e-mailen i dit system uden at videresende eller kopiere den.
> Selv om e-mailen og ethvert vedhaeftet bilag efter vores overbevisning er fri for virus og andre fejl, som kan paavirke computeren eller it-systemet, hvori den modtages og laeses, aabnes den paa modtagerens eget ansvar. Vi paatager os ikke noget ansvar for tab og skade, som er opstaaet i forbindelse med at modtage og bruge e-mailen.
> _______________
> Please note that this message may contain confidential information. If you have received this message by mistake, please inform the sender of the mistake by sending a reply, then delete the message from your system without making, distributing or retaining any copies of it.
> Although we believe that the message and any attachments are free from viruses and other errors that might affect the computer or IT system where it is received and read, the recipient opens the message at his or her own risk. We assume no responsibility for any loss or damage arising from the receipt or use of this message.
> </FONT>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org