关于Watson-NLU速度基准及推文文件处理性能瓶颈的咨询

一、文件处理环节会不会拖慢速度？ #

先看看你贴的这段代码：

while 1: 
    where = file.tell() 
    line = file.readline() 
    if not line: 
        print "no line found, waiting for a 1 seconds" 
        time.sleep(1) 
        file.seek(where) 
    else: 
        if (re.search('[a-zA-Z]', line)): 
            print "-----------------------------" 
            print "the line is: " 
            print line 
            ...

这段逻辑确实可能给整体速度拖后腿，主要问题在这几个地方：

• 轮询等待太浪费时间：每次读到文件末尾就sleep 1秒再回去重新读，要是文件是持续写入的，这种频繁等待会累积不少延迟。
• 逐行同步处理效率低：读一条就处理一条（还同步打印内容），控制台打印本身就占IO时间，而且没法并行处理多条Watson请求，等于每次都要等API返回才能处理下一条。
• 正则匹配的累积开销：虽然re.search('[a-zA-Z]')单条开销不大，但推文数量多了，这些小开销加起来也会有影响。

不过得说句实在的，Watson NLU的API调用延迟可能才是更大的瓶颈——毕竟网络请求的耗时通常远高于本地文件IO。但你的文件处理逻辑确实有优化空间，相当于雪上加霜了。

给你几个优化方向：

• 改成批量读取+批量提交：一次读个几十上百条，然后用Watson的批量接口提交，减少API调用次数，能省不少HTTP握手的时间。
• 换掉低效的轮询：如果是一次性处理所有推文，直接把所有行读出来再处理就行；如果是实时监听文件更新，用watchdog这类专门的文件监听库，比自己sleep轮询高效多了。
• 异步处理请求：用asyncio加aiohttp这类异步工具，并行调用Watson API，不用等一条处理完再搞下一条，能大幅提升吞吐量。
• 少打控制台日志：把打印内容改成写入日志文件，或者用logging库，控制台IO真的挺慢的。

二、Watson NLU的速度基准大概是多少？ #

Watson NLU的处理速度没有固定值，主要看这几个因素：你调用的分析类型（情感、实体、关键词啥的）、批量请求的大小、你的套餐版本（免费/付费）、还有你和Watson服务器的网络距离。

根据官方测试和用户实际反馈：

• 单条请求：像推文这种短文本，单条处理时间大概在100ms到500ms之间，理想状态下每分钟能处理120到600条，但这得是网络好、服务器负载低的情况。
• 批量请求：用批量接口一次提交10-100条的话，效率会高很多，每分钟能处理几百到上千条，因为减少了重复的HTTP握手开销。
• 免费版限制：免费版有请求速率限制（比如每分钟最多100条），而且服务器优先级低，实际速度可能会打折扣。
• 网络延迟影响：如果你的服务器和Watson的节点（比如达拉斯、法兰克福）离得远，网络延迟会增加每次请求的耗时，拖慢整体速度。

所以你现在每分钟28条的速度，大概率是文件处理的低效逻辑 + Watson API的同步调用 + 可能的网络延迟/套餐限制共同导致的，其中API的同步等待和网络延迟应该是主要原因。

内容的提问来源于stack exchange，提问作者Aviral Srivastava