记得几年前，“我”还是有点洞察力的“萌新”，曾有人建议“我”为网站修改“自动采集”功能。这的确是一个很好的想法，不需要额外的编程语言和IDE工具，自动增加网站内容的同时，还能为网站编辑减轻不少负担并提高编辑的创作空间和自由。同时也凸显网站“高大上”的形象：智能化。听起来多么美好......“我”考虑几秒就否决该美好的提议。

为何？

事实上，很可能，很多主流网站都具备自动采集的功能。但是，使用PHP网站作为采集用途真的妥当？！

我们知道，动态网页是在服务器上执行，执行完成后将结果反馈给客户端浏览器。也就是说动态网页消耗服务器的硬件和软件资源。换句话说，如果使用PHP网站采集功能，PHP采集执行影响服务器性能，占用服务器CPU时间片。下面来进行一个简单的采集测试。这是一个包含20多个页面的图集。每个页面包含多张图片，一张目标高清图片。目标计划为：使用PHP代码通过网络识别采集每一个页面，并提取目标图片，下载保存该图片。测试环境为Windows10+PHP7.x+Apache2.4.x，相关PHP library库为cURL。本地硬件为多核主机，网络带宽10-20Mbps。以下为测试一中的系统负载图示。

从以上图示可以看出，该采集活动持续达到156秒！远超过60秒的时间！采集执行期间，CPU负载大部分处于“较低”水平，大概在单核3%-10%的占用率。这是服务器和客户端都在同一主机环境中的情况。另外在同一浏览器中，开启两个页面同时进行采集，发现第二个页面长时间无应答，处于等待状态。

需要特别注意的是，整个采集活动中，仅仅涉及的是普通的网络和本地文件IO的问题，没有包含数据库读写相关动作。

由此可见，PHP在采集方面，时间效率是一个需要谨慎对待的问题。在Apache、Nginx等CGI Server软件当中，往往默认设置页面最大响应时间。这个时间一般是60秒。单个页面如果在指定时间内没有响应，则被判定为超时，进而被服务器软件停止提供Web服务，终止执行进程。实际应用中，采集活动还需要将数据保存至数据库。除了涉及数据库优化问题，还有数据勘误和安全问题。因为机器自动采集到的数据不一定完全符合预期要求，或者不是期望采集的目标数据。

正如之前所说，虽然诸多限制，PHP网站上的采集功能还是具有较大的吸引力。毕竟这能或多或少提高工作效率不是？