[test case] terrible performance with select()

[Brad Fitzpatrick]

I couldn't reproduce this.

But then, I can only get it to use poll, and not select.  I haven't read
libevent to see how it makes that decision.


On Sun, 10 Aug 2003, Evan Martin wrote:

> As a few people (including me) have found out, memcache is suspiciously
> slow when using libevent backends other than epoll.  (I think?  I guess
> I've only seen the behavior myself with select().)
>
> FWIW, it appears the problem that event_hander is taking up to five
> seconds to get called, but only after repeat commands.  Why that
> happens is a more difficult problem, because it works fine with epoll
> so it must be some behavior that's inconsistent underneath libevent.
>
> Attached is a test case that exhibits the behavior.  Of note is the
> perfectly round numbers that come up when it's being slow.  Is
> something timing out here?
> (The "delay" here is the delay between subsequent requests.)
>
> lulu:~/projects/memcached/api/python% ./slow.py 1
> Trying get()s with 1.00s delay
> get took 0.13 seconds
> get took 0.30 seconds
> get took 4.00 seconds
> get took 4.00 seconds
> get took 4.00 seconds
> get took 4.00 seconds
> lulu:~/projects/memcached/api/python% ./slow.py 0.9
> Trying get()s with 0.90s delay
> get took 0.18 seconds
> get took 1.38 seconds
> get took 4.10 seconds
> get took 4.10 seconds
> get took 4.10 seconds
> get took 4.10 seconds
>
>
>