memcached performance on Mac OS 10.4

[Peter Bengtson]

Can somebody summarize, please?

	/ Peter Bengtson


2 mar 2006 kl. 17.39 skrev Brad Fitzpatrick:

> On Thu, 2 Mar 2006, Noah M. Daniels wrote:
>
>> Ok, that makes more sense... so I disable both kqueue and NOPUSH.
>> Does libevent need rebuilt with certain flags? Or will setting the
>> EVENT_NOPOLL environment variable be sufficient?
>
> If anything you'd want EVENT_NOKQUEUE, if that exists.  Should  
> work, if
> so.
>
>>
>>
>> On Mar 2, 2006, at 11:31 AM, Brad Fitzpatrick wrote:
>>
>>> On Thu, 2 Mar 2006, Brad Fitzpatrick wrote:
>>>
>>>> If you rebuild libevent with kqueue support, and disable TCP_NOPUSH
>>>
>>> _without_ kqueue support, sorry.
>>>
>>>> support in memcached (which it tries to auto-detect), then
>>>> memcached will
>>>> be fast on OS X, but you're limited in your number of concurrent
>>>> connections.  Or rather, it'll eat more CPU as you have more  
>>>> clients
>>>> connected because it has to poll()/select().
>>>>
>>>> The problem, as I understand it, is:
>>>>
>>>>    kqueue is auto-detected, but sucks on OS X.
>>>>
>>>>    NOPUSH is auto-detected, but sucks (on OS X and FreeBSD?) or its
>>>>      semantics diff from TCP_CORK on Linux.  not quite sure.
>>>>
>>>> In any case, a coworker of mine using memcached on OS X (for
>>>> development,
>>>> not production), had success with the above.
>>>>
>>>> - Brad
>>>>
>>>>
>>>> On Sun, 15 Jan 2006, Peter Bengtson wrote:
>>>>
>>>>> 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
>>>>>
>>>>>
>>>>
>>>>
>>
>>