ai时代,能不能进一步降低webman or workerman api响应时间
webman几乎是第一梯队的响应时间,本地测试带数据库,基本在20-40ms,但是go语言能10-30ms,在ai帮助下能不能进一步降低响应时间,我用尝试了一下效果不理想,或者有啥最佳实践,或者优化方案
关于带数据库业务的webman和go的压测对比有比较权威的第三方有测试报告,webman各个方面的性能比go的常用框架高一截。 来源 Techempower最后一轮压测 ,历史轮次代码和数据都可查。
不管是go还是webman,一个简单的数据查询求耗时10-40ms都是不太正常的,预热后正常情况下处理一个请求时间一般都不超过1ms。
压测一般不是肉眼看下浏览器network的耗时,它不是很准,因为网络传输的耗时占大头,例如总耗时30ms,但实际上服务端处理耗时不到1ms,这种情况下通过network耗时来判断框架性能高低没有意义。
另外数据库组件的封装复杂度对于压测性能有很大影响,laravel和tp的数据库类因为提供了丰富的接口和特性,所以使用这些组件和go使用轻量数据库组件来对比性能是不合理的,一般都是直接用pdo 和 go的最轻量数据库组件来对比。
性能和压测相关参考手册 https://www.workerman.net/doc/webman/others/performance.html https://www.workerman.net/doc/webman/others/benchmarks.html
workerman基本上已经把php的性能发挥到极致,至于ai能否继续优化性能有难度但是不排除还有一定提升。
关于带数据库业务的webman和go的压测对比有比较权威的第三方有测试报告,webman各个方面的性能比go的常用框架高一截。

来源 Techempower最后一轮压测 ,历史轮次代码和数据都可查。
不管是go还是webman,一个简单的数据查询求耗时10-40ms都是不太正常的,预热后正常情况下处理一个请求时间一般都不超过1ms。
压测一般不是肉眼看下浏览器network的耗时,它不是很准,因为网络传输的耗时占大头,例如总耗时30ms,但实际上服务端处理耗时不到1ms,这种情况下通过network耗时来判断框架性能高低没有意义。
另外数据库组件的封装复杂度对于压测性能有很大影响,laravel和tp的数据库类因为提供了丰富的接口和特性,所以使用这些组件和go使用轻量数据库组件来对比性能是不合理的,一般都是直接用pdo 和 go的最轻量数据库组件来对比。
性能和压测相关参考手册
https://www.workerman.net/doc/webman/others/performance.html
https://www.workerman.net/doc/webman/others/benchmarks.html
workerman基本上已经把php的性能发挥到极致,至于ai能否继续优化性能有难度但是不排除还有一定提升。