为什么json-rpc的rpcclient不保持长连接,而是每次接受完数据就关闭
如果是长连接,就涉及到复用连接的问题。 但是没有很划算的机制能确认某个连接对应的进程是否空闲,如果将消息发给非空闲的rpc进程处理,会导致请求处理延迟甚至积压。 长连接的情况: 假设A B两个进程的rpcclient和rpc的1号进程保持了长连接,A通过长连接向rpc1号进程发送了请求,很不幸这个请求要执行1秒的时间,这时候B通过长连接也向rpc1进程发送了请求,那么这个请求就会排队等待,等待A的请求处理完毕才能被执行,也就是最差的情况不管B请求多块都要等待1秒才能返回。如果这种请求积压了很多,会导致某些请求排队返回异常缓慢。 短链接的情况: 如果是短连接,当A进程向rpc发送一个请求后,只有空闲的进程才会去认领这个请求,假设是rpc1号进程处理,耗时要1秒。这时候B进程向rpc发送的另外一个请求,这个请求不会落在rpc1号进程,会被其它空闲的进程认领处理,不会造成B请求的排队延迟。 所以短链接虽然耗费了一些建立连接的资源消耗,换来的是系统更快速的运行。话说回来,短链接的性能消耗和业务消耗比起来一般可以忽略。如果你的业务消耗很小,处理速度极快(纯内存计算不涉及外部存储),可以采用长连接的方式与rpc通讯。
谢谢 感谢您的回答
如果是长连接,就涉及到复用连接的问题。
但是没有很划算的机制能确认某个连接对应的进程是否空闲,如果将消息发给非空闲的rpc进程处理,会导致请求处理延迟甚至积压。
长连接的情况:
假设A B两个进程的rpcclient和rpc的1号进程保持了长连接,A通过长连接向rpc1号进程发送了请求,很不幸这个请求要执行1秒的时间,这时候B通过长连接也向rpc1进程发送了请求,那么这个请求就会排队等待,等待A的请求处理完毕才能被执行,也就是最差的情况不管B请求多块都要等待1秒才能返回。如果这种请求积压了很多,会导致某些请求排队返回异常缓慢。
短链接的情况:
如果是短连接,当A进程向rpc发送一个请求后,只有空闲的进程才会去认领这个请求,假设是rpc1号进程处理,耗时要1秒。这时候B进程向rpc发送的另外一个请求,这个请求不会落在rpc1号进程,会被其它空闲的进程认领处理,不会造成B请求的排队延迟。
所以短链接虽然耗费了一些建立连接的资源消耗,换来的是系统更快速的运行。话说回来,短链接的性能消耗和业务消耗比起来一般可以忽略。如果你的业务消耗很小,处理速度极快(纯内存计算不涉及外部存储),可以采用长连接的方式与rpc通讯。
谢谢 感谢您的回答