Re: Question on Executor and maxThreads reported by Manager
Christopher Schultz wrote: Seems like my earlier findings were incorrect based on this - surely gzip is not capable of compressing images to zero byte files :) It's using the new ∞-compressor. It's a new breed of super-lossy algorithms. It's practical applications are as yet unknown. I heard of that one too. I think it is just looking at the pictures and throwing away the irrelevant or ugly ones. Most of the ones in webpages turn out to be, hence the compression factor. Conme to think of it, we could try and turn it loose on the messages of this list, see how it does with text. - 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
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
-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
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: Question on Executor and maxThreads reported by Manager
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matt, On 3/20/2009 10:34 AM, Matt Brown wrote: 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 Wow, that's incredible. You must have non-compressed PNGs or something. Seems like my earlier findings were incorrect based on this - surely gzip is not capable of compressing images to zero byte files :) It's using the new ∞-compressor. It's a new breed of super-lossy algorithms. It's practical applications are as yet unknown. I should have looked further into the total size number reported by Yslow instead of taking it for granted as being correct. I suspect what you're seeing from Yslow is an aggregate including the text files, etc. Text files, of course, compress /very/ well using gzip and other similar compression algorithms. Thanks again for pointing this out, I'll likely go ahead and disable these types from wastefully being recompressed on the server. Yeah, unless you are serving images to mobile devices or some other application where bandwidth is significantly limited, (re-)compressing images is counter-productive: you waste a lot of CPU time getting 0.5% compression ratios for your trouble. Good luck, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAknD+4oACgkQ9CaO5/Lv0PB/HgCeJ/mMuheNkfWR+qweAJKRiF0x uoIAoLKm85ljimsmYqt1ItGFtbr821QQ =2g1j -END PGP SIGNATURE- - 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
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
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
RE: Question on Executor and maxThreads reported by Manager
From: Matt Brown [mailto:matt.br...@citrixonline.com] Subject: RE: Question on Executor and maxThreads reported by Manager 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? Correct, they won't be applicable when using an Executor. Looks like LambdaProbe gets it wrong as well. You could use JMX to retrieve the correct information, just like JConsole does. You might want to look into MoSKito: http://moskito.anotheria.net/ - 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
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
