ibrowse 总体上来讲,是个很不错的http client,自带进程池,同步使用没什么问题,但是异步模式下,就要小心了。

问题一,怎么合理设置max_sessions的大小

ibrowse自带了发送数据的进程池,我们通过设置max_sessions和max_pipeline_size可以来提高性能。

通过测试,我们发现max_sessions并不是越大越好的,比如,我们发送100个请求,将max_sessions设置为100的时候可能比max_sessions设置为10要差。原因是当前连接数没有超过max_sessions的话,直接启动一个新的进程去处理。启动一个进程的代价,第一次初始化需要做dns解析,建立tcp连接,如果可以复用原来的连接,用keep-alive的属性的话,会稍微节约这部分开销。

后来,我依据每秒产生请求数去配置,比如每秒产生了100个,那么max_sessions我配置成100,希望下一秒都能pipe,节约掉建立连接的开销,既然知道max_sessions有这个影响开销,就可以考虑不配置那么大就是了。

问题二,Asynchronous在什么时候返回RedId

我们在测试的时候,发现开多进程同步发送的耗时比单进程用异步发送还要少,感觉正常来讲,异步,不就发个消息给对方,对方收到了,就返回ReqId给你,然后他继续他的发送逻辑。这样情况下,收发ReqId应该开销很小。

实际上,开销并不小,ReqId的返回时候是ibrowse_http_client的do_send_body之后,也是要等tcp连接建立发送数据之后才返回。这种异步最多只能算就是接收Body异步,这样一来,单进程都承载成这么多请求的发送开销,多进程情况会均摊到发送开销,所以看起来耗时短了。

结论

  • 合理设置max_sessions大小,可以减少耗时
  • 不要集中请求到一个进程来异步发送
  • 如果一个不需要返回的http请求的话(比如统计服务的日志提交),怕堵塞的话,spawn个进程去请求即可。