subject:"tuning"

Hi Matt,

Welcome to the list from me. It's funny because you have just listed precisely the 
same server setup as we are launching our new tomcat based app to this weekend and I 
have been having nightmares about performance. 

We have a system like this;


user - 
  IIS - 
JK2 ISAPI - 
  Tomcat 5.0.19 - 
-- Content Management System Bean
  -- SQL Server 2000
-- SQL Server 2000 via JNDI resource setup

Our application is built on Struts. 

We found performance to be very poor under a load of 20 users of 3 iterators of 20 
page requests (13 secs per page) avg pages per secon 1.1!! Looking into it revealed 
too much XML, too much database connectivity and too much dynamic rending on the 
pages. 

I came up with a caching strategy for our navigation as well as removing all XML to 
database calls instead (you may have seen my last post)

Along with other things I have managed 10 pages per seconds and 1.5 seconds per page 
under the same load test. I'm still not entirely happy and wonder if I am missing any 
confoguration type stuff to make my app run faster either in tomcat, jk2, iis and so 
fourth. I run tomcat as a service with -Xms128 -Xmx384.

I would be very interested if you have time to hear of any useful quick tips you found 
can optimise via configuration - maybe even seeing your server.conf and anything else, 
perhaps any ideas about code optimisation and also how complex your system is (db 
accesses or other system integration). 

What are your page response times under load and so on.

It's a big ask but you have a very similar hardware setup and I would like to maximise 
my use of it.

Cheers! ADC


-Original Message-
From: Matt Woodings [mailto:[EMAIL PROTECTED]
Sent: 08 April 2004 16:50
To: [EMAIL PROTECTED]
Subject: Tomcat configuration tuning


Hi guys,

I am at stage where I have all my various components talking to one another (Apache 
http server 2.0.49 - Mod JK2 - Tomcat 4.1.30) and running nicely with each other, 
but the loads on the server are increasing rapidly in our production environment ( 
~2000 logins/day and peak concurrency of ~75 currently ) and I want to get the best 
possible configuration for my server. (Dual 1GHz, 1GB Ram, Win 2k, SQL Server + 
Web/Apps servers).  

Now, ultimately this is up to me, but I am unsure of a few relationships and variables 
used in the configuration files.  The settings I have work, but I want them to be 
optimal and more importantly I want to understand them, so any help on the following 
would be greatly appreciated.

1) server.xml/Connector/bufferSize.  Is this allocated for every users session until 
it is terminated, or is it a peak size that could be allocated?
2) workers2.properties/shm.slots. Does this equate to the 
server.xml/Connector/maxProcessors? or are these fundamentally different?

I have attached my fully working configuration below for those who are interested, as 
I noticed a lot of people in the archives looking for working examples using JK2.

Many thanks,

Matt

P.S. I am new to the list but I have been using Tomcat for many years and love it, and 
if I can help with anyones queries, from the trivial to complex,  I would be only too 
happy to do so.

workers2.properties
[logger]
##
LOGGER
##
# Log level. Supported: EMERG, ERROR, INFO, DEBUG
level=ERROR
# Log file. XXX you may be able to change this at runtime, to 
# implement rolling. 
file=${serverRoot}/logs/jk2_error.log

[config]
##
CONFIG
##
# Location of the workers2.properties file
file=${serverRoot}/conf/workers2.properties
# Set the debug level of the config component
debug=0
# Set the debug level of the hidden env component
debugEnv=0

[shm]
##
SHARED MEMORY SETUP   
##
# Name of the file that will be mmapped to use as shared memory, 
# If set to 'anonymous' use the anonymous shered memory
file=${serverRoot}/logs/shm.file
# Number of shared memory slots. Set to the number of child 
# processes
slots=378
# Use process memory instead of shared memory. Useful for single 
# child mpm's
useMemory=0

[lb:lb_group]
##
LOAD BALANCER (EVEN IF USED ON ONE MACHINE)   
##
# If set, jk2 won't touch the headers in case of error and will 
# let for example Apache present the 
# ErrorDocument via mod_alias.
noErrorHeader=1
# 
noWorkerMsg=No workers available
# 
noWorkerCode=503
# 
hwBalanceErr=
# If all

RE: Tomcat configuration tuning

2004-04-08 Thread Shapira, Yoav


Hi,

Welcome to the list from me. It's funny because you have just listed
precisely the same server setup as we are launching our new tomcat
based

You have a wacky definition of precisely because he has Apache at the
front-end and you have IIS.

Yoav Shapira



This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Tomcat configuration tuning

Yes ok :) but other than that ;)

ADC.

-Original Message-
From: Shapira, Yoav [mailto:[EMAIL PROTECTED]
Sent: 08 April 2004 17:01
To: Tomcat Users List
Subject: RE: Tomcat configuration tuning

Hi,

Welcome to the list from me. It's funny because you have just listed
precisely the same server setup as we are launching our new tomcat
based

You have a wacky definition of precisely because he has Apache at the
front-end and you have IIS.

Yoav Shapira

This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.

-
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]

RE: Tomcat configuration tuning

Hey

Yes our struts uses the tiles plugin also. And the page load times are as a result of 
running on the server itself unfortunately. I am using the JTDS driver which 
apparently is one of the fastest SQL Server 2000 implementations for db connectivity.

One of the things about our system is that every click the user makes is a search to 
the CMS for content that belongs to that page. This could be considered sub-optimal. 
For instance, I could cache results per 15 minutes or something, but content changes 
often so I thought I would leave it dynamic. 

I spent some time running JProfiler against the app. The accumulated CPU and memory 
seemed to ultimately come down to these search calls to the CMS especially under load. 
Per request I have to instantiate the vendors' bean which is an interface to the CMS 
server socket and is responsible for giving back all the data from the calls. I then 
simply package up what I need in data transfer objects and ship them to the JSPs. The 
JSPs are highly configurable in terms of skinning and so on and have calls to the file 
system to check if images are present and so on. I think I could cache that too. In 
fact looking at timings in the logs shows the page start to end is sub 1 second, the 
rest (user click - page process start) I think is caught up at the search but even so 
that is generally about 0.8s. Pages are taking about 0.1 and my cached implementation 
of nav takes 0.06 or so to load. But overall the pages under load feel like they take 
about 2 seconds and also I get the feeling tomcat is recompiling something it really 
doesn't need to - that was why I was interested in the development flag in server.conf 
and whether I should turn that to false.

A fair amount of CPU and memory was going to Log4J also. I removed a lot of our 
unnecessary debugging statements and this too helped. 

I guess it comes down to the CMS load but any tips from others on the list are so very 
welcome,

Cheers, ADC

-Original Message-
From: LILES, DAVID (CONTRACTOR) [mailto:[EMAIL PROTECTED]
Sent: 08 April 2004 17:22
To: Allistair Crossley
Subject: RE: Tomcat configuration tuning


I have seen a couple postings regarding poor performance with Tomcat recently and 
thought I'd respond because we are using IIS5 with Tomcat 5 and SQL 2000 as well.

We have a Struts site but our difference is that we are using Tiles for our 
presentation... haven't really looked into the performance differences between Tiles 
and non-Tiles display rates

As for our database connectivity... we are using an internally developed connection 
pooling class (no JNDI), but have recently started migrating to Hibernate.

It is interesting hearing how long it is taking for the pages to be displayed 
considering we are on a similar set-up and have not noticed this type of problem. We 
have not made any special optimization setting changes, we basically did an out of the 
box set-up 

Is this occurring when running the app locally or on the server? I would be curious to 
know what is the resource load on the box running the app, how is the connectivity 
(bandwidth) to the box, has any sort of optimization tools been run against the code 
to check for bottle-necks?

Not sure that I can provide much value technically, but feel free to ask

-Dave



 -Original Message-
From:   Allistair Crossley [mailto:[EMAIL PROTECTED] 
Sent:   Thursday, April 08, 2004 11:00 AM
To: Tomcat Users List
Cc: [EMAIL PROTECTED]
Subject:RE: Tomcat configuration tuning

Hi Matt,

Welcome to the list from me. It's funny because you have just listed precisely the 
same server setup as we are launching our new tomcat based app to this weekend and I 
have been having nightmares about performance. 

We have a system like this;


user - 
  IIS - 
JK2 ISAPI - 
  Tomcat 5.0.19 - 
-- Content Management System Bean
  -- SQL Server 2000
-- SQL Server 2000 via JNDI resource setup

Our application is built on Struts. 

We found performance to be very poor under a load of 20 users of 3 iterators of 20 
page requests (13 secs per page) avg pages per secon 1.1!! Looking into it revealed 
too much XML, too much database connectivity and too much dynamic rending on the 
pages. 


I came up with a caching strategy for our navigation as well as removing all XML to 
database calls instead (you may have seen my last post)

Along with other things I have managed 10 pages per seconds and 1.5 seconds per page 
under the same load test. I'm still not entirely happy and wonder if I am missing any 
confoguration type stuff to make my app run faster either in tomcat, jk2, iis and so 
fourth. I run tomcat as a service with -Xms128 -Xmx384.

I would be very interested if you have time to hear of any useful quick tips you found 
can optimise via configuration - maybe even seeing your server.conf and anything else, 
perhaps any ideas about code optimisation and also how complex your system

R: Tomcat configuration tuning

2004-04-08 Thread Simone - Dev

Hello,
I'm having the same problem with a big news portal I'm developing
(goal.com, and a few of other sites - italian soccer team - that share
the same content management), and even if it is developed with .NET, the
concept is almost the same.

I don't know how your environment is set up, but u can cache the results
for 15 min or even forever, but u can force a cache reload whenever you
update a content in the adminstration application.

If the frontend is running in another context (or even another server)
then the admin site (and u don't have access to the same instance of the
CMS), you can call a webservice (or a simplier page) to do this.

Simone

-
Simone Chiaretta
www.piyosailing.com/S
Any sufficiently advanced technology is indistinguishable from magic
Life is short, play hard


 -Messaggio originale-
 Da: Allistair Crossley [mailto:[EMAIL PROTECTED] 
 Inviato: giovedì 8 aprile 2004 18.33
 A: LILES, DAVID (CONTRACTOR); [EMAIL PROTECTED]
 Oggetto: RE: Tomcat configuration tuning
 
 
 Hey
 
 Yes our struts uses the tiles plugin also. And the page load 
 times are as a result of running on the server itself 
 unfortunately. I am using the JTDS driver which apparently is 
 one of the fastest SQL Server 2000 implementations for db 
 connectivity.
 
 One of the things about our system is that every click the 
 user makes is a search to the CMS for content that belongs to 
 that page. This could be considered sub-optimal. For 
 instance, I could cache results per 15 minutes or something, 
 but content changes often so I thought I would leave it dynamic. 
 
 I spent some time running JProfiler against the app. The 
 accumulated CPU and memory seemed to ultimately come down to 
 these search calls to the CMS especially under load. Per 
 request I have to instantiate the vendors' bean which is an 
 interface to the CMS server socket and is responsible for 
 giving back all the data from the calls. I then simply 
 package up what I need in data transfer objects and ship them 
 to the JSPs. The JSPs are highly configurable in terms of 
 skinning and so on and have calls to the file system to check 
 if images are present and so on. I think I could cache that 
 too. In fact looking at timings in the logs shows the page 
 start to end is sub 1 second, the rest (user click - page 
 process start) I think is caught up at the search but even so 
 that is generally about 0.8s. Pages are taking about 0.1 and 
 my cached implementation of nav takes 0.06 or so to load. But 
 overall the pages under load feel like they take about 2 
 seconds and also I get the feeling tomcat is recompiling 
 something it really doesn't need to - that was why I was 
 interested in the development flag in server.conf and whether 
 I should turn that to false.
 
 A fair amount of CPU and memory was going to Log4J also. I 
 removed a lot of our unnecessary debugging statements and 
 this too helped. 
 
 I guess it comes down to the CMS load but any tips from 
 others on the list are so very welcome,
 
 Cheers, ADC
 
 -Original Message-
 From: LILES, DAVID (CONTRACTOR) [mailto:[EMAIL PROTECTED]
 Sent: 08 April 2004 17:22
 To: Allistair Crossley
 Subject: RE: Tomcat configuration tuning
 
 
 I have seen a couple postings regarding poor performance with 
 Tomcat recently and thought I'd respond because we are using 
 IIS5 with Tomcat 5 and SQL 2000 as well.
 
 We have a Struts site but our difference is that we are using 
 Tiles for our presentation... haven't really looked into the 
 performance differences between Tiles and non-Tiles display rates
 
 As for our database connectivity... we are using an 
 internally developed connection pooling class (no JNDI), but 
 have recently started migrating to Hibernate.
 
 It is interesting hearing how long it is taking for the pages 
 to be displayed considering we are on a similar set-up and 
 have not noticed this type of problem. We have not made any 
 special optimization setting changes, we basically did an out 
 of the box set-up 
 
 Is this occurring when running the app locally or on the 
 server? I would be curious to know what is the resource load 
 on the box running the app, how is the connectivity 
 (bandwidth) to the box, has any sort of optimization tools 
 been run against the code to check for bottle-necks?
 
 Not sure that I can provide much value technically, but feel 
 free to ask
 
 -Dave
 
 
 
  -Original Message-
 From: Allistair Crossley [mailto:[EMAIL PROTECTED] 
 Sent: Thursday, April 08, 2004 11:00 AM
 To:   Tomcat Users List
 Cc:   [EMAIL PROTECTED]
 Subject:  RE: Tomcat configuration tuning
 
 Hi Matt,
 
 Welcome to the list from me. It's funny because you have just 
 listed precisely the same server setup as we are launching 
 our new tomcat based app to this weekend and I have been 
 having nightmares about performance. 
 
 We have a system like this;
 
 
 user - 
   IIS - 
 JK2 ISAPI

Re: Tomcat configuration tuning

2004-04-08 Thread Matt Woodings

Hi Allistair,

Thanks for the quick response.  My server.xml file is below but to some of
the questions you had.  One of the biggest speed increases we gained was
from SQL optimization and table tuning.  One thing about server.xml
configuration which I realised is the acceptCount being set too high,
because if your server is struggling anyway having the requests backing up
is not going to help in fact may help it to go down.

What I mean by SQL optimization is we had java take over a lot of processing
rather than the database, so some of our queries may seem at first a little
broad but the speed increase was incredible.  Think how fast java can
iterate through a set of results rather than constantly referring to the db,
so that was one.   Also, one of our tables is heavily used and also ever
increasing in size, so to keep this fast I keep only a few weeks worth of
data in it (so its indexing is still really quick) and offload the rest to a
history table which is only used for reporting ... so based on date range I
either quickly recieve the latest info or slightly slower receive data from
the past.

Unfortunately I am unable to give you response times as they would be
meaningless (number of db hits, processing etc), but suffice to say its in
the region of 100msecs for non db jsp pages to 20+ secs (depending upon
connection) for insanely large amounts of db/processed pages and for the
vast majority of pages for select style queries are about 700msecs.  Sorry I
can't be of more help there.

I haven't read your post on caching yet, but I rely heavily on XML for our
site, from configuration to the menu options, and I also use streamed XML to
XSLT for all our views.  I guess it comes down to what you need to do, but I
would love to hear how you are using it.

One of the problems I am tackling at the moment is for places where there is
a lot of db inserts/updates which can't be done on-mass, so I am coming up
with a plan to assign these tasks to be fulfilled at off peak times, or in
manageable chunks so as to keep response times high.  One of the problems I
am overcoming is that our users aren't tech savvy and if a page doesn't load
fast enough they will hit reload constantly and escalate any memory problems
I may have had to the dreaded outOfMemory Exception.

Regards,

Matt

P.S. Struts ROCKS!!!

server.xml
?xml version='1.0' encoding='utf-8'?
Server className=org.apache.catalina.core.StandardServer port=8005
debug=0 shutdown=SHUTDOWN
  Listener className=org.apache.catalina.mbeans.ServerLifecycleListener
debug=0 jsr77Names=false/
  Listener
className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener
debug=0/
  GlobalNamingResources
Environment name=simpleValue override=true type=java.lang.Integer
value=30/
Resource name=UserDatabase scope=Shareable
type=org.apache.catalina.UserDatabase auth=Container description=User
database that can be updated and saved/
ResourceParams name=UserDatabase
  parameter
namefactory/name
valueorg.apache.catalina.users.MemoryUserDatabaseFactory/value
  /parameter
  parameter
namepathname/name
valueconf/tomcat-users.xml/value
  /parameter
/ResourceParams
  /GlobalNamingResources
  Service className=org.apache.catalina.core.StandardService debug=0
name=Tomcat-Load-Balance-1
Connector className=org.apache.coyote.tomcat4.CoyoteConnector
redirectPort=8443 bufferSize=8192 port=8009 connectionTimeout=0
enableLookups=true
protocolHandlerClassName=org.apache.jk.server.JkCoyoteHandler debug=0
disableUploadTimeout=true maxProcessors=378 minProcessors=5
acceptCount=100 useURIValidationHack=false /
Engine jvmRoute=hsInstance debug=0 defaultHost=instance1
name=LoadBalance
  Host appBase=webapps autoDeploy=true debug=0 unpackWARs=true
name=instance1
Context crossContext=true reloadable=true debug=0
docBase=** path=/hs 
  Resource name=jdbc/** scope=Shareable
type=javax.sql.DataSource/
  ResourceParams name=jdbc/**
parameter
  nameurl/name
  value**/value
/parameter
parameter
  namemaxIdle/name
  value1000/value
/parameter
parameter
  namemaxActive/name
  value1/value
/parameter
parameter
  namedriverClassName/name
  valuecom.microsoft.jdbc.sqlserver.SQLServerDriver/value
/parameter
parameter
  namemaxWait/name
  value6/value
/parameter
parameter
  nameremoveAbandoned/name
  valuetrue/value
/parameter
parameter
  nameusername/name
  value**/value
/parameter
parameter
  namelogAbandoned/name
  valuetrue/value
/parameter
parameter

RE: Tomcat configuration tuning

Slightly off-forum but related to my performance tuning of my tomcat webapp, I am 
using the JCIFS NTLM authentication servlet as a filter. The filter is mapped to all 
requests /*. I just thought to myself on the train home whether because NTLM is a 
3-way handshake, that this may be causing some kind of performance hit.
 
The filter authenticates the desktop user and then populates the 
request.getRemoteUser. I suppose I could do this once with a login servlet and then 
populate a session user object and if that ever expires redirect back to the login 
servlet.
 
Does anyone have an opinion on whether it would be worth my time removing the filter 
per request in favour of a once-only login action.
 
I appreciate this is off-tomcat, so no hard feelings if noone replies ;)
 
ADC


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]

Re: Tomcat configuration tuning

I do just what you described below. If the loginContext isn't in the
session,
I show do a global-forward to the login form. And, because I didn't want to
have to put a session check into every Struts action I used AspectJ to weave
in a pointcut into every action. Works great. I was considering going with
a filter servlet instead but if you say its slow then maybe I did the right
thing.

Charlie

Allistair Crossley wrote:

Slightly off-forum but related to my performance tuning of my tomcat webapp, I am using the JCIFS NTLM authentication servlet as a filter. The filter is mapped to all requests /*. I just thought to myself on the train home whether because NTLM is a 3-way handshake, that this may be causing some kind of performance hit.

The filter authenticates the desktop user and then populates the request.getRemoteUser. I suppose I could do this once with a login servlet and then populate a session user object and if that ever expires redirect back to the login servlet.

Does anyone have an opinion on whether it would be worth my time removing the filter per request in favour of a once-only login action.

I appreciate this is off-tomcat, so no hard feelings if noone replies ;)

ADC

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]

RE: Tomcat configuration tuning

2004-04-08 Thread Shapira, Yoav


Hi,
Did you profile the filter versus aspects?  Now that's a benchmark I'd
be really interested in.

To the original poster: assuming your filter is smart enough to check
the session for a user is authenticated already token, the /* mapping
is not that big a deal.  If you're re-authenticating every time, that's
terrible, and you should make your filter smarter.

Yoav Shapira
Millennium Research Informatics


-Original Message-
From: Charles N. Harvey III [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 08, 2004 3:38 PM
To: Tomcat Users List
Subject: Re: Tomcat configuration tuning

I do just what you described below.  If the loginContext isn't in the
session,
I show do a global-forward to the login form.  And, because I didn't
want
to
have to put a session check into every Struts action I used AspectJ to
weave
in a pointcut into every action.  Works great.  I was considering going
with
a filter servlet instead but if you say its slow then maybe I did the
right
thing.


Charlie



Allistair Crossley wrote:

Slightly off-forum but related to my performance tuning of my tomcat
webapp, I am using the JCIFS NTLM authentication servlet as a filter.
The
filter is mapped to all requests /*. I just thought to myself on the
train
home whether because NTLM is a 3-way handshake, that this may be
causing
some kind of performance hit.

The filter authenticates the desktop user and then populates the
request.getRemoteUser. I suppose I could do this once with a login
servlet and then populate a session user object and if that ever
expires
redirect back to the login servlet.

Does anyone have an opinion on whether it would be worth my time
removing
the filter per request in favour of a once-only login action.

I appreciate this is off-tomcat, so no hard feelings if noone replies
;)

ADC


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]




This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat configuration tuning

I've never actually used a profiler before.  I keep meaning to I swear.
Its my next big venture.  I just figured out unit testing about 2 weeks ago.
We just never have time for that silly testing and profiling stuff at my
company.  I never actually wrote the filter either.  But I have one around
that I could use to at least do some testing.
I'll try this profiling and try to get the results back to the list.

Charlie

Shapira, Yoav wrote:

Hi,
Did you profile the filter versus aspects?  Now that's a benchmark I'd
be really interested in.
To the original poster: assuming your filter is smart enough to check
the session for a user is authenticated already token, the /* mapping
is not that big a deal.  If you're re-authenticating every time, that's
terrible, and you should make your filter smarter.
Yoav Shapira
Millennium Research Informatics
 

-Original Message-
From: Charles N. Harvey III [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 08, 2004 3:38 PM
To: Tomcat Users List
Subject: Re: Tomcat configuration tuning
I do just what you described below.  If the loginContext isn't in the
session,
I show do a global-forward to the login form.  And, because I didn't
   

want
 

to
have to put a session check into every Struts action I used AspectJ to
weave
in a pointcut into every action.  Works great.  I was considering going
with
a filter servlet instead but if you say its slow then maybe I did the
   

right
 

thing.

Charlie



Allistair Crossley wrote:

   

Slightly off-forum but related to my performance tuning of my tomcat
 

webapp, I am using the JCIFS NTLM authentication servlet as a filter.
   

The
 

filter is mapped to all requests /*. I just thought to myself on the
   

train
 

home whether because NTLM is a 3-way handshake, that this may be
   

causing
 

some kind of performance hit.
   

The filter authenticates the desktop user and then populates the
 

request.getRemoteUser. I suppose I could do this once with a login
servlet and then populate a session user object and if that ever
   

expires
 

redirect back to the login servlet.
   

Does anyone have an opinion on whether it would be worth my time
 

removing
 

the filter per request in favour of a once-only login action.
   

I appreciate this is off-tomcat, so no hard feelings if noone replies
 

;)
 

ADC

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]
   





This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged.  This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender.  Thank you.

-
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]

RE: Tomcat configuration tuning

Hi Yoav
 
It's the Samba team JCIFS NTLM servlet filter, so I guess I need to find out from them 
if the auth is done each time.
 
Cheers, ADC
 
-Original Message- 
From: Shapira, Yoav [mailto:[EMAIL PROTECTED] 
Sent: Thu 08/04/2004 20:39 
To: Tomcat Users List 
Cc: 
Subject: RE: Tomcat configuration tuning




Hi,
Did you profile the filter versus aspects?  Now that's a benchmark I'd
be really interested in.

To the original poster: assuming your filter is smart enough to check
the session for a user is authenticated already token, the /* mapping
is not that big a deal.  If you're re-authenticating every time, that's
terrible, and you should make your filter smarter.

Yoav Shapira
Millennium Research Informatics


-Original Message-
From: Charles N. Harvey III [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 08, 2004 3:38 PM
To: Tomcat Users List
Subject: Re: Tomcat configuration tuning

I do just what you described below.  If the loginContext isn't in the
session,
I show do a global-forward to the login form.  And, because I didn't
want
to
have to put a session check into every Struts action I used AspectJ to
weave
in a pointcut into every action.  Works great.  I was considering going
with
a filter servlet instead but if you say its slow then maybe I did the
right
thing.


Charlie



Allistair Crossley wrote:

Slightly off-forum but related to my performance tuning of my tomcat
webapp, I am using the JCIFS NTLM authentication servlet as a filter.
The
filter is mapped to all requests /*. I just thought to myself on the
train
home whether because NTLM is a 3-way handshake, that this may be
causing
some kind of performance hit.

The filter authenticates the desktop user and then populates the
request.getRemoteUser. I suppose I could do this once with a login
servlet and then populate a session user object and if that ever
expires
redirect back to the login servlet.

Does anyone have an opinion on whether it would be worth my time
removing
the filter per request in favour of a once-only login action.

I appreciate this is off-tomcat, so no hard feelings if noone replies
;)

ADC


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]




This e-mail, including any attachments, is a confidential business 
communication, and may contain information that is confidential, proprietary and/or 
privileged.  This e-mail is intended only for the individual(s) to whom it is 
addressed, and may not be saved, copied, printed, disclosed or used by anyone else.  
If you are not the(an) intended recipient, please immediately delete this e-mail from 
your computer system and notify the sender.  Thank you.


-
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]

RE: Tomcat configuration tuning

All our actions extend an abstract base action that handles auth if the session user 
is null and then delegates to a subclass to do the actial work which is another way of 
what you describe there. 
 
Hm...are you saying you use JCIFS also? Is the loginContext your own or part of the 
JCIFS API.

ADC

-Original Message- 
From: Charles N. Harvey III [mailto:[EMAIL PROTECTED] 
Sent: Thu 08/04/2004 20:38 
To: Tomcat Users List 
Cc: 
Subject: Re: Tomcat configuration tuning



I do just what you described below.  If the loginContext isn't in the
session,
I show do a global-forward to the login form.  And, because I didn't want to
have to put a session check into every Struts action I used AspectJ to weave
in a pointcut into every action.  Works great.  I was considering going with
a filter servlet instead but if you say its slow then maybe I did the right
thing.


Charlie



Allistair Crossley wrote:

Slightly off-forum but related to my performance tuning of my tomcat webapp, 
I am using the JCIFS NTLM authentication servlet as a filter. The filter is mapped to 
all requests /*. I just thought to myself on the train home whether because NTLM is a 
3-way handshake, that this may be causing some kind of performance hit.

The filter authenticates the desktop user and then populates the 
request.getRemoteUser. I suppose I could do this once with a login servlet and then 
populate a session user object and if that ever expires redirect back to the login 
servlet.

Does anyone have an opinion on whether it would be worth my time removing the 
filter per request in favour of a once-only login action.

I appreciate this is off-tomcat, so no hard feelings if noone replies ;)

ADC


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]





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]

Re: Tomcat configuration tuning

LoginContext is part of the jdk1.4. javax.security.auth.login.LoginContext.
It is usually extended by others. I found the very popular example on
javaworld.com
where the author created an RDBMDLoginContext. I changed that to my own
OJBLoginContext
because I use Apache OJB. Its pretty easy to write one, just override
each of the
methods.

Charlie

Allistair Crossley wrote:

All our actions extend an abstract base action that handles auth if the session user is null and then delegates to a subclass to do the actial work which is another way of what you describe there.

Hm...are you saying you use JCIFS also? Is the loginContext your own or part of the JCIFS API.

ADC

-Original Message-
From: Charles N. Harvey III [mailto:[EMAIL PROTECTED]
Sent: Thu 08/04/2004 20:38
To: Tomcat Users List
Cc:
Subject: Re: Tomcat configuration tuning

Charlie

Allistair Crossley wrote:

Does anyone have an opinion on whether it would be worth my time removing the filter per request in favour of a once-only login action.

I appreciate this is off-tomcat, so no hard feelings if noone replies ;)

ADC

-
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]

Re: Tomcat configuration tuning

Sorry, I was a little off in that last e-mail.

The example on javaworld.com has you extending LoginContext to 
SessionLoginContext.
It extends LoginContext and implements HttpSessionBindingListner.  This 
is done
so that when the session is over, the logout method is called from 
valueUnbound().

RDBMSLoginModule is the other class from the example and it implements 
LoginModule.
This is the jaas class that you configure in your jaas.config file.

None of this really has anything to do with Tomcat configuration tuning, 
sorry
for going off on a tangent.

Charlie

Charles N. Harvey III wrote:

LoginContext is part of the jdk1.4.  
javax.security.auth.login.LoginContext.
It is usually extended by others.  I found the very popular example on 
javaworld.com
where the author created an RDBMDLoginContext.  I changed that to my 
own OJBLoginContext
because I use Apache OJB.  Its pretty easy to write one, just override 
each of the
methods.

Charlie



Allistair Crossley wrote:

All our actions extend an abstract base action that handles auth if 
the session user is null and then delegates to a subclass to do the 
actial work which is another way of what you describe there.
Hm...are you saying you use JCIFS also? Is the loginContext your own 
or part of the JCIFS API.

ADC

-Original Message- From: Charles N. Harvey III 
[mailto:[EMAIL PROTECTED] Sent: Thu 08/04/2004 20:38 To: 
Tomcat Users List Cc: Subject: Re: Tomcat configuration tuning



I do just what you described below.  If the loginContext isn't in 
the
session,
I show do a global-forward to the login form.  And, because I 
didn't want to
have to put a session check into every Struts action I used 
AspectJ to weave
in a pointcut into every action.  Works great.  I was considering 
going with
a filter servlet instead but if you say its slow then maybe I did 
the right
thing.


Charlie



Allistair Crossley wrote:

Slightly off-forum but related to my performance tuning of my 
tomcat webapp, I am using the JCIFS NTLM authentication servlet as a 
filter. The filter is mapped to all requests /*. I just thought to 
myself on the train home whether because NTLM is a 3-way handshake, 
that this may be causing some kind of performance hit.

The filter authenticates the desktop user and then populates the 
request.getRemoteUser. I suppose I could do this once with a login 
servlet and then populate a session user object and if that ever 
expires redirect back to the login servlet.

Does anyone have an opinion on whether it would be worth my time 
removing the filter per request in favour of a once-only login action.

I appreciate this is off-tomcat, so no hard feelings if noone 
replies ;)

ADC


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]





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]

tuning

2004-04-02 Thread Randy Paries

Hello

I am looking for docs/howto on tuning

I am setting up some new boxes with rh9, tomcat 4 and apache 2

Any heads up from experience would help as well

I am move the code from a rh7, tomcat 4 and apache 1.3

Thanks
Randy


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat Tuning Memory leak

Hi (yes that's me again),

I have more details for those that would be willing to help. I have 
started to use IBM's JDK that has the nice memory dump feature set up so 
that whenever OutOfMemory occurs the heap is dumped. So my heap is here
http://hry.atlas.cz/zaloha/heapdump.20040114.160700.8886.txt.gz
Probably no need to download the 12MB - I have tried to process it and 
interesting result is this:

I have used the k function of HeapRoots205 (here is its description):
This executes by first running 'p 0x1234'. This leaves every object 
reachable by 0x1234 owned by it. Then any objects which are owned by 
0x1234 but reachable from outside of this set are removed. This leaves 
0x1234 owning exactly those objects which are only reachable thru' it.

on following object:

 k 0x10102818

Calculating keep-alive size of 0x10102818 
'org/apache/coyote/RequestGroupInfo' ...

Requesting 17 mb of heapspace to process heapdump ...

done.
Finding pure Roots
.. done.
DFS from 0x10102818
.  done.
Total reach (inclusive) 1,245,481 objects. Total-size is 299,128,896.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat Tuning Memory leak

My previous post should be longer ... here is the rest:

DFS from pure Roots
...done.
DFS from objects unreached from Roots
...done.
Found 1,051,382 objects which are reachable from elsewhere.
These will be taken from 0x10102818 and then owned by other objects ...
DFS from 0x10102818
.  done.
Keep-alive size (inclusive) is 194,099 objects. Total-size is 154,016,544.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat Tuning Memory leak

Still I don't see the whole thing - and trying to send the rest here:

If I interpret it correctly the instance of 
org/apache/coyote/RequestGroupInfo
holds 150 MB of heap memory. Also if I understand it correctly from here
http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/
someone just recently tried to do something with it.

Am I totally paranoic when I suspect that the memory leak is in tomcat?

Thanks for any hints (as usually) and best regards,

David



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Tomcat Tuning Memory leak

2004-01-16 Thread Shapira, Yoav


Howdy,

If I interpret it correctly the instance of
org/apache/coyote/RequestGroupInfo
holds 150 MB of heap memory. Also if I understand it correctly from
here
http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-
connectors/coyote/src/java/org/apache/coyote/
someone just recently tried to do something with it.

Am I totally paranoic when I suspect that the memory leak is in tomcat?

You're not paranoid.  There's a memory leak related to the
RequestGroup/RequestGroupInfo connector code.  It's been discussed
during the past week on the dev mailing list, and addressed within the
past couple of days.  You can try the tomcat 5.0.18 build which has the
fix.

Yoav Shapira



This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat Tuning Memory leak

Shapira, Yoav wrote:
You're not paranoid.  There's a memory leak related to the
RequestGroup/RequestGroupInfo connector code.  It's been discussed
during the past week on the dev mailing list, and addressed within the
past couple of days.  You can try the tomcat 5.0.18 build which has the
fix.
Yoav Shapira
Thanks for the pointer. Although they talk only about 5.0.x I thing that 
the problem is present even in 4.1.29 - it might make sense to only 
downgrade to 4.1.27 because the classes in question were not there ...
I will first try to set minProcessors==maxProcessors and see whether it 
helps even in 4.1.29. If it won't help I will think about moving to some 
other revision.

Thanks again and best regards,

David



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Tomcat Tuning Memory leak

2003-12-30 Thread Mohit Gupta


Hi All

I am working on Tomcat 4.1.24 on Solatis-8, 12 CPU, 24GB RAM Machine. I am using 
Apache 2.0.43 and the Jdk version is 1.4.1_02.

When I start my server then after 5-6 hours my server becomes very slow and then I 
need to restart my server. I am taking the top stats for the tomcat and have found 
that normally the thread remains between 100- 140 but when the system crashes it 
reaches to 372 and the memory gradually increases from 256 to some where around 660. 
The top stats are as follows

   PID USERNAME THR PRI NICE  SIZE   RES STATETIMECPU COMMAND
 13082 root 115   00  653M  578M cpu/290 313:31 37.64% java
 13082 root 139   70  654M  579M cpu/291 388:08 40.78% java
 13082 root 143   00  654M  580M cpu/419 466:39 41.43% java
 13082 root 374   10  662M  589M cpu/323 547:47 47.03% java
 13082 root 374  100  662M  589M cpu/291 625:42 53.59% java

 Here the Thread count increases from 143 to 374 in just 10 min. Even though the no of 
user accessing this site has decreased. I really dont know what the problem is...
 I have set the Catalina Option as -Xms128M -Xmx512M but even setting the value of 
-XMx1024 doesn't solved my problem.

 The connector settings in my server.xml are as follows

 Connector className=org.apache.coyote.tomcat4.CoyoteConnector acceptCount=5 
bufferSize=2048 connectionTimeout=2 debug=0 disableUploadTimeout=false 
enableLookups=false maxProcessors=350 minProcessors=5 port=8009 
protocolHandlerClassName=org.apache.jk.server.JkCoyoteHandler proxyPort=0 
redirectPort=8443 scheme=http secure=false tcpNoDelay=true 
useURIValidationHack=false
 Factory className=org.apache.catalina.net.DefaultServerSocketFactory/
 /Connector

 Please tell me what is the problem with my configuration.
 Please help me

 Thanks  Regards
 Mohit




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat Tuning Memory leak

Hi,

I have the very same problem. I have tried everything possible with no
outcome (the fork atribute for the jsp compiler did not help (with this
I refer to a previous discussion here)). I suspect the CoyoteConnector
being at fault but have no proof yet. I plan to run profiler but doing
that with users hanging on our machine it requires a bit of courage.

If you manage to solve this problem somehow please let me know (on this
mailing list) because there is at least one person _very_ interested in
solving this problem. Even if you succeed by trying another connector I
would like to hear.

Good luck and best regards,

David

Mohit Gupta wrote:
Hi All

I am working on Tomcat 4.1.24 on Solatis-8, 12 CPU, 24GB RAM Machine. I am using Apache 2.0.43 and the Jdk version is 1.4.1_02.

When I start my server then after 5-6 hours my server becomes very slow and then I need to restart my server. I am taking the top stats for the tomcat and have found that normally the thread remains between 100- 140 but when the system crashes it reaches to 372 and the memory gradually increases from 256 to some where around 660. The top stats are as follows

PID USERNAME THR PRI NICE SIZE RES STATETIMECPU COMMAND
13082 root 115 00 653M 578M cpu/290 313:31 37.64% java
13082 root 139 70 654M 579M cpu/291 388:08 40.78% java
13082 root 143 00 654M 580M cpu/419 466:39 41.43% java
13082 root 374 10 662M 589M cpu/323 547:47 47.03% java
13082 root 374 100 662M 589M cpu/291 625:42 53.59% java
Here the Thread count increases from 143 to 374 in just 10 min. Even though the no of user
accessing this site has decreased. I really dont know what the problem is...
I have set the Catalina Option as -Xms128M -Xmx512M but even setting the value of
-XMx1024 doesn't solved my problem.
The connector settings in my server.xml are as follows

Connector className=org.apache.coyote.tomcat4.CoyoteConnector acceptCount=5 bufferSize=2048 connectionTimeout=2 debug=0 disableUploadTimeout=false enableLookups=false
maxProcessors=350 minProcessors=5 port=8009 protocolHandlerClassName=org.apache.jk.server.JkCoyoteHandler proxyPort=0 redirectPort=8443 scheme=http secure=false
tcpNoDelay=true useURIValidationHack=false
Factory className=org.apache.catalina.net.DefaultServerSocketFactory/
/Connector
Please tell me what is the problem with my configuration.
Please help me

Thanks Regards
Mohit

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat Tuning Memory leak

Ooops. I was too fast with my previous post. My config is different form 
yours:

Connector className=org.apache.coyote.tomcat4.CoyoteConnector 
address=212.47.18.50 acceptCount=100 bufferSize=2048 
compression=off connectionLinger=-1 connectionTimeout=2 
connectionUploadTimeout=30 debug=0 disableUploadTimeout=true 
enableLookups=false maxKeepAliveRequests=100 maxProcessors=250 
minProcessors=25 port=80 
protocolHandlerClassName=org.apache.coyote.http11.Http11Protocol 
proxyPort=0 redirectPort=8443 scheme=http secure=false 
serverSocketTimeout=0 tcpNoDelay=true tomcatAuthentication=true 
useURIValidationHack=false
  Factory 
className=org.apache.catalina.net.DefaultServerSocketFactory/
/Connector

Also my machine is a bit smaller ;-) (with linux). But the behaviour is 
very similar.

Best,

David

David Strupl wrote:
Hi,

I have the very same problem. I have tried everything possible with no 
outcome (the fork atribute for the jsp compiler did not help (with this 
I refer to a previous discussion here)). I suspect the CoyoteConnector 
being at fault but have no proof yet. I plan to run profiler but doing 
that with users hanging on our machine it requires a bit of courage.

If you manage to solve this problem somehow please let me know (on this 
mailing list) because there is at least one person _very_ interested in 
solving this problem. Even if you succeed by trying another connector I 
would like to hear.

Good luck and best regards,

David

Mohit Gupta wrote:

Hi All

I am working on Tomcat 4.1.24 on Solatis-8, 12 CPU, 24GB RAM Machine. 
I am using Apache 2.0.43 and the Jdk version is 1.4.1_02.

When I start my server then after 5-6 hours my server becomes very 
slow and then I need to restart my server. I am taking the top stats 
for the tomcat and have found that normally the thread remains between 
100- 140 but when the system crashes it reaches to 372 and the memory 
gradually increases from 256 to some where around 660. The top stats 
are as follows

   PID USERNAME THR PRI NICE  SIZE   RES STATETIMECPU COMMAND
 13082 root 115   00  653M  578M cpu/290 313:31 37.64% java
 13082 root 139   70  654M  579M cpu/291 388:08 40.78% java
 13082 root 143   00  654M  580M cpu/419 466:39 41.43% java
 13082 root 374   10  662M  589M cpu/323 547:47 47.03% java
 13082 root 374  100  662M  589M cpu/291 625:42 53.59% java
 Here the Thread count increases from 143 to 374 in just 10 min. Even 
though the no of user accessing this site has decreased. I really 
dont know what the problem is...
 I have set the Catalina Option as -Xms128M -Xmx512M but even 
setting the value of -XMx1024 doesn't solved my problem.

 The connector settings in my server.xml are as follows

 Connector className=org.apache.coyote.tomcat4.CoyoteConnector 
acceptCount=5 bufferSize=2048 connectionTimeout=2 debug=0 
disableUploadTimeout=false enableLookups=false maxProcessors=350 
minProcessors=5 port=8009 
protocolHandlerClassName=org.apache.jk.server.JkCoyoteHandler 
proxyPort=0 redirectPort=8443 scheme=http secure=false 
tcpNoDelay=true useURIValidationHack=false
 Factory 
className=org.apache.catalina.net.DefaultServerSocketFactory/
 /Connector

 Please tell me what is the problem with my configuration.  Please 
help me

 Thanks  Regards
 Mohit


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat Tuning Memory leak

2003-12-30 Thread David Rees

Mohit Gupta wrote:

I am working on Tomcat 4.1.24 on Solatis-8, 12 CPU, 24GB RAM Machine. 
I am using Apache 2.0.43 and the Jdk version is 1.4.1_02.

When I start my server then after 5-6 hours my server becomes very 
slow and then I need to restart my server. I am taking the top stats 
for the tomcat and have found that normally the thread remains between 
100- 140 but when the system crashes it reaches to 372 and the memory 
gradually increases from 256 to some where around 660. The top stats 
are as follows

   PID USERNAME THR PRI NICE  SIZE   RES STATETIMECPU COMMAND
 13082 root 115   00  653M  578M cpu/290 313:31 37.64% java
 13082 root 139   70  654M  579M cpu/291 388:08 40.78% java
 13082 root 143   00  654M  580M cpu/419 466:39 41.43% java
 13082 root 374   10  662M  589M cpu/323 547:47 47.03% java
 13082 root 374  100  662M  589M cpu/291 625:42 53.59% java
 Here the Thread count increases from 143 to 374 in just 10 min. Even 
though the no of user accessing this site has decreased. I really 
dont know what the problem is...
 I have set the Catalina Option as -Xms128M -Xmx512M but even 
setting the value of -XMx1024 doesn't solved my problem.

 The connector settings in my server.xml are as follows

 Connector className=org.apache.coyote.tomcat4.CoyoteConnector 
acceptCount=5 bufferSize=2048 connectionTimeout=2 debug=0 
disableUploadTimeout=false enableLookups=false maxProcessors=350 
minProcessors=5 port=8009 
protocolHandlerClassName=org.apache.jk.server.JkCoyoteHandler 
proxyPort=0 redirectPort=8443 scheme=http secure=false 
tcpNoDelay=true useURIValidationHack=false
 Factory 
className=org.apache.catalina.net.DefaultServerSocketFactory/
 /Connector

Please tell me what is the problem with my configuration.  Please 
help me
First thing to find out is to figure out what all the threads are doing. 
 Send the Tomcat process a -QUIT signal (`kill -QUIT 13082`) and 
capture the output which will be sent to stdout.  You will get a stack 
trace for each thread showing what it is doing.  You will probably find 
that the threads are busy somewhere in your application code.

Additionally, upgrading to the latest Tomcat (4.1.27 or 5.0.16) and JDK 
(1.4.2_03) is a good idea as the latest versions have bug fixes and 
performance improvements.

I doubt it is a Tomcat issue, it is more than likely an issue with your 
application, but the stack trace will show the cause.

-Dave

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat Tuning Memory leak

David Rees wrote:
Additionally, upgrading to the latest Tomcat (4.1.27 or 5.0.16) and JDK 
(1.4.2_03) is a good idea as the latest versions have bug fixes and 
performance improvements.

I doubt it is a Tomcat issue, it is more than likely an issue with your 
application, but the stack trace will show the cause.
I have tomcat 4.1.29, JDK1.4.2. Also my app was completely ok with 
tomcat 3.x.x. The 100% of processor time occurs in my case only after 
the OOME. Before the OOME all the threads (both tomcat's and mine) are 
happy.

Thanks for any hints,

David



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat Tuning Memory leak

2003-12-30 Thread Philipp Taprogge

Hi!

David Strupl wrote:
I have tomcat 4.1.29, JDK1.4.2. Also my app was completely ok with 
tomcat 3.x.x. The 100% of processor time occurs in my case only after 
the OOME. Before the OOME all the threads (both tomcat's and mine) are 
happy.
The processor usage is not too surprising. When your machine runs out 
of memory and there are still busy processes, most of the cpu time 
will go into swapping in and out those processes. Still, since most 
prople are perfectly happy with the tomcat build you are using, there 
seems to be a problem with your application code. Perhaps you could 
elaborate a bit further here?
And, as we had that subject a few days ago, are you by chance re-using 
StringBuffer instances ;-)

Regards,

	Phil

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat Tuning Memory leak

Philipp Taprogge wrote:
The processor usage is not too surprising. When your machine runs out of 
memory and there are still busy processes, most of the cpu time will go 
into swapping in and out those processes. Still, since most prople are 
perfectly happy with the tomcat build you are using, there seems to be a 
problem with your application code. Perhaps you could elaborate a bit 
further here?
And, as we had that subject a few days ago, are you by chance re-using 
StringBuffer instances ;-)
Yes - I was also not surprised with the CPU after the OOME. I will try 
to prepare a heap shapshot and post it here (only a link, don't worry) 
after I manage to get a usefull one.

My application does not do anything special - it is an online gaming 
server with couple of JSPs and servlets. The profiling has not revealed 
any memory leak in my code so far. Also the code was running for several 
years in tomcat 3.x without any problem. After migrating to tomcat 4.x 
the nightmare began.

Thanks for any hints,

David



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat Tuning Memory leak

2003-12-30 Thread Philipp Taprogge

Hi again!

David Strupl wrote:

 Also the code was running for several
years in tomcat 3.x without any problem. After migrating to tomcat 4.x 
the nightmare began.
Have you changed the JRE as well or are you running the tomcat 4 
instance in the same VM as the tomcat 3 before? Just to make sure your 
problems are not arising from changes made to the JVM in the meantime.

Regards,

		Phil

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat Tuning Memory leak

Philipp Taprogge wrote:
Have you changed the JRE as well or are you running the tomcat 4 
instance in the same VM as the tomcat 3 before? Just to make sure your 
problems are not arising from changes made to the JVM in the meantime.
I have upgraged the VM as well as the OS on the machine. In fact the 
whole machine is different now (being it dual-pentium this time). Right 
now I am further upgrading SUN JDK 1.4.2 to SUN 1.4.2_03 if that is 
going to have any impact.

David



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Tomcat Tuning Memory leak

2003-12-30 Thread Shapira, Yoav


Howdy,

Yes - I was also not surprised with the CPU after the OOME. I will try
to prepare a heap shapshot and post it here (only a link, don't worry)
after I manage to get a usefull one.

Make sure it's one before the OutOfMemoryError ;)

server with couple of JSPs and servlets. The profiling has not revealed
any memory leak in my code so far. Also the code was running for
several
years in tomcat 3.x without any problem. After migrating to tomcat 4.x
the nightmare began.

There's no doubt tomcat 4 (and 5's) memory usage characteristics are
significantly different from tomcat 3.  Nearly everything in the code is
significantly different.

Is it possible your app doesn't have any leaks, but simply needs more
memory under load than you're allocating it?

(BTW, to refresh my memory, is this setup where the JSP pages change
hourly?)

Yoav Shapira



This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat Tuning Memory leak

2003-08-14 Thread Mike Cherichetti \(Renegade Internet\)

Shapira, Yoav wrote:
(BTW, to refresh my memory, is this setup where the JSP pages change
hourly?)
I have already changed this ;-) Also added the fork attribute to true 
for jsp compile. It is not caused by the app - after the app starts and 
first 100 or so users connect the memory jumps up to approx 130 MB. But 
during the next 24 hours it eats more than 300 megs. From what I have 
seen from the profiler so far number of my objects is fairly decent. But 
there are more and more approx 100k (98320 chars) buffers created 
somewhere. I will post more precise info later after I
  a. upgrade to the latest and greatest JDK 1.4.2_03
  b. create some HTML output of the heap

Thanks for any hints so far, best regards,

David



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat Tuning Memory leak

2003-12-30 Thread James Black

David Strupl wrote:

I have already changed this ;-) Also added the fork attribute to true 
for jsp compile. It is not caused by the app - after the app starts 
and first 100 or so users connect the memory jumps up to approx 130 
MB. But during the next 24 hours it eats more than 300 megs. From what 
I have seen from the profiler so far number of my objects is fairly 
decent. But there are more and more approx 100k (98320 chars) buffers 
created somewhere. I will post more precise info later after I
  a. upgrade to the latest and greatest JDK 1.4.2_03
  b. create some HTML output of the heap 
 Your JSP page shouldn't have any business logic in it, that should be 
in beans that your JSP page uses. You can test the beans in a profiler 
and see if there is any memory leaks.

 If you are using JDK1.4.1 then that will probably be your problem as 
there was a memory leak in the String class that was fixed in JDK1.4.2.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

IIS/Tomcat tuning

2003-10-22 Thread Jean-René Blaive

Hello,

I would like to know your feeling about the IIS/Tomcat installation.
We know that Apache/Tomcat works well but what can we say about IIS/Tomcat ?
Is it reliable into production systems ?
If you could inform me about this question or send me some links.

Thanks for your job.
Jean-René Blaive.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: IIS/Tomcat tuning

2003-10-22 Thread jerome moliere

 Hello,

Hi Jean rene,
 I would like to know your feeling about the IIS/Tomcat installation. We
 know that Apache/Tomcat works well but what can we say about IIS/Tomcat
 ? Is it reliable into production systems ?
good question
TROLL
is IIS production ready
/TROLL
seems to be a troll but this is the main question...
mod_jk is a very reliable connector AJP (3) is a good protocol...
so your debts turn to have an answer for this TROLL:question
don't have much experience with IIS...

Tomcat (3.3 or 4.1.2x) are production ready releases...
tuning can be made by several tricks:
-config of tomcat
- JVM
- connectors

for robustness constraints don't forget to use:
load balancer facilities of the connectors
clustering features of Tomcat 4.1 version (is it useful for you ?)

 If you could inform me about this question or send me some links.

 Thanks for your job.

HTH
Jerome



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Tomcat cluster tuning

2003-09-12 Thread Ralph Einfeldt

Sorry can't give a recommendation.

We had different results even for (nearly) the same
software for different sites. For one site the IBM JDK 
worked best, for the other Sun's.

Any given result may be wothless with the next version 
of either jdk. (Even with just changes in the minor 
revision)

You have to test that
- in your environment
- with your application
- with the expected behaviour of the users

Even small changes in one of these setting can change 
the result which jdk is better for you. (At least that's 
our experience)

 -Original Message-
 From: Cristopher Daniluk [mailto:[EMAIL PROTECTED]
 Sent: Thursday, September 11, 2003 7:04 PM
 To: 'Tomcat Users List'
 Subject: RE: Tomcat cluster tuning
 
 
 Are there any recommendations for what JVM would work best?
 
 We're not doing anything fancy, so presumably any VM that works well
 with tomcat would work well for us. Are there any sites that 
 talk about
 the different JVM tuning options that affect Tomcat? I 
 haven't seen that
 many.
 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Tomcat cluster tuning

2003-09-11 Thread Cristopher Daniluk

We are runing a cluster of 3 apache servers and 2 tomcat servers
connected via AJP w/Oracle on backend.

The cluster has been performing very well but we've had a recent load
spike that's causing the tomcat servers to start swapping pretty
hardcore despite JVM limitations.

What is the -Xmx option limiting? Threads? Defined services? Instances
of Tomcat?

I would've thought that it would limit the entire tomcat instance, but
we have been far exceeding the 768mb limit we set.

We're connecting to Oracle on the back end via the JDBC thin client.
When the site starts swapping, performance on Oracle queries goes
exponentially downhill. A non-db page takes about 1 second to load
before swapping, vs 5 seconds to load when its swapping. On the other
hand, a db intensive page takes about 5 seconds to load normally, vs
about 40-50 seconds when it begins to swap. That number begins to crawl
quickly up until it exceeds the 5 minute max execution time and Tomcat
cuts the request off.

The servers are basically identically configured P1.8ghz machines with
1gb ram each. The connector line from server.xml is:

  Connector
className=org.apache.coyote.tomcat4.CoyoteConnector
port=8009 minProcessors=5 maxProcessors=100
enableLookups=true redirectPort=8443
acceptCount=100 debug=0 connectionTimeout=-1
 
protocolHandlerClassName=org.apache.jk.server.JkCoyoteHandler
/

And we're running Apache 2.0.47 w/mod_jk1 and AJP1.3. the
workers.properties is set to nonweighted balancing.

Are there any options to tune tomcat to reduce memory footpritn and to
let it queue more? We were initially running more maxProcessors but I
turned it down hoping to alleviate the congestion. Tried turning it up
thinking maybe the accept queue was the problem too, but that made it
worse.

Thanks,

Cris



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Tomcat cluster tuning

2003-09-11 Thread Ralph Einfeldt

mx is limiting the heap of a java process.

In other words:
It limits the total heap for one tomcat instance.

The total memory can be much higher:

- stacksize per thread
  Some vm's let you set these values (-Xss).
  If you have some hundred of threads that can make up some memory.

- static memory (like string constants, the code, ...)
  That pretty much defined at compile time.

- and may be further sorts of memories that depend on 
  the vendor and version of the jdk.

Regarding your config:

You can try to play with the combination of
maxProcessors
connectionTimeout
acceptCount

I'm not shure how the accepted but not processed 
request are handled (wether they are queued in one
thread, or if each has it's own thread)

There isn't much more you can change in tomcat.
The best recommendation I have is to find out where 
the memory comes from and either to cure the cause or
find out that you have to live with that memory usage
and spend more memory.

 -Original Message-
 From: Cristopher Daniluk [mailto:[EMAIL PROTECTED]
 Sent: Thursday, September 11, 2003 5:33 PM
 To: [EMAIL PROTECTED]
 Subject: Tomcat cluster tuning
 
 
 
 What is the -Xmx option limiting? Threads? Defined services? Instances
 of Tomcat?
 
 I would've thought that it would limit the entire tomcat instance, but
 we have been far exceeding the 768mb limit we set.
 
 
   Connector
 className=org.apache.coyote.tomcat4.CoyoteConnector
 port=8009 minProcessors=5 maxProcessors=100
 enableLookups=true redirectPort=8443
 acceptCount=100 debug=0 connectionTimeout=-1
  
 protocolHandlerClassName=org.apache.jk.server.JkCoyoteHandler
 /
 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Tomcat cluster tuning

2003-09-11 Thread Cristopher Daniluk

Are there any recommendations for what JVM would work best?

We're not doing anything fancy, so presumably any VM that works well
with tomcat would work well for us. Are there any sites that talk about
the different JVM tuning options that affect Tomcat? I haven't seen that
many.

-Original Message-
From: Ralph Einfeldt [mailto:[EMAIL PROTECTED] 
Sent: Thursday, September 11, 2003 12:46 PM
To: Tomcat Users List
Subject: RE: Tomcat cluster tuning


mx is limiting the heap of a java process.

In other words:
It limits the total heap for one tomcat instance.

The total memory can be much higher:

- stacksize per thread
  Some vm's let you set these values (-Xss).
  If you have some hundred of threads that can make up some memory.

- static memory (like string constants, the code, ...)
  That pretty much defined at compile time.

- and may be further sorts of memories that depend on 
  the vendor and version of the jdk.

Regarding your config:

You can try to play with the combination of
   maxProcessors
   connectionTimeout
   acceptCount

I'm not shure how the accepted but not processed 
request are handled (wether they are queued in one
thread, or if each has it's own thread)

There isn't much more you can change in tomcat.
The best recommendation I have is to find out where 
the memory comes from and either to cure the cause or
find out that you have to live with that memory usage
and spend more memory.

 -Original Message-
 From: Cristopher Daniluk [mailto:[EMAIL PROTECTED]
 Sent: Thursday, September 11, 2003 5:33 PM
 To: [EMAIL PROTECTED]
 Subject: Tomcat cluster tuning
 
 
 
 What is the -Xmx option limiting? Threads? Defined services? 
Instances 
 of Tomcat?
 
 I would've thought that it would limit the entire tomcat 
instance, but 
 we have been far exceeding the 768mb limit we set.
 
 
   Connector 
 className=org.apache.coyote.tomcat4.CoyoteConnector
 port=8009 minProcessors=5 maxProcessors=100
 enableLookups=true redirectPort=8443
 acceptCount=100 debug=0 connectionTimeout=-1
  
 protocolHandlerClassName=org.apache.jk.server.JkCoyoteHandler
 /
 

-
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]

RE: Tuning KeepAlive Connections?

That didn't work.  Got the following in logs/catalina.out when I tried that:

Aug 7, 2003 11:40:45 PM org.apache.coyote.http11.Http11Processor process
WARNING: Error parsing HTTP request
java.lang.IllegalArgumentException: timeout can't be negative
at java.net.Socket.setSoTimeout(Socket.java:920)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:572)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConne
ction(Http11Protocol.java:392)
at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:565)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav
a:619)
at java.lang.Thread.run(Thread.java:568)

Have a nice day ...

Sincerely,

Mike Cherichetti
Renegade Internet
Internet Advertising Delivery Solutions
www.renegadeinternet.com
Phone (724) 658-6346
Fax (724) 658-6346


-Original Message-
From: Venkata Srinivasa Rao, Yerra [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 07, 2003 10:21 PM
To: Tomcat Users List
Subject: Re: Tuning KeepAlive Connections?


To disable connection timeouts, set connectionTimeout value to -1
At 02:09 PM 8/7/2003 -0400, you wrote:
RedHat Linux 7.3
IBM JDK 1.4.1
Tomcat 4.1.24

Is it possible to disable KeepAlive connections with the Coyote HTTP/1.1
connector?  If it's not possible to turn them off, is it possible to lower
the request limit and timeout period for them?

Have a nice day ...

Sincerely,

Mike Cherichetti
Renegade Internet
www.renegadeinternet.com
Phone (724) 658-6346
Fax (724) 658-6346




-
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]

Re: Tuning KeepAlive Connections?

2003-08-14 Thread Bill Barker

You can (effectively) disable KeepAlive connections by setting the
'maxKeepAliveRequests=1' attribute on the Connector.  Tomcat 5 has a more
intuitive option, but it works the same way.

If you have the maxKeepAliveRequests  1, then the 'connectionTimeout'
attribute on the Connector determines how long it will wait for the next
request.

Mike Cherichetti (Renegade Internet) [EMAIL PROTECTED] wrote in
message news:[EMAIL PROTECTED]
 RedHat Linux 7.3
 IBM JDK 1.4.1
 Tomcat 4.1.24

 Is it possible to disable KeepAlive connections with the Coyote HTTP/1.1
 connector?  If it's not possible to turn them off, is it possible to lower
 the request limit and timeout period for them?

 Have a nice day ...

 Sincerely,

 Mike Cherichetti
 Renegade Internet
 www.renegadeinternet.com
 Phone (724) 658-6346
 Fax (724) 658-6346




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tuning KeepAlive Connections?

2003-08-14 Thread Bill Barker


Mike Cherichetti (Renegade Internet) [EMAIL PROTECTED] wrote in
message news:[EMAIL PROTECTED]
 Hi Bill,

 Thanks for the info!  Looks like that helped, but I can't tell for sure
 because the server isn't loaded too much right now.  Will have to wait
until
 morning to find out.  Did I miss something or is that not in the docs?
 Might be good to add this to the docs :)


I believe that it is in the TC 5 docs (without looking).  And yes, it would
be a good idea to add it to the TC 4 docs ;-).

 Thanks again,
 Mike

 -Original Message-
 From: news [mailto:[EMAIL PROTECTED] Behalf Of Bill Barker
 Sent: Friday, August 08, 2003 12:00 AM
 To: [EMAIL PROTECTED]
 Subject: Re: Tuning KeepAlive Connections?


 You can (effectively) disable KeepAlive connections by setting the
 'maxKeepAliveRequests=1' attribute on the Connector.  Tomcat 5 has a
more
 intuitive option, but it works the same way.

 If you have the maxKeepAliveRequests  1, then the 'connectionTimeout'
 attribute on the Connector determines how long it will wait for the next
 request.

 Mike Cherichetti (Renegade Internet) [EMAIL PROTECTED] wrote
in
 message news:[EMAIL PROTECTED]
  RedHat Linux 7.3
  IBM JDK 1.4.1
  Tomcat 4.1.24
 
  Is it possible to disable KeepAlive connections with the Coyote HTTP/1.1
  connector?  If it's not possible to turn them off, is it possible to
lower
  the request limit and timeout period for them?
 
  Have a nice day ...
 
  Sincerely,
 
  Mike Cherichetti
  Renegade Internet
  www.renegadeinternet.com
  Phone (724) 658-6346
  Fax (724) 658-6346




 -
 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]

Re: Tuning KeepAlive Connections?

2003-08-14 Thread Venkata Srinivasa Rao, Yerra

To disable connection timeouts, set connectionTimeout value to -1
At 02:09 PM 8/7/2003 -0400, you wrote:
RedHat Linux 7.3
IBM JDK 1.4.1
Tomcat 4.1.24
Is it possible to disable KeepAlive connections with the Coyote HTTP/1.1
connector?  If it's not possible to turn them off, is it possible to lower
the request limit and timeout period for them?
Have a nice day ...

Sincerely,

Mike Cherichetti
Renegade Internet
www.renegadeinternet.com
Phone (724) 658-6346
Fax (724) 658-6346


-
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]

Tuning KeepAlive Connections?

2003-08-09 Thread Mike Cherichetti \(Renegade Internet\)

RedHat Linux 7.3
IBM JDK 1.4.1
Tomcat 4.1.24

Is it possible to disable KeepAlive connections with the Coyote HTTP/1.1
connector?  If it's not possible to turn them off, is it possible to lower
the request limit and timeout period for them?

Have a nice day ...

Sincerely,

Mike Cherichetti
Renegade Internet
www.renegadeinternet.com
Phone (724) 658-6346
Fax (724) 658-6346




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Tuning KeepAlive Connections?

2003-08-08 Thread Mike Cherichetti \(Renegade Internet\)

Hi Bill,

Thanks for the info!  Looks like that helped, but I can't tell for sure
because the server isn't loaded too much right now.  Will have to wait until
morning to find out.  Did I miss something or is that not in the docs?
Might be good to add this to the docs :)

Thanks again,
Mike

-Original Message-
From: news [mailto:[EMAIL PROTECTED] Behalf Of Bill Barker
Sent: Friday, August 08, 2003 12:00 AM
To: [EMAIL PROTECTED]
Subject: Re: Tuning KeepAlive Connections?


You can (effectively) disable KeepAlive connections by setting the
'maxKeepAliveRequests=1' attribute on the Connector.  Tomcat 5 has a more
intuitive option, but it works the same way.

If you have the maxKeepAliveRequests  1, then the 'connectionTimeout'
attribute on the Connector determines how long it will wait for the next
request.

Mike Cherichetti (Renegade Internet) [EMAIL PROTECTED] wrote in
message news:[EMAIL PROTECTED]
 RedHat Linux 7.3
 IBM JDK 1.4.1
 Tomcat 4.1.24

 Is it possible to disable KeepAlive connections with the Coyote HTTP/1.1
 connector?  If it's not possible to turn them off, is it possible to lower
 the request limit and timeout period for them?

 Have a nice day ...

 Sincerely,

 Mike Cherichetti
 Renegade Internet
 www.renegadeinternet.com
 Phone (724) 658-6346
 Fax (724) 658-6346




-
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]

RE: JVM tuning

2003-08-04 Thread Shapira, Yoav


Howdy,

Has anyone got any clues on JVM tuning for Tomcat on Windows 2000, Sun
141

I would venture at least a few people on this list have clues.  But it's
impossible to help you without a clue about your webapp.

Yoav Shapira



This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: JVM tuning

Hmm well only a profiler could tell me that;  I was more looking for some 
(subsequently discovered) things such as you should reseize the young 
generation to be much larger than the default 25% and so on;  there are 
some rules of thumb such as this which I was looking for!
cheers
Pete





Shapira, Yoav [EMAIL PROTECTED]
04/08/2003 14:16
Please respond to Tomcat Users List
 
To: Tomcat Users List [EMAIL PROTECTED]
cc: 
Subject:RE: JVM tuning



Howdy,

Has anyone got any clues on JVM tuning for Tomcat on Windows 2000, Sun
141

I would venture at least a few people on this list have clues.  But it's
impossible to help you without a clue about your webapp.

Yoav Shapira



This e-mail, including any attachments, is a confidential business 
communication, and may contain information that is confidential, 
proprietary and/or privileged.  This e-mail is intended only for the 
individual(s) to whom it is addressed, and may not be saved, copied, 
printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your 
computer system and notify the sender.  Thank you.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: JVM tuning

2003-08-04 Thread Shapira, Yoav

Howdy,

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Sent: Monday, August 04, 2003 9:27 AM
To: Tomcat Users List
Subject: RE: JVM tuning

Hmm well only a profiler could tell me that;  I was more looking for
some
(subsequently discovered) things such as you should reseize the young
generation to be much larger than the default 25% and so on;  there are
some rules of thumb such as this which I was looking for!

I would argue any such rule of thumb is as likely to hurt performance as
improve it for your specific app.

Yoav Shapira
Millennium ChemInformatics

This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: JVM tuning

Well not really; we know that we are running Tomcat, a web container which 
has its own (fixed) characteristics.  It is a server side app which is 
processing non state based transactions which are thus highly like to 
involve a lot of objects being created and destroyed without too many 
hanging around for long;  the details of the webapp, unless it is highly 
unusual, are likely not to matter particularly.  This is a rule of thumb 
not an exact science and the vast majority of people who run Tomcat would 
benefit from running in such a configuration (or playing with it to see 
what the effects were) - read Sun's own tuning documentation and you will 
see the default settings are not said to be suitable for the majority of 
server apps.
cheers
Pete





Shapira, Yoav [EMAIL PROTECTED]
04/08/2003 14:29
Please respond to Tomcat Users List
 
To: Tomcat Users List [EMAIL PROTECTED]
cc: 
Subject:RE: JVM tuning



Howdy,

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Sent: Monday, August 04, 2003 9:27 AM
To: Tomcat Users List
Subject: RE: JVM tuning

Hmm well only a profiler could tell me that;  I was more looking for
some
(subsequently discovered) things such as you should reseize the young
generation to be much larger than the default 25% and so on;  there are
some rules of thumb such as this which I was looking for!

I would argue any such rule of thumb is as likely to hurt performance as
improve it for your specific app.

Yoav Shapira
Millennium ChemInformatics



This e-mail, including any attachments, is a confidential business 
communication, and may contain information that is confidential, 
proprietary and/or privileged.  This e-mail is intended only for the 
individual(s) to whom it is addressed, and may not be saved, copied, 
printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your 
computer system and notify the sender.  Thank you.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: JVM tuning

2003-08-04 Thread Shapira, Yoav


Howdy,

Well not really; we know that we are running Tomcat, a web container
which
has its own (fixed) characteristics.  It is a server side app which is
processing non state based transactions which are thus highly like to
involve a lot of objects being created and destroyed without too many
hanging around for long;  the details of the webapp, unless it is
highly
unusual, are likely not to matter particularly.  This is a rule of
thumb
not an exact science and the vast majority of people who run Tomcat
would
benefit from running in such a configuration (or playing with it to see
what the effects were)

I disagree ;)

Every time I've tuned a webapp for pay, both transactional and not, both
full J2EE and just servlets/JSPs, the above has been false.  The
webapp's specific implementation matters far more (typically 3-4 orders
of magnitude) than the container implementation, especially for a mature
container which has been tuned repetitively and carefully over time.
It's precisely because of this, and because as you say performance
tuning is not a science, that a rule of thumb is as likely to hurt as it
is to help if blindly applied.

 read Sun's own tuning documentation and you will
see the default settings are not said to be suitable for the majority
of
server apps.

I appreciate the pointer - I used to help write them ;)

Good luck, however, as it's always YMMV with these things.

Yoav Shapira



This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: JVM tuning

Ah sorry I should really have said that I was focusing specifically on 
memory managment; general performance tuning is a completely different 
matter in which I do agree with you!  On the memory front however I would 
stand by the fact that most tomcat webapps (big or small) would benefit 
from a change in the default JVM config.

Anyway, have sorted out my problem now (by doing just that as well as a GC 
change) and performance is 10x better!

cheers
Pete





Shapira, Yoav [EMAIL PROTECTED]
04/08/2003 14:45
Please respond to Tomcat Users List
 
To: Tomcat Users List [EMAIL PROTECTED]
cc: 
Subject:RE: JVM tuning



Howdy,

Well not really; we know that we are running Tomcat, a web container
which
has its own (fixed) characteristics.  It is a server side app which is
processing non state based transactions which are thus highly like to
involve a lot of objects being created and destroyed without too many
hanging around for long;  the details of the webapp, unless it is
highly
unusual, are likely not to matter particularly.  This is a rule of
thumb
not an exact science and the vast majority of people who run Tomcat
would
benefit from running in such a configuration (or playing with it to see
what the effects were) 

I disagree ;)

Every time I've tuned a webapp for pay, both transactional and not, both
full J2EE and just servlets/JSPs, the above has been false.  The
webapp's specific implementation matters far more (typically 3-4 orders
of magnitude) than the container implementation, especially for a mature
container which has been tuned repetitively and carefully over time.
It's precisely because of this, and because as you say performance
tuning is not a science, that a rule of thumb is as likely to hurt as it
is to help if blindly applied.

 read Sun's own tuning documentation and you will
see the default settings are not said to be suitable for the majority
of
server apps.

I appreciate the pointer - I used to help write them ;)

Good luck, however, as it's always YMMV with these things.

Yoav Shapira



This e-mail, including any attachments, is a confidential business 
communication, and may contain information that is confidential, 
proprietary and/or privileged.  This e-mail is intended only for the 
individual(s) to whom it is addressed, and may not be saved, copied, 
printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your 
computer system and notify the sender.  Thank you.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: JVM tuning

2003-08-04 Thread Angus Mezick

Wouldn't AdaptiveSizePolicy help? (saves you the work of Java Heap usage
analyzing :-) :

I use this on my 2x proc machine.

-XX:UseParallelGC -XX:+UseAdaptiveSizePolicy

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] 
 Sent: Monday, August 04, 2003 9:55 AM
 To: Tomcat Users List
 Subject: RE: JVM tuning
 
 
 Ah sorry I should really have said that I was focusing 
 specifically on 
 memory managment; general performance tuning is a completely 
 different 
 matter in which I do agree with you!  On the memory front 
 however I would 
 stand by the fact that most tomcat webapps (big or small) 
 would benefit 
 from a change in the default JVM config.
 
 Anyway, have sorted out my problem now (by doing just that as 
 well as a GC 
 change) and performance is 10x better!
 
 cheers
 Pete
 
 
 
 
 
 Shapira, Yoav [EMAIL PROTECTED]
 04/08/2003 14:45
 Please respond to Tomcat Users List
  
 To: Tomcat Users List [EMAIL PROTECTED]
 cc: 
 Subject:RE: JVM tuning
 
 
 
 Howdy,
 
 Well not really; we know that we are running Tomcat, a web container
 which
 has its own (fixed) characteristics.  It is a server side 
 app which is
 processing non state based transactions which are thus highly like to
 involve a lot of objects being created and destroyed without too many
 hanging around for long;  the details of the webapp, unless it is
 highly
 unusual, are likely not to matter particularly.  This is a rule of
 thumb
 not an exact science and the vast majority of people who run Tomcat
 would
 benefit from running in such a configuration (or playing 
 with it to see
 what the effects were) 
 
 I disagree ;)
 
 Every time I've tuned a webapp for pay, both transactional 
 and not, both
 full J2EE and just servlets/JSPs, the above has been false.  The
 webapp's specific implementation matters far more (typically 
 3-4 orders
 of magnitude) than the container implementation, especially 
 for a mature
 container which has been tuned repetitively and carefully over time.
 It's precisely because of this, and because as you say performance
 tuning is not a science, that a rule of thumb is as likely to 
 hurt as it
 is to help if blindly applied.
 
  read Sun's own tuning documentation and you will
 see the default settings are not said to be suitable for the majority
 of
 server apps.
 
 I appreciate the pointer - I used to help write them ;)
 
 Good luck, however, as it's always YMMV with these things.
 
 Yoav Shapira
 
 
 
 This e-mail, including any attachments, is a confidential business 
 communication, and may contain information that is confidential, 
 proprietary and/or privileged.  This e-mail is intended only for the 
 individual(s) to whom it is addressed, and may not be saved, copied, 
 printed, disclosed or used by anyone else.  If you are not the(an) 
 intended recipient, please immediately delete this e-mail from your 
 computer system and notify the sender.  Thank you.
 
 
 -
 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]

RE: JVM tuning