【 在 GoGoRoger 的大作中提到: 】
: 一个很简单的Python脚本，几乎没有计算，就是连续发送两个http请求，然后返回结果。把程序打包成一个镜像，在实体机上运行，耗时将近200ms，布置到云上后变成了500多ms。。。。在实体机和云上分别ping对方的server，结果差不多。。。。
: 之前都是用cpp程序，没发现这么大的差距。。。
: 发自「今日水木 on M2007J17C」


不知道我下面的理解是否正确？

用cpp程序连续发送两个http请求，然后返回结果。把程序打包成一个镜像，在实体机上运行，耗时将近200ms，布置到云上后还是将近200ms，端到端延迟基本一样。

然后用Python脚本替代cpp程序连续发送两个http请求，在实体机上运行，耗时将近200ms，布置到云上后变成了500多ms，端到端延迟增加1倍多。

我们公司也用k8s部署云服务，用Docker来运行微服务。用Proxy将所有的内网服务Port映射到外网网址。理论上，几乎没有计算的微服务用Python脚本或cpp程序实现的延迟区别不大，在k8s所产生的延迟也基本一样。

有一种可能性是，Python脚本和cpp程序运行的web server port不一样，k8s上的Proxy对不同port映射优先级不一样。

不过，Python脚本和cpp程序的程序语言的不同应该不会造成如此大的差距。Python脚本和cpp程序的对比测试必须在同样环境和同样时间进行，才能确定这种延迟差距是Python脚本造成的。

我也是最近因为某个新项目的需要才接触k8s的部署问题，因为我需要让Rails服务器定时发送消息。由于种种原因总是出问题，才采用k8s的CronJobs来完成。我们的不同微服务用不同的语言实现，没发现k8s对我们用Java,PHP,Rails,Scala实现的不同微服务产生 诸如 200ms versus 500ms 差距巨大的延迟。
--
FROM 174.113.17.*

为什么没啥计算还要200ms？ 如果主要是网络耗时的话，你可以考虑dns resolve的问题。 search domain和resolver不一样。用fqdn，ip之类试试
【 在 GoGoRoger 的大作中提到: 】
: 一个很简单的Python脚本，几乎没有计算，就是连续发送两个http请求，然后返回结果。把程序打包成一个镜像，在实体机上运行，耗时将近200ms，布置到云上后变成了500多ms。。。。在实体机和云上分别ping对方的server，结果差不多。。。。
:
: 之前都是用cpp程序，没发现这么大的差距。。。
: ....................

- 来自「最水木 for iPhone12,8」
--
FROM 107.77.212.*

大头在外面，那就抓包吧。node network namespace抓一个，pod network namespace抓一个
【 在 GoGoRoger 的大作中提到: 】
: 发出去，等待回答的时间。
:
:
: ....................

- 来自「最水木 for iPhone12,8」
--
FROM 75.31.75.*

嗯，后来用cpp，就是200ms，感觉就是Python接收和发送的时间，后来没有深挖。
【 在 littleSram 的大作中提到: 】
:  
: 如果是k8s的问题，那么应该跟语言实现没关系吧  
: 你确定测试了cpp版本耗时？  
: --  
:

发自「今日水木 on M2007J17C」
--
FROM 222.129.55.*

多次
【 在 thisyears 的大作中提到: 】
:  
: 你是收发多次取平均吗？Python的服务器，可能初次启动慢点。  
: --  
:

发自「今日水木 on M2007J17C」
--
FROM 222.129.55.*