Re: aio_read implementaion in Squid

On 13 Sep 2001, at 18:01, Venkatesh <gv_kovai@yahoo.com> wrote:

> Thanks for your valuable points. Actually I wanted to start that before 2
> weeks itself. But As I was busy with other works, I could not make it. Again
> I am stressing you all that I am for very very very High performance Squid.
> say It should handle 1k req/sec. I am not really for very quicker solution.
> So Pls guide me in this way.
>
> So my objective will be,
> * If you want to finish eventio model first, Ie for moderate performance
> improvement, I can try to contribute from my side.
> * But Before doing that, I should get fair decision of what I/O will be good
> for Squid in all aspects to achieve 1k req/sec.

 Current squid can easily handle 1k req/sec without disks involved. In last
 days one of our reverse-proxies was handling 540 req/sec with single disk,
 although its memhitrate is at 90-95%...
 Next bottleneck after disks is ACL's. If you use no or very few acls, only
 then comes io model into play.
 And while at that, it makes a huge difference, whether you service alot of
 slow clients or few fast clients. When you have few open sockets, poll model
 is very much okay.

> I know filesystem also another big bottleneck. Assume now, FileSystem is not
> bottleneck and tell me How much My squid can handle and with which Net I/O
> Implementation?

 I don't think anyone has any figures or tests done on that matter.

 If You think of ultimate performance for squid, eventio will not solve any
 problem actually. If I understand it correct, then its just a framework,
 abstraction layer within Squid that helps in plugging different IO models.
 It will make squid much simpler and cleaner, but bottlenecks will stay.
 poll() overhead is not very big, its the way it is used that makes the
 overhead to add up. Ontop of "eventio" new api things can be done better.

 When trying to remove all bottlenecks from the path, you'd eventually have
 to eliminate excessive "expensive" paths from equation.
 - syscalls are expensive. You need to reduce number of syscalls/request.
 - memory latency is expensive. Need to increase locality and reduce copy.
 Both are related to either OS or hardware specifics.

 I can't help it but draw analogy with tape device. It works very well
 if it is streaming, but becomes ultimate duck when it can't. With tape
 device the effect is drastic, with code its much less obvious. In analogy,
 every expensive path is as a need to stop the tape and rewind. Either op,
 rewind or read/write is effective if done in bulk, but if switching between
 the two types dominates, life becomes damned.
 Any piece of code that doesn't directly contribute to the goal, is useless,
 although often required overhead. If thought from that perspective, its
 quite easy to see the main drawbacks of any existing io models.

> > On Thu, Sep 13, 2001, Henrik Nordstrom wrote:
> > > Adrian Chadd wrote:
> > >
> > > > > Have now updated eventio to HEAD (and automake). It compiles, but I
> > > > > strongly doubt it is at all usable. The code was left in the middle
> of a
> > > > > farily large transition from the old "polled" I/O model to the
> > > > > "eventio" I/O model.
> > > >
> > > > Did you have any ideas on how this could be done relatively easily?
> > >
> > > Not really. At the stage eventio branch currently is the easiest path is
> > > most likely to "just" finish the transition.
> > >
> > > If one starts over doing it at a slower pace then I have some ideas on
> > > how the old I/O model could be implemented using the new core, including
> > > deferred reads. But it is unclear if this will be any easier.
> >
> > Well, throw me the ideas? :)

------------------------------------
 Andres Kroonmaa <andre@online.ee>
 CTO, Microlink Online
 Tel: 6501 731, Fax: 6501 725
 Pärnu mnt. 158, Tallinn,
 11317 Estonia
Received on Thu Sep 13 2001 - 11:39:02 MDT