On fre, 2007-08-03 at 15:37 +0200, Jiri Kuthan wrote: > I'm wondering if you could do me a massive favor and exchange some experience > you > might have gathered with building squid regarding TCP scalability.
We can try.. > I've been writing a SIP proxy server, SER (www.iptel.org/ser), which > typically operates > in UDP mode. Now in the IETF, TCP is gaining more momentum. SER supports it > but compared > to UDP it scales rather poorly -- at the moment we can't get more than 50k > connections > out of it. The primary thing to keep in mind is to make use of a decent event notificatoin mechanism, i.e. epoll/kqueue/devpoll. Without it performance will quickly suffer when the amount of connections increases. To make life easy one may use libevent, which provides all the needed framework. When using a good event notification the performance is again more related to the amount of messages one has to process and not related to the amount of concurrent connections. > Could you share with me, how many TCP connections can squid handle, if you > have any > performance measurment results, tuning tips, etc? Unlike SIP HTTP is still dominated by relatively shortlived connections, so we don't get that many concurrent connections. A very buzy server is more in the range of 5-10K connections. But have done lab tests with several hundreds of thousand idle connections, to verify that the event notification works. It does, but Squid's connection oriented buffer management makes it consume quite a bit of memory... Regards Henrik
signature.asc
Description: This is a digitally signed message part
