这是预期的。
您在虚拟机上运行此基准测试，在该虚拟机上，系统调用的成本高于物理硬件上的成本。激活gevent时，它倾向于生成更多的系统调用（以处理epoll设备），因此最终会降低性能。
您可以通过在脚本上使用strace轻松地检查这一点。
如果没有gevent，则内部循环会生成：
recvfrom(3, ":931rn", 4096, 0, NULL, NULL) = 6sendto(3, "*3rn$6rnINCRBYrn$10rntestsocketr"..., 41, 0, NULL, 0) = 41recvfrom(3, ":941rn", 4096, 0, NULL, NULL) = 6sendto(3, "*3rn$6rnINCRBYrn$10rntestsocketr"..., 41, 0, NULL, 0) = 41
使用gevent，您将发生以下情况：
recvfrom(3, ":221rn", 4096, 0, NULL, NULL) = 6sendto(3, "*3rn$6rnINCRBYrn$10rntestsocketr"..., 41, 0, NULL, 0) = 41recvfrom(3, 0x7b0f04, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)epoll_ctl(5, EPOLL_CTL_ADD, 3, {EPOLLIN, {u32=3, u64=3}}) = 0epoll_wait(5, {{EPOLLIN, {u32=3, u64=3}}}, 32, 4294967295) = 1clock_gettime(CLOCK_MONOTONIC, {2469, 779710323}) = 0epoll_ctl(5, EPOLL_CTL_DEL, 3, {EPOLLIN, {u32=3, u64=3}}) = 0recvfrom(3, ":231rn", 4096, 0, NULL, NULL) = 6sendto(3, "*3rn$6rnINCRBYrn$10rntestsocketr"..., 41, 0, NULL, 0) = 41当recvfrom调用处于阻塞状态（EAGAIN）时，gevent返回事件循环，因此需要执行其他调用来等待文件描述符事件（epoll_wait）。
请注意，对于任何事件循环系统，这种基准测试都是最坏的情况，因为您只有一个文件描述符，因此无法在多个描述符上分解等待操作。此外，由于所有内容都是同步的，因此异步I
/ O在这里无法改善任何内容。
对于Redis来说，这也是最坏的情况，因为：
它会产生许多到服务器的往返
它会系统地连接/断开连接（1000次），因为该池是在UxDomainSocket函数中声明的。
实际上，您的基准测试并不测试gevent，redis或redis-py：它行使VM在2个进程之间维持乒乓游戏的能力。
如果要提高性能，则需要：
使用流水线减少往返次数
使池在整个基准中持久存在
例如，考虑使用以下脚本：
#!/usr/bin/pythonfrom gevent import monkeymonkey.patch_all()import timeitimport redisfrom redis.connection import UnixDomainSocketConnectionpool = 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倍的性能提升，并且gevent几乎没有开销。
