我的这个场景是不是不适合 epoll

我的场景：
1. client 端用 python 的多线程去并发请求一个服务，其中并发度可调节5，10，50，之类的，服务本身没有负载均衡，一个进程（一个worker）单纯的处理，也就是说，场景是简单的 n 个并发到一个端口上的服务

2. 服务端业务处理简单，基本就是在 mysql 中插入一条记录（其实是认证用的 token）
3. server 端用的是 python 和 eventlet，eventlet 默认用的 epoll

问题：
我把并发调成1的时候，效率大概是每个请求都能在0.2秒完成
但，当我把并发调成5左右的时候，有的请求会被 delay 很久，我自己的统计大概是：
1. 0.2s
2. 0.2s
3. 15s
4. 0.2s
...

总有那么几个倒霉的线程，在请求 server 的时候总会被忽略，然后就出现了上面 3 的那个情况，完成时间是别的线程的几十倍

另一个现象是，顺序的请求的话，比如 100 个请求用了 25s 的时间，那 100 个并发的请求会在35s 左右，也就是 server 段出现了 overhead

我自己的想法：
1. 首先单 worker 是根源，25s 的总请求时间变成 35s，是因为 epoll 在上下文切换的时候造成的，而且业务本身的性质并没有多少空闲（epoll之类的选举算法是当一个请求空闲的时候，切换下，让别人跑跑），也就是没有多少收益。收益 < 上下文切换带来的代价，所以总相应时间会变多

2. 上面例子中的 3 无法理解，为什么总有一个请求者（线程）总是没法被 epoll 选到呢？不能只是运气差吧