造成请求超时的原因是什么？

无刮取通用抓取API在服务定义的执行限制内检索公共网页，并支持JavaScript渲染。

请求超时意味着一个操作在监督它的组件达到截止日期之前没有完成。未完成的操作可能是打开连接、上传请求、等待响应或等待浏览器元素。这些失败需要不同的调查。在没有识别出未完成阶段的情况下，仅仅增加一个超时值可能会让实际问题未被触及。

对于数据收集工作，首先提出两个问题：哪个组件停止等待，什么已经完成？客户异常、HTTP 响应和浏览器导航错误是不同的证据。在更改您的网络路由或提取逻辑之前，记录这一区别。

请求超时的原因是什么？

请求超时发生在网络进度、服务器工作或应用程序等待超过其配置的时间预算时。缓慢的 DNS 解析、连接建立问题、上游处理延迟、大数据传输和等待缺失页面元素都可能消耗该预算。

考虑完整的路径：你的工作进入本地队列，建立连接，发送请求，接收响应，并处理结果。渲染页面增加了浏览器启动、文档加载、脚本执行和元素准备。最后期限可以涵盖一个阶段或多个阶段。单独的“超时”一词并不能界定边界。

一个有用的事件记录明确命名了操作：“连接建立超过其限制”传达的信息比“网站超时”更多。请包含请求的主机名、操作名称、经过的时间以及是否接收到响应头。这些事实缩小了调查范围，同时不暴露账户凭据。

客户端超时，HTTP 408 和 HTTP 504

客户端超时是一个本地决定停止等待；HTTP 408 和 HTTP 504 是服务器发送的响应。 在 HTTP 状态语义408涉及服务器未能及时收到完整请求，而504涉及网关等待上游响应的时间过长。

超时可能发生而没有任何 HTTP 状态，因为客户端从未收到 HTTP 响应。在您的监测系统中，不要为这种情况制造 504 值。为本地故障保留一个单独的错误类别，当不存在响应时，状态字段为空。

在更改截止日期之前找到缓慢阶段

阶段定时有助于区分慢速目标与本地拥堵或浏览器等待错误条件。浏览器导航测量区分诸如连接建立和响应处理等阶段； 导航时序 定义浏览器计时模型。

连接与传输

检查目标是否可达，配置的代理是否可访问，以及TLS连接是否完成。如果连接成功但第一个响应字节到达得晚，则将注意力转向网关或源。如果字节及时到达但传输随后停滞，请检查响应大小和进度，而不是将事件视为连接问题。

在您操作的系统上，比较应用程序处理时间与排队等待的时间。当请求等待可用工作者时，快速处理程序仍然可能导致缓慢的用户体验。如果您的平台公开了这两个持续时间，请记录它们。

浏览器准备情况

一个页面可能在后台请求继续进行的同时显示所需数据。相反，文档可以在产品列表出现之前完成加载。选择一个表示您需要的数据的完成条件，例如一个可见的结果容器加上一个必填字段，而不是假设一个通用的页面事件证明了提取的准备就绪。

当选择器等待时间到期时，检查实际页面。一个同意提示、一个拒绝访问的屏幕、一个更改的模板，或一个确实为空的结果都可以解释缺失的元素。更多的等待并不能使元素在错误的页面上存在。

多个超时预算如何相互作用

一个工作流程可以有几个独立的截止日期，最早适用的截止日期可以结束操作。您的 HTTP 客户端、网关、托管服务、浏览器导航和作业运行器可能各自监督不同的时间间隔。

这 无残留通用爬虫API超时策略 区分页面加载与累积指令执行。其文档页面加载限制为30秒，而其全局指令执行限制为180秒。页面加载限制可以在达到全局限制之前停止处理。这些是特定于服务的值，而不是每个HTTP客户端或浏览器的默认值。

例如，配置了更短截止日期的调用者可能在服务完成其他允许操作之前停止监听。这并不能证明服务在同一时刻失败。将调用者的预算与文档服务行为及工作的业务截止日期对齐，同时保持有限的上限。

在调整这些边界之前将其写下来。识别出您的团队控制的设置和属于上游提供者的设置。地方配置变更不能扩展提供者独立强制的上游限制。

一次实用的超时调查

有用的超时调查跟踪一次请求跨越其可观察阶段，并仅更改证据所关联的设置。使用您被授权收集的公共页面，并保持调查范围有限。

1. 捕获确切的异常或响应、操作名称、可用的最终URL以及经过的时间。
2. 确定是否观察到连接、响应头、响应体和所需的页面内容。
3. 检查附加到不完整阶段的截止日期和任何封闭的工作截止日期。
4. 在更改选择器或等待条件之前检查最终表示。
5. 在这些测量可用时，将本地资源使用情况和队列深度与目标侧的计时进行比较。
6. 进行一次基于证据的更改，并在小的授权样本上评估完成情况和输出的正确性。

假设一个目录作业成功接收HTML但从未观察到价格容器。第一项任务是确定HTML中是否包含目录、位置选择器或安全响应。如果目录具有新的标记模式，则更新提取条件。如果响应是拒绝，则将作业路由到访问审查。如果价格在合法用户选择后加载，则在批准的工作流程中表示该选择。

这个例子是一个诊断场景，而不是一种测量性能的声明。其目的是展示为什么相同的可见症状可以导致不同的纠正措施。

防止慢工作在管道中传播

有限的工作单元和明确的失败记录可以防止一个缓慢的页面掩盖整个数据集的状态。保持请求级的结果与提取可能产生的业务记录分开。

不要仅仅因为请求过期而写下空的价格、标题或可用性值。有效页面中的缺失字段和从未获取的页面有不同的意义。将“由于获取失败未观察到”与真正的空结果分开记录。

限制使用相同受限资源的同时作业数。当本地浏览器容量饱和时，增加更多工作可能延长队列时间而不是增加有效的吞吐量。从测得的容量和目标允许的容量中选择并发性，而不是从其他网站复制的通用数字。

这 无残留通用爬虫API 为公共网页提供了一个受管理的获取表面。您的应用程序仍然需要输出验证、截止日期政策和识别失败阶段的错误记录。在扩展之前，审查 无残留定价 与您的工作负载范围。

讨论 PHP网页抓取和远程浏览器计时 提供了一个相关示例，说明客户配置和运行时环境必须一致。将其实施选择视为特定于该工作流，而不是通用超时设置。

结论

通过识别停止等待的组件和保持不完整的阶段来诊断请求超时。保持客户端异常与HTTP响应的区分，使用内容特定的浏览器就绪条件，并将嵌套截止日期与服务合同对齐。最佳改进是消除观察到的瓶颈，同时保持准确的数据和有限的工作。