Re: Squid 2.x performance curioisities

> - no big select() loop, non-blocking I/O and complicated commSetSelect
> calls with read and write handlers anymore; it comes with a lot of
> overhead;

The select() loop is one of the suggestions which keeps coming up for
how Apache can improve performance :-) Although kernel threads look
like the way its going.

> - limited number of file descriptors per process (some OSes have/had
> problems with this);

In most cases, had. It's generally a fixed problem.

> - avoids the use of mmap, kernel threads, async-io, etc. which are
> poorly or even not implemented on some systems; the preforked daemons
> Apache uses work very well on many platforms without all these fancy
> things;

Yes, you would increase portability at the price of speed. The Apache
developers admit it's not very fast compared to the fastest http daemons
and think that using threads or other performance features would help this.

> - the client handling processes can do blocking operations without
> stopping other connections; the kernel will schedule one of the other
> processes as soon as a process blocks. I think the kernel can do this
> more efficiently than Squid can 'schedule' connections in its select()
> loop where it needs to update state information per connection after
> each read or write.

So you want one process per client connection without using threads and don't
think this will cause a massive performance problem? Full processes come with
overheads, and we will probably have more simultaneous connections than Apache.

> - without the need for kernel threads to support async-io or native
> async-io we can have parallel I/O requests because we have multiple
> processes doing disk I/O instead of one: this should scale quite
> nicely on multiple independent disks and/or multiple processors.

You might have wins on the massively parallel case, with an OS which supports
it very well, but otherwise I think this design would lose.

David.
Received on Tue Jul 29 2003 - 13:15:58 MDT