<p dir="ltr"><br>
On May 13, 2016 05:25, "Mehdi Abaakouk" <<a href="mailto:sileht@sileht.net">sileht@sileht.net</a>> wrote:<br>
>>><br>
>>> - Is anyone interested in using pylibmc in their project instead of<br>
>>> python-memcached?<br>
><br>
><br>
> This is not a real drop-in replacement, pylibmc.Client is not threadsafe<br>
> like python-memcached [1]. Aos it's written in C, it shouldn't be a<br>
> problem for keystone because you don't use eventlet anymore, but for<br>
> project that still use eventlet no greenlet switch will occurs during<br>
> memcached IO.<br>
><br>
> [1] <a href="http://sendapatch.se/projects/pylibmc/misc.html#differences-from-python-memcached">http://sendapatch.se/projects/pylibmc/misc.html#differences-from-python-memcached</a><br>
><br>
> -- <br>
> Mehdi Abaakouk<br>
> mail: <a href="mailto:sileht@sileht.net">sileht@sileht.net</a><br>
> irc: sileht<br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></p>
<p dir="ltr">FYI - Python-memcached is not really greenlet safe under load. We found that it explicitly uses thread.local which means that enough connections coming into a service that means heavily on memcache can cause the memcache server to end up with a ton of open connections/max out TCP connection limits. </p>
<p dir="ltr">This had to be worked around in keystone under eventlet. Luckily it hasn't hit other projects too hard. This move should consider that design issue as well (regardless of the final choice)</p>
<p dir="ltr">--Morgan</p>