Hi Amos , Thank you for your reply , We ll you correct corresponding to TCP/HTTP . but my main concern is here its just POST/GET with single reply from our API server . Its just one TCP connection one HTTP connection . But yes i will work on other solutions since squid is not the right place for that . Thanks a lot ! > On Nov 27, 2019, at 3:20 PM, Amos Jeffries <squid3@xxxxxxxxxxxxx> wrote: > > On 28/11/19 1:03 am, --Ahmad-- wrote: >> Hello Amos , Thank you for your response . >> >> we have an APP behind squid http APP that will crash if # of (req/sec ) exceeded X . >> it won’t crash about Already established session , it only care about new req/sec hitting squid . >> > > That does not make sense. Any server (aka. app *behind* Squid) does not > see all requests *arriving* at Squid, only the ones Squid sends to it. > > >> I think its doable by iptables , but i really was hopping we can do it from squid level . >> > > iptables would be right if you actually mean new TCP connections per second. > > If you actually mean HTTP requests per second, then you would need > Squid. But since this is completely counter to the goals of a proxy > (*increasing* req/sec) you will need an external_acl_type helper to > delay requests. > > In current Squid we have a helper called ext_delayer_acl which delays > each request by a fixed amount of time. You may be able to use that as > the basis of one that does what you need. > > >> >> so you can imagine http req/sec or tcp req/sec same here as squid is > being used only on http protocol . > > > Er, that does not make sense. HTTP protocol has infinite number of > requests per single TCP connection. There is no equivalence. > > > > Amos > _______________________________________________ > squid-users mailing list > squid-users@xxxxxxxxxxxxxxxxxxxxx > http://lists.squid-cache.org/listinfo/squid-users _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
