获得更快 Web 服务响应的一般技术？
我正在使用亚马逊产品广告 API 来处理我的全文搜索。问题是响应时间长达 3-4 秒（大约是我的总页面加载时间 6-8 秒的一半）。我可以采取一些通用技术来缩短响应时间吗？我已经收到压缩格式的回复。
最终，我希望能够尽快向用户显示搜索引擎结果页面。
I'm using Amazon Product Advertising API to handle my full text search. The problem is that the response is taking up to 3-4 seconds (which is about half of my total page load time of 6-8 seconds). Are there any general techniques I could do to improve response time? I'm already receiving the response in compressed format.
Ultimately, I want to be able to display the search engine results page to the user as quickly as possible.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我认为您问的是
Web 2.0的概念。在您的情况下，您可以立即提供页面，然后使用 AJAX 请求，该请求将在几秒钟后填充内容 - 一直以来，用户都会看到一个旋转的动画 GIF 正在等待您的数据负载。您可能想进一步阅读SOA（面向服务的架构） - 这只是其中之一数十种适合整个
Web 2.0主题的编程范例。I think you're asking about the concept of
Web 2.0. Here is where, in your case, you serve the page immediately and then use an AJAX request that will populate it several seconds later with the content - all the while the user sees a spinning animated GIF waiting for your data payload.You may want to read further about SOA (Service-oriented architecture) - this just one of dozens of programming paradigm that fit with the whole
Web 2.0theme.与外部 Web 服务的通信几乎总是很慢，通常慢得令人无法接受。在这种情况下，您真正能够优化的唯一部分是连接开销。如果您要在本地运行一个守护进程，以保持与 Amazon Web 服务的保持连接，然后通过该守护进程触发请求，则可以避免连接开销并缩短响应时间。
从用户体验的角度来看，您最好通过向服务器发出 AJAX 请求来执行搜索。您可以向用户显示一个微调器，然后在请求返回时填充页面。这可能会让它感觉更具响应性，因为他们不会等待整个页面的构建。
Communicating with external web services is nearly always slow, usually unacceptably so. In this case, the only piece you'll really be able to optimize is the connection overhead. If you were to keep a daemon running locally that maintained a keepalive connection to the Amazon web service, then fired requests through that, you could avoid the connection overhead and improve response times.
From a UX perspective, you're probably better executing the search via an AJAX request to the server. You can display a spinner to the user, and then populate the page when the request returns. This would probably make it feel a bit more responsive, since they wouldn't be waiting on the whole page to build.