-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Leo,
On 12/2/14 5:12 PM, Leo Donahue wrote: > On Tue, Dec 2, 2014 at 3:28 PM, Chris Gamache <cgama...@gmail.com> > wrote: > >> You could probably be more sophisticated in your throttling, >> letting certain IPs or requests through while tarpitting others. >> >> I was thinking about how, from my perspective, I see developers >> wanting to > throttle back the number of requests to their web applications (and > web services) based on the same ip, session, and other factors > appearing in a given amount of time. > > I know that some frameworks (Spring) provide this mechanism, and I > have seen other projects attempt to record the information in a > database and produce application specific logic to restrict the > number of requests in a given amount of time. > > I didn't know if anyone has considered a container provided filter > that is configurable to provide this kind of functionality. "This > kind of functionality" is ambiguous I know. But I would settle on > even the basic ability to say: For this web service/app, allow > only x many connections per sec/min/hour. FWIW, Tomcat already captures stats like requests per unit time. You can find them on the connector's MBean (I think... don't have time to check just now). A Filter wanting to simply limit the total server throughput (e.g. 10k/sec) could consult that data and simply return 503 responses if the server were handling too much load. I'd recommend making the limit for that Filter configurable through JMX or some other means, so you can take the cap off it you think that you can handle more load... you don't want to restart your webapp just to change the load-cap. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUglmfAAoJEBzwKT+lPKRYmWYP/05x4TViGO4tz1FTfd2q81+7 RWYvGjk/S7ItedwflGLWO/yCSAweIsB+Gh+9qcbhyh2xn6u1xVZuSEBHyUsqCuQE VLtbyEf05VSQ26ju4sLkT9XY8o379udb+Svk7/IRakhba2EKxuZSYz/L8dHwNjja suoNA40Nhm8qyySfSzHFrIcyz7okuJxV3GXMU5048RD+BN1M/IImSqps/osDXy1k yqXX2+KUPfC/S6kO5zttNZATSLhAirccAoqan6NfonyNbZOc/6d6Am5ZnTwHf7Sm eefbloWoN2I4n3KAGOHeRBmZpHubGGG+ZFRof/ir+2K44mwfmwWi1EL9gjIjyu7P dck9wWw1+LdtNZLBfgXTVTUCyfz/V1XagzyfCl7TqKHDxv2TQuz9pm8GAcixpEKz Ch9oszWwit+tRNvXwUwX8M/7NmOaLkZ2o9ouJe+CcfPw/cm1vI90bcVagR4oqFmA TJRU8KhXp3FsApyx6KGzsMiDVO6GTIyVMux4t9V5/6huwU1z1VAaT2Vri48JTXFw Edl6Pm5rss0X4PwtMgZAoG3MipbboE3Xufkvpo3sQ/XJ/Hxq9OFwD6Qmwx0+Ezoi xtIAUbAAu9Di4FCE75GxTV5Tm5dCGg2dHoIpF1Nv0KmU+2+QLELB3bF6SBANAwvx dTOOk4pS91Ir2DWeDlIE =86pY -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
