python gevent缺点_python – redis gevent – 表现不佳 – 我做错了什么？

这是预期的。

您在虚拟机上运行此基准测试，系统调用的成本高于物理硬件。当gevent被激活时，它往往会产生更多的系统调用(以处理epoll设备)，所以最终会降低性能。

您可以通过在脚本上使用strace轻松查看此点。

没有gevent，内部循环产生：

recvfrom(3, ":931\r\n", 4096, 0, NULL, NULL) = 6

sendto(3, "*3\r\n$6\r\nINCRBY\r\n$10\r\ntestsocket\r"..., 41, 0, NULL, 0) = 41

recvfrom(3, ":941\r\n", 4096, 0, NULL, NULL) = 6

sendto(3, "*3\r\n$6\r\nINCRBY\r\n$10\r\ntestsocket\r"..., 41, 0, NULL, 0) = 41

有了Gevent，你会发生以下情况：

recvfrom(3, ":221\r\n", 4096, 0, NULL, NULL) = 6

sendto(3, "*3\r\n$6\r\nINCRBY\r\n$10\r\ntestsocket\r"..., 41, 0, NULL, 0) = 41

recvfrom(3, 0x7b0f04, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)

epoll_ctl(5, EPOLL_CTL_ADD, 3, {EPOLLIN, {u32=3, u64=3}}) = 0

epoll_wait(5, {{EPOLLIN, {u32=3, u64=3}}}, 32, 4294967295) = 1

clock_gettime(CLOCK_MONOTONIC, {2469, 779710323}) = 0

epoll_ctl(5, EPOLL_CTL_DEL, 3, {EPOLLIN, {u32=3, u64=3}}) = 0

recvfrom(3, ":231\r\n", 4096, 0, NULL, NULL) = 6

sendto(3, "*3\r\n$6\r\nINCRBY\r\n$10\r\ntestsocket\r"..., 41, 0, NULL, 0) = 41

当recvfrom调用阻塞(EAGAIN)时，gevent返回到事件循环，因此会执行额外的调用来等待文件描述符事件(epoll_wait)。

请注意，这种基准测试对于任何事件循环系统来说都是最差的，因为只有一个文件描述符，所以等待操作不能被分解成几个描述符。此外，异步I / O无法改善任何内容，因为一切都是同步的。

这也是Redis的一个最坏的情况，因为：

>它会向服务器生成许多往返

>它系统地连接/断开(1000次)，因为池在UxDomainSocket函数中声明。

实际上，你的基准测试不会测试gevent，redis或redis-py：它能够运行虚拟机在2个进程之间维持乒乓球游戏的能力。

如果要提高性能，您需要：

>使用流水线来减少往返次数

使整个基准池保持一致

例如，请考虑以下脚本：

#!/usr/bin/python

from gevent import monkey

monkey.patch_all()

import timeit

import redis

from redis.connection import UnixDomainSocketConnection

pool = redis.ConnectionPool(connection_class=UnixDomainSocketConnection, path = '/tmp/redis.sock')

def UxDomainSocket():

r = redis.Redis(connection_pool = pool)

p = r.pipeline(transaction=False)

p.set("testsocket", 1)

for i in range(100):

p.incr('testsocket', 10)

p.get('testsocket')

p.delete('testsocket')

p.execute()

print timeit.Timer(stmt='UxDomainSocket()', setup='from __main__ import UxDomainSocket').timeit(number=1000)

使用这个脚本，我可以获得大约3倍的性能，几乎没有任何额外的开销。