I think evenly dividing the filedescriptor sets won't do you much good.
Instead a suitable priority mechanism should be found telling how often
an given FD is polled.
With current code, I think something like this would do good:
* If not ready for a time of X * queue priority, then move to a lower
priority queue
* Move to first priority queue when an handler is installed on the FD
If the optimistic IO is reimplemented, then I am not sure. But anyway
the optimistic IO should quite drastically cut down on the number of
polls per forwarded request..
Or maybe to have a simple design based on three priorities:
1. Status unknown. High priority for one poll only. This is to catch the
case where data is already in the TCP buffer.
2. No data seen on last poll, or the TCP buffer was completely
drained/filled in the last operation.
3. Background polls where we are only watching to see if something
happens. For example reading of closed client connections waiting for
the client to shut down the connection.
/Henrik
adri wrote:
>
> Update of /cvsroot/squid/squid/src
>
> Modified Files:
> Tag: commloops
> comm_poll.c
> Log Message:
>
> An attempt at optimising the poll code. Instead of a single pollfd set, there
> are NPOLL fd sets (defined in src/comm_poll.c for the time being) which
> define how many FD sets they are.
>
> The FDs are placed inside the fdset by a simple modulus NPOLL, evenly
> distributing the FDs between the fdsets. A call to comm_select() now
> polls a single fdset, rather than all.
>
> I have to fix a little code in comm_select() which checks whether
> there are no FDs and only allows it during a shutdown. This definitely
> needs to be fixed, but doesn't impact normal operation.
>
> This is based upon ideas from Andreas and Dancer, and initial coding from
> Benno. If you want the details, squid-dev mailing list archives are your
> friend.
>
> _______________________________________________
> Squid-cvs mailing list
> Squid-cvs@lists.sourceforge.net
> http://lists.sourceforge.net/mailman/listinfo/squid-cvs
Received on Fri Aug 04 2000 - 12:23:58 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:12:34 MST