在使用轮询发出ZeroMQREQ/REP请求时，我得到了无法解释的结果。
poll()-方法占用的经过时间受到代码中其他time.sleep()的影响。
我有一个服务器进程，它运行一个命令，并返回该进程的pid。这是有问题的请求端代码：
导入日期时间，系统，时间，zmqsleeptime=浮点(sys.argv[1](def log_msg(消息(：print"｛0｝，｛1｝".format(datetime.datetime.ucnow((.strftime('%Y%m%d_%H:%m:%S.%f'(，msg(context=zmq。上下文((socket=context.socket(zmq.REQ(socket.connect("tcp://｛0｝：｛1｝".format('myserver'，9980((poller=zmq。轮询器((poller.register(套接字，zmq.POLLIN(req=｛'req_type'：'raw_cmd'，'cmd'：'cho-hello'，'block'：0，'timeout'：300，'return_output'：0｝对于范围(4(中的i：睡眠时间socket.send_json(req(start=time.time((socks=dict((poller.poll(30000((逝去=(time.time((-start(*1000rep=套接字.recv_json((log_msg('pid＝｛0｝，sleep＝｛1｝，所用时间＝｛2｝'.format(rep['pid‘]，sleeptime，int(perated((
第一次轮询所用时间变化很大，但所有后续轮询所用的时间都比睡眠时间短约2秒，除非睡眠时间为0，在这种情况下它很快，所以：
sleep = 0.5:
20201008_08:27:24.168800，pid=52528，睡眠=0.5，所用时间=50520201008_08:27:26.210196，pid=52529，睡眠=0.5，所用时间=154020201008_08:27:28.250891，pid=52530，睡眠=0.5，所用时间=153920201008_08:27:302.95036，pid=52531，睡眠=0.5，所用时间=1543
sleep = 1.5:
20201008_08:44:02.4474492，pid=54730，睡眠=1.5，所用时间=29520201008_08:44:04.516844，pid=54731，睡眠=1.5，所用时间=54020201008_08:44:06.557980，pid=54732，睡眠=1.5，所用时间=53920201008_08:44:08.599717，pid=54733，睡眠=1.5，所用时间=539
sleep = 0:
20201008_08:27:13.999147，pid=52513，睡眠=0.0，所用时间=69020201008_08:27:14.033915，pid=52514，睡眠=0.0，所用时间=3420201008_08:27:14.068803，pid=52515，睡眠=0.0，所用时间=3420201008_08:27:114.103947，pid=52516，sleep=0.0，花费的时间=34
所以问题是，为什么time.sleep()会影响ZeroMQpoller.poll()花费的时间？
按原样的代码将苹果和橙子混合在一起：
time.time()将自epoch以来的秒数返回为float，即( time.time() - start )*1000产生测试中的代码段实际花费的[ms]毫秒数。
而poller.poll()-方法的timeout预计为毫秒，因此请求的30000 [ms]会使poller-实例等待并保持，直到30 [s]过去或与消息到达相关的zmq.POLLIN-事件允许提前任何时间前进。
也就是说，您的测量探索的不是.sleep()方法，而是外部进程随机抽取的间隔，该间隔将REP侧的答案发送到REQ-侧的.send()-s。
仍然心存疑虑？将睡眠时间设置为31 [s]，您应该会收到来自错误制定的本地时间段的几乎为零的持续时间报告(当然，如果且仅当远程REP实体在此类操作中没有崩溃或窒息(。
您可能还喜欢zmq.Stopwatch类，它具有{ .start(), .stop() }-方法，为使用ZeroMQ本机[us]-分辨率时钟提供了一个智能工具。我关于ZeroMQ性能的大部分文章都将此用于微基准测试。