Re: thanks a lot!

In addition to poll(), squid has other limitations which serverely makes
it spiral out when the number of active filedescriptors grow, plus that
it wastes a lot of CPU for nothing when there is a lot of activity.

The big think with ncomm is that it properly isolates and abstracts the
actual I/O mechanism from the rest of the code. The fact that it
provides a more efficient use of poll() is a bonus. The biggest wins is
in the redesign required of other parts of the code (not yet done).

When Squid has been converted into using the API presented by "ncomm",
then other I/O mechanisms than the normal poll() mechanism can easily be
tried out. See discussions on squid-dev not too long ago.

Regards
Henrik

wen xiulin wrote:
>
> Henrik£¬
> thanks for your help!yes, it's good start to understand there problem for me.
>
> i think the main bottleneck of performance with Squid--coming from comm_poll" mechanism and disk read/write
> associated with underlying filesystem.
> On the network side, does the event driven network i/o can eliminate these overhead much?
>
> i read some paperes about event-driven network i/o which implement new API instead of tranditional select() or
> poll() system call.Today i read some source code of ncomm.c(Squid's event io project,which do u take part in?).
> Perhaps i didn't really understand it.but it seems it just get rid of the whole test of fd_table[] compare to comm_poll().then can it improve the situation much?(cleaning up any of my misconception is apprecitaed.)
>
> the last 2 months of this year,i want to do sth.about the proxy caching server.Since it seems that Squid is the most popular Proxy Caching Server, so i choose to start from here. but i dont sure how far could i go, but i'll try my best.
>
> regards
>
> wen xiulin
>
> ÔÚ 2001-10-15 18:04:00 ÄúдµÀ£º
> >For this, I'd suggest not so much reading the Squid sources, but to look
> >into the issues of high speed I/O.
> >
> >Putting something like Squid in the kernel won't make it run much
> >faster, unless you at the same time addresses the underlying reasons to
> >why Squid does not perform as well as it should.
> >
> >There is many things that can be done to write a proxy that performs
> >significantly faster than Squid. Putting it into the kernel is quite far
> >down that list.
> >
> >A good starting point for understanding the problems involved is to read
> >Dan Kegel's C10K page <http://www.kegel.com/c10k.html>.
> >
> >Regards
> >Henrik Nordström
> >Squid Hacker
> >
>
>
Received on Fri Oct 19 2001 - 08:45:29 MDT