基本上,我有一个通过长轮询从后端搜索和请求结果的应用程序。它连接到后端,后端收集500 ms的结果,然后将结果发送回客户端(当然,我在这里简化了一些事情)。当我们对此进行优化时,我们注意到在夜间搜索的用户和白天搜索的用户之间的差距越来越大。也就是说,晚上搜索的用户要比白天搜索的用户慢得多,因为这些用户大多是国际用户,延迟时间更长。
对于这些用户来说,有什么好的高级方法可以加快速度呢?
发布于 2011-09-22 05:39:02
你需要分析你的代码,寻找“扭转”。扭转是一种情况下,前进的进展被阻止,直到数据可以从另一方收到。每一次转机都会给性能增加一小部分,使其随延迟而增加。因此,如果您有12转,100 of的延迟意味着1.2秒的等待。如果您可以将翻转时间降到4100 of,则额外的延迟只意味着额外的.4秒等待时间。
有些扭转是明显的。如果你发送了一个请求,等待回复,那就是一个转变。如果你需要看到这个回复来决定下一个请求是什么,那就是一个转变。
有些扭转是隐含的。如果打开TCP连接并等待确定打开是否成功,则这是一个转机。如果您关闭一个TCP连接,并等待关闭完成,没有错误,这是一个转机。
寻找和测量旋转是一种有点黑色的艺术。但是,您可以使用的一个技巧是延迟模拟器(Linux可以使用图腾)。如果您可以添加带有时间戳的日志记录,或者以其他方式告诉发生了什么,那么您可以添加一个4秒钟的延迟模拟器(一种为通过它的每个数据包增加4秒延迟的设备)。每4秒钟,你都在等待某件事情的发生。你可以数数它们,你也可以看到在你的操作过程中,它们落在了哪里。
从来没有为回溯优化过的代码经常会有大量不必要的回溯。它们在测试环境中通常是不可见的,因为这些环境通常在同一个LAN上有客户机和服务器,或者在最坏的情况下,在快速广域网上非常接近。
有四种基本的方法来消除扭亏为盈。一种是流水线--这基本上意味着,如果你不必等待回复,你就不会等待回复。您可以稍后再来检查结果。另一个是整合--如果你现在需要两个请求来做一些更高级别的操作,然后你把它减少到一个请求,那就没有了。第三种方式是并发--如果你一次能做不止一件事,那就没有了。最后一个是预取--如果您知道要加载的网页元素需要加载另一个URL的内容,您可以在加载需要它的网页时开始检索该URL。
发布于 2011-09-22 01:11:47
一些可能有帮助的想法:
https://softwareengineering.stackexchange.com/questions/109966
复制相似问题