On Tue, 26 Jan 1999, John Dilley wrote:
> Apologies for being slightly off the disk/IO topic, but I have
> some comments & questions about using threads. My opinion of the way
> threads are intended to be used leads to a thread-per-connection model.
Not exactly. A thread is intended for a logically encapsulated/isolated
piece of work. Processing one connection is not isolated from other
activities. In fact, there are a lot of scenarios when one connection's
activity interleaves actively and a lot with other connections. The
logical granularity is significantly finer than "a connection". Thus, one
will not gain any "programming simplicity" but rather will be buried in
tons of synchronization stuff. (Not to mention that this solution does not
scale well with the number of concurrent users).
> The best
> way to improve Squid performance would be (IMHO) to focus on disk IO
> (the main "thread" of this conversation :-) and to improve select()...
Since non-threaded Squid _blocks_ on every disk IO, per-disk threads (or
other concurrent models) may improve Squid performance (provided there is
a lot of unused disk bandwidth when running non-threaded Squid!).
Ideally, you want to have a zero-overhead thread per every blocking
device/activity in your system.
Alex.
Received on Tue Jul 29 2003 - 13:15:56 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:12:02 MST