-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Supun,
On 3/12/19 12:05, Supun Abeysinghe wrote: > I am working on a project where the parameters of the tomcat server > (e.g. MaxThreads, MinSpareThreads, MaxSpareThreads etc.) for a > given web application is auto-tuned using a machine learning > technique by looking at the runtime characteristics (e.g. workload > characteristics, current performance etc.). I'm kind of curious about this. Is this Nest[1] for Tomcat? My experience is that traffic is bursty. That means that it's hard to predict when you'll need more resources -- like threads, one of the only things you can really tune at runtime. When you need them, you want them NOW, not when some algorithm finally gets around to detecting the burst of traffic you know has already begun. Since the server must be planned for X number of threads at peak volume, why not simply always run with X threads? There is really no penalty for leaving threads unused, other than "wasted" memory... that you would need if you needed the threads, anyway. It's not like you can use that memory for anything else, because you're going to need it at peak-load time. If you are interested in doing ML for capacity-tuning, I'd look more toward auto-scaling of *instances* rather than the resources being used by one single Tomcat instance. If I can scale-down my VMs deployed into, say, AWS, then I can save *real money* by scaling-back during low-load times and learning about trends to pre-scale things before e.g. the Friday-night rush or whatever happens to be "peak volume" for my particular use-case. - -chris [1] https://nest.com/thermostats/ -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlyIXA8ACgkQHPApP6U8 pFhIexAAhhyCaSiQLaTlS3ySTzF5hHuH9Ft2TVXV8rC1/nOA11zelkQRad1Dpd1Z Ywks+Ag0OaZryld+S/oDCg2hbZEJ4yp2lCKhib9Vk85TGO6DnLM17Ul6Z7XOGstQ gQagjNBCd+lpRuaJ/d1esx1zhzUxD8eTSMRNGP1eZcOTRFUekQpSPlaEmJiczTdo /X79kL/NPV2evmJXlXrzBToqLPqpNVUrQMNmu6QZcwEP4eXNIaGIiUTD6WqnnHeJ jSppwqk/++RXJa2P17+6cue5fmyoUHcVKOypwYye6c7deEXPR5Kx8Nvdl/IB4VJU GsEhce9L+4R0EGRsgBEi0VW5OK4SxDYtmi+hdPxHDFXz1hocwAu3R0zdZspwJYo6 ESFepwnvEA/yfrNJD/dkoVrndejuZQjBRHkTRDh4ELj/ce/jFW3q0WjESVTz0Mmt jrwnZsbqQ+qAFgcvYqQnBAyHguiJTfuRpDAg0kkkPfXLay65ESU5j8tAmoHR1S+V utuZOaStzFnDl0VRyFMhPzU0K32w29bpp0wSpb6COgwkIha1TDOIrVJTBlT5sjhr 0tXo2ex4TZXdGVkeGqwCGmu2SNZQcPSp3qVbYGzZ/w1duvqlPFoBkxpk04dWFEc1 6eixdMxP3fb0KAiowXbk3VFtLJblkzzum3+UavxB8+vOCn2v2kg= =Q1Uk -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
