-----Message d'origine----- De : Amos Jeffries [mailto:squid3@xxxxxxxxxxxxx] Envoyé : 27 novembre 2012 17:40 À : squid-users@xxxxxxxxxxxxxxx Objet : Re: Problem publishing on Facebook via Squid 3.1.2 On 28.11.2012 09:00, Eliezer Croitoru wrote: > You will like to allow for your environment more then 8192 FD. > I would suggest to jump to something like 65535 as a starter and use > half of it for the soft and the full to hard. > > This is the basic tuning for such a system for this amount of users. > 2700 with about 100 per sec can be the culprit. > you can use squidclient mgr:SOMETHING > > and the command: > lsof -n |grep proxy | wc -l > to see how many basically are opened. > > Regards, > Eliezer > Note that 130 req/sec mentioned earlier equates to almost 8K active sockets. So it is *very* likely this is one of the traffic bottlenecks in your proxy. When you increase the FD available you can expect to see higher and faster spikes in traffic req/sec going through Squid. This is normal and a Good Thing, the client browsers are getting faster service time and can place more requests to complex sites in those shorter duration peaks. I would also ensure that persistent connections are enabled for both client and server connections. If you have them disabled your Squid will cause a lot of the machine network sockets to be stuck in TCP's 15min TIME_WAIT period and unusable to any process. These two changes alone may fix your FB issue. Their uploader is a bit sensitive to connection speed as it re-codes whatever the upload is on the fly. If not you will likely benefit from also adding the HTTP/1.1 improvements available in 3.2 series, which allow a lot more automatic optimization on sites with traffic profiles like FB. Amos --- Thanks Amos, My max FD is now 65535 and client_persistent_connections and server_persistent_connections are still at their default value "on". I have seen no improvement with Facebook so I'll try Squid 3.2.3. Marc Delisle
