How does the Tomcat Manager guess at user name?
The Sessions Administration page within the Tomcat Manager (i.e., /manager/html/sessions?path=/) has two columns for Guessed Locale and Guessed User name. Does anyone know how the manager app guesses at these two values? My app stores the user's username (and locale) in session, but both are buried somewhere in an object graph in one of the session attributes. I think it might be kind of useful to be able to see this data displayed within Session Administration, but I just have no idea what to do to enable Tomcat Manager to effectively guess at this. Does anyone know how the guessing is done? Thanks Matt Brown Citrix Online Audio Services matt.br...@citrix.commailto:matt.br...@citrix.com 201-420-1155 x42
RE: Question on Executor and maxThreads reported by Manager
Actually yes, in our case the image content is not already sufficiently compressed by the content provider - we're seeing a sizeable decrease in the size of the images delivered after enabling gzip on them. Good question though, thank you. -Matt -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Thursday, March 19, 2009 11:18 PM To: Tomcat Users List Subject: Re: Question on Executor and maxThreads reported by Manager -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matt, On 3/19/2009 1:37 PM, Matt Brown wrote: compression=on compressableMimeType=..., image/png,image/jpeg,image/gif Are you sure you want to waste your CPU time compressing files that are already compressed? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAknDCukACgkQ9CaO5/Lv0PA/nwCfVzUS9FGGbGsLBGF2kO1Bec56 skYAoIsMDDwHOCQWxZWi/KVTzjW8S/SI =gLAQ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Question on Executor and maxThreads reported by Manager
Here are some quick numbers (provided by YSlow) from the home page of this webapp: Without gzip compression on image/png,image/jpeg,image/gif: 133.1K 12 Images With gzip compression: 1.7K 12 Images ..,Actually now that I'm looking in detail at the numbers reported for each individual image by YSLow, I'm starting to think that it doesn't calculate the size of gzipped images correctly. Here were the largest size images on this page pre-compression (I've removed the filenames): jpg 43.8K jpg 39.4K jpg 31.1K gif 7.4K png 4.5K gif 2.5K gif 2.4K With compression turned on: jpg gzip 0K gif gzip0K gif gzip0K gif gzip0K jpg gzip0K jpg gzip0K png gzip0K Seems like my earlier findings were incorrect based on this - surely gzip is not capable of compressing images to zero byte files :) I should have looked further into the total size number reported by Yslow instead of taking it for granted as being correct. Thanks again for pointing this out, I'll likely go ahead and disable these types from wastefully being recompressed on the server. -Matt -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Friday, March 20, 2009 10:16 AM To: Tomcat Users List Subject: Re: Question on Executor and maxThreads reported by Manager -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matt, On 3/20/2009 9:10 AM, Matt Brown wrote: Actually yes, in our case the image content is not already sufficiently compressed by the content provider - we're seeing a sizeable decrease in the size of the images delivered after enabling gzip on them. You may be able to re-code some of these graphics using higher compression (better results with PNG) or lower quality (for JPG) though lower quality will always be... lower quality. Interesting that gzip does a good job with these files. Can you give some metrics? I'd be interested to see how well it does. Is this for a mobile application? Or are you just trying to reduce bandwidth use in general? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAknDpScACgkQ9CaO5/Lv0PDjMwCeMdwZw7SzUVH6YXjkAkzzECu8 Mg4AnRyjK+WCorIkVCFcCyFMFKhnZByW =+4e5 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: very off topic marketing question
I would ask for benchmarks and evidence to back up that assertion. -Original Message- From: Jason Pyeron [mailto:jpye...@pdinc.us] Sent: Friday, March 20, 2009 11:04 AM To: 'Tomcat Users List' Subject: very off topic marketing question I have a client that is confused why we are giving them a J2EE product and they are concerned with performance and scalability. (IE/Tomcat 5.5/struts 2.1/hibernate 3.x/oracle 10g) Note the system will never see more than 50 users/sessions with 7500 hits per day on a lan. As such we don't see any relevance as to the performance and scalability issues for either PHP or J2EE. They have quoted to us: PHP by itself is very fast. Much faster than ASP or JSP running on the same type of server. This is because it has very little overhead compared to its competitors and it pre-compiles all of its code before it runs each script How would others respond to this? -Jason -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Question on Executor and maxThreads reported by Manager
In my conf/server.xml, I have an executor and two connectors set up something like this: Executor name=tomcatThreadPool namePrefix=catalina-exec- maxThreads=200 minSpareThreads=50/ Connector port=8686 protocol=HTTP/1.1 connectionTimeout=2 maxThreads=250 executor=tomcatThreadPool redirectPort=8643 compression=on compressableMimeType=text/html,text/xml,text/plain,text/javascript,text/css,image/png,image/jpeg,image/gif / Connector port=8643 protocol=HTTP/1.1 SSLEnabled=true maxThreads=250 executor=tomcatThreadPool scheme=https secure=true clientAuth=false sslProtocol=TLS compression=on compressableMimeType=text/html,text/xml,text/plain,text/javascript,text/css,image/png,image/jpeg,image/gif / My intention is to have the two connectors share a thread pool with a maximum thread count of 200, and minSpareThreads of 50. When I check the server info in Tomcat Manager, the max thread count for each connector is reported as 250 (the value of maxThreads in each Connector element, which I expect to be ignored because 'executor' is present) and not 200. When using a shared thread pool, should I expect the Manager to report the incorrect amount of max threads per connector, or is something wrong with my configuration? Will the Manager report on the size/limits of the shared thread pool? Thanks Matt
RE: Question on Executor and maxThreads reported by Manager
Thanks Charles. I was using the Manager to confirm if my settings for the thread pool (particularily minSpareThreads) were working right - I'll have to confirm with jconsole. We have a monitoring app that pings /manager/status?XML=true to get mem usage, thread activity/count/stats, etc., so it sounds like our stats for max threads might not reflect the true settings? Thanks again -Original Message- From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] Sent: Thursday, March 19, 2009 2:07 PM To: Tomcat Users List Subject: RE: Question on Executor and maxThreads reported by Manager From: Matt Brown [mailto:matt.br...@citrixonline.com] Subject: Question on Executor and maxThreads reported by Manager When I check the server info in Tomcat Manager, the max thread count for each connector is reported as 250 (the value of maxThreads in each Connector element, which I expect to be ignored because 'executor' is present) and not 200. Just because it's reported doesn't mean it's not being ignored. (Were there enough negatives in that sentence?) When using a shared thread pool, should I expect the Manager to report the incorrect amount of max threads per connector, or is something wrong with my configuration? I don't see anything wrong with your config. The manager is just reporting what's there, and is blissfully unaware that you're actually using an Executor, so the maxThreads setting is meaningless. Will the Manager report on the size/limits of the shared thread pool? I don't think anyone has ever tried to update the manager webapp to do that (patches are welcome). You can see the Executor and its threads with JConsole. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
