memcached performance on Mac OS 10.4

[Peter Bengtson]

I'm experiencing the previously reported 200 ms latency on each  
memcached query. As five queries per second is far, far worse than  
scrapping memcache altogether and running without memory caching, I  
was wondering if the problems on Mac OS 10.4 have been addressed and/ 
or worked around in any way since Gregory Block wrote the following  
to this list in March last year:

> I had a bug open on Radar regarding memcached causing core dumps when
> used in poll(), kevent(), or anything other than select.  I've been
> informed by the team that there's a fix in place for Tiger, and that
> they've tested under tiger and poll() without seeing the kernel  
> panics.
>
> So...
>
> Until that fix is in place, it's memcached + select() on mac os x, or
> watch your kernel go tits up.

Of course, libevent since v1.1 has a "workaround", but memcache when  
using libevent 1.1a and started in the following fashion:

	/usr/local/bin/memcached -k -uroot

still reports:

	[warn] kq_init: detected broken kqueue; not using.: Bad file descriptor

and then proceeds to respond exactly five times a second.

Also, James Robinson wrote, on Aug 30:

> stores of payload between 14000 and 195846 bytes all happen on OS X
> without delay. Apparently OS X's TCP_NOPUSH is just plain busted, as
> seems to be the net wisdom garnered from google.

So, I'm wondering what is happening here. Are the Mac OS 10.4  
implementations of kqueue and TCP_NOPUSH still broken? Are there any  
patches from Apple or any third-party solutions? And is the slow  
speed we're seeing the result of select() being inherently slow on  
Mac OS X? Is there another way of forcing memcached use poll()?

	/ Peter Bengtson