大量访问时加载 iframe 内容的延迟和低速答案

【问题标题】：Delay and low speed in loading iframe content at huge visit大量访问时加载 iframe 内容的延迟和低速
【发布时间】：2015-08-09 09:29:06
【问题描述】：

在将存储超过4 million 记录per day 的系统上工作。
为了减少 I/O 并提高速度，我将存储从数据库更改为文件。所以数据会变成json直接写入文件。

问题

当访问量上升并达到每分钟近 3000 次访问时，iframe 加载速度显着降低，而且有时会导致 iframe 中的打印服务器超时。

我正在寻找减少资源使用和提高加载速度以及防止超时的方法。

任何帮助将不胜感激...

【问题讨论】：

是什么让你的服务器变慢了？横幅图片？你确定这是最快的将数据库更改为文件吗？你的 apache 中有压缩系统吗？你的 php 中有一个编程缓冲区吗？抱歉，有了这些信息，我无法为您提供更多帮助。
也许这个链接对你有帮助：digitalocean.com/community/tutorials/… | giftofspeed.com/apache-server
@MarcosPérezGude 感谢您的回答，将数据库更改为文件至少可以使我的读/写更好并减少使用的存储空间，并且据我测量，我面临的时间范围内没有显着变化。据我所知，我的服务器上没有可用的压缩系统
@MarcosPérezGude 真的很感谢您的帮助，我会告诉我们的服务器管理员执行这些操作，并尽快在此处列出规范。
@HosseinShahsahebi 是的，我更认为您可以通过将内容存储在那里而不是数据库或文件来避免磁盘 I/O，以防磁盘 I/O 阻碍了事情。当然，您仍然需要一个 cronjob 来从 memcached 中检索项目并永久存储它们，但这可能会减少您的瓶颈。另外，只是一个想法 - 如果它在 Apache 上运行，您是否检查或修改了 MaxClients，以防只是您的所有 httpd 进程都在使用并且正在备份请求以等待空闲进程？尚未阅读所有答案或您的回复，因此这可能无关紧要:)

标签： php performance iframe

【解决方案1】：

每分钟有 3k 个请求，并且有增长的希望，您需要开始使用 big data 架构和工具。

以下是一些需要考虑的广泛的图片亮点：

使用单独的CDN 来存储和提供图片。
使用mapReduce软件存储数据，如hadoop。
获取distributed 的服务器，而不是一台庞大的服务器。
添加load balancing 服务器。
关闭所有不需要的 php 功能和扩展。

【讨论】：

感谢您的回答，这似乎是一个很好的答案，但似乎也需要对现有项目进行非常深入的结构性更改。我认为这是一个很好的答案，但让我提出问题让其他人回答，最后我会做出决定。

【解决方案2】：

在您的应用程序规模的这个特定点上，我将重点关注对您的基础架构和代码逻辑的两项具体改进。

将向最终用户提供横幅资产所需的流程与存储广告印象所需的流程分离。
实施一个水平可扩展的基础架构来接收请求。

1。将投放横幅与存储印象分离

通过分离这两个问题，您将能够为您的ppc 服务的客户提供更一致的性能。如果您还没有，使用 CDN 或以其他方式卸载从服务器提供图像本身的需求可以帮助大大缩短响应时间。

另一个能给您带来巨大收益的领域是将横幅代码的服务与将展示数据存储到磁盘的进程分开。有很多方法可以做到这一点，但我有过的一个成功的解决方案是使用 ActiveMQ (http://activemq.apache.org/) 或类似的排队系统。排队系统将通过将印象数据存储在内存中并以一致的速率将这些数据点发送到可以将该数据存储到数据库或其他存储介质中的消费者（又名工作人员）进程来帮助平衡您的印象存储负载。这使得在磁盘上实际存储印象的工作量与提供广告的过程分离。您还可以设置多个进程来使用排队的作业，这导致了第二个改进领域。

2。可横向扩展的基础架构

构建一个水平可扩展的解决方案基本上意味着您无需增加单个服务器的大小和功能，只需添加额外的更小的服务器，这些服务器将平均分担系统需求的工作负载。这具有多个优点，其中之一是向池中添加更多小型服务器更容易（通常更便宜），而不是将一台大型服务器升级为更大更强大。它还具有在服务器发生故障时更加健壮的优势。

在这种情况下，我认为一个好的解决方案是让一个服务器或进程充当路由器，它将通过将请求发送到实际处理请求的不同服务器来负载平衡请求。互联网上有很多关于在 PHP 中构建路由或负载平衡脚本的好资源，但基本上您将在一个端点接收请求，然后将该请求发送到另一台服务器以实际执行。如果您构建准备好接收请求的服务器的动态列表，那么当您开始看到不可接受的性能时，您可以轻松增加满足请求的服务器数量。这也将使您能够在服务器出现故障时轻松地从列表中删除它，然后任何流量都会被路由到仍在运行的其他服务器。

如果您还没有，最好研究一下 lighttpd (http://www.lighttpd.net/) 或 nginx (https://www.nginx.com/) 作为 Apache 的替代品，它们旨在以更少的开销处理大量请求。这些特别适合处理路由器服务器上的请求。

为请求设置水平扩展后，为存储服务器设置水平扩展也将相当简单。您可以通过根据池中服务器的数量修改 ID 来轻松完成此操作，以确定将请求发送到何处。

$serverNumber = $adID % $availableServers;

总结

尽管通过优化存储方法和服务器调优您肯定可以看到良好的性能改进，但在大型应用程序中的某个时间点，您可能希望能够添加额外的服务器来完成工作。我认为通过上述步骤，您将处于一个非常好的位置，可以随着应用程序的规模增长而顺利扩展应用程序。

【讨论】：

首先，我非常感谢您的详细描述。不知何故，这是Skarlinski 在他的回答中提供的两个最重要选项的细节。在这些话之后，我不得不问一些关于负载平衡的问题。如您所说，一台服务器将是路由器。现在这台服务器将成为系统的瓶颈，同样的问题也会出现。我说的对吗？
这种设置的好处是它如何分离职责并将它们委托给不同的进程处理。路由器服务器只负责引导请求，因此它应该能够处理足够的流量来保持大量数据库和广告服务器的繁忙。如果您需要多个路由器服务器来处理您的流量，您可以查看 http 级别的负载平衡。几个选项是专用的 nginx 服务器 (nginx.org/en/docs/http/load_balancing.html)，或者更便宜（有一些缺点）使用 DNS 负载平衡。

【解决方案3】：

您可以利用现有的 Apache 访问日志作为印象跟踪器，并完全关闭您的自定义数据库/平面文件读/写代码，从而节省性能和开发时间。

设置一个新的 Apache 虚拟主机，并将其指向一个系统 webroot 目录，您将让该目录完全负责提供您的广告生成 PHP 脚本。在这个虚拟主机配置中，您可以设置一个 100% 专用于投放广告的系统访问日志； Apache 将负责在每次访问（印象）时附加到此日志并根据需要轮换/归档日志。您可以指向要存储日志的任何位置以及将哪种类型的服务器/环境/引荐来源/用户代理数据存储到其中。

然后，通过 cron 或守护程序，您可以运行任何您想要的后端日志分析器，将统计信息收集到数据库中，处理您的数字等，而无需将任何繁重的工作与实时 Web 请求耦合。

我还在 Stack Overflow 上发现了使用这种技术 with lighttpd instead of Apache 进一步扩展服务器资源的建议。

进一步阅读：

【讨论】：

更多信息

问题

1。将投放横幅与存储印象分离

2。可横向扩展的基础架构

总结