我目前的任务是为严重的PHP瓶颈找到解决方案，该瓶颈显然是由我们的网站在高负载下时服务器端缩小CSS和JS引起的。
一些细节和我到目前为止发现的内容
我继承了一个在Wordpress上运行的Web应用程序，它使用复杂的Doctrine，Memcached和W3 Total Cache进行缩小和缓存。在重负载下，我们的应用程序开始迅速变慢。到目前为止，我们已经将部分问题缩小到服务器端缩小过程。初步分析表明，PHP 进程的数量在负载下开始堆叠，当达到 500 个进程的进程限制时，开始减慢一切。缩小库的作者也提到了一些事情。
到目前为止我评估过的解决方案
预缩小
最合乎逻辑的解决方案是在上线之前预先缩小任何文件。不幸的是，我们的工作流程要求非开发人员应该能够在我们的生产服务器上编辑所述文件（即在 Web 应用程序上线后）。因此，我认为预处理是不可能的，因为它限制了缩小文件的可编辑性。
提供未缩小的文件
75%的用户使用他们的移动设备访问我们的Web应用程序，尤其是智能手机。未缩小的JS和CSS大小为432KB，缩小后的大小减少了60-80%。因此，在解决性能和可编辑性问题的同时，提供未缩小的文件是为了移动用户而
行之。我知道这既是一个技术问题，也是一个工作流程问题，我想只要我们最终获得更好的整体性能，我们就愿意在这两个问题上工作。
我的问题
是否有解决PHP瓶颈的合理折衷方案问题，允许非开发人员对实时 CSS/JS 进行更改，并且仍然向客户端提供合理大小的文件。
如果没有这种一刀切的解决方案，我该怎么办更好的工作流程和/或服务器端行为？
编辑：因为有一些关于服务器配置的问题/评论，我们的服务器运行Debian，并配备了32GB的RAM和24核CPU。
您可以通过Node.js运行 css/javascript 编译服务，如 Gulp 或 Grunt，在更改时缩小所有 js 和 css 资产。
此服务可以在生产中运行，但不建议在没有一些体系结构设置的情况下运行（具有多个版本化的编译文件并通过gulp或其他扩展自动检查它们）。
我强调将功能修补到生产中并直接 强烈建议不要编辑它，因为它可能会将实时问题呈现给 您的访问者降低了您的可信度。
http://gulpjs.com/
使用 Gulp/Grunt 需要您更改编写 css/javascript 文件的方式。
我会用 2 种解决方案来解决这个问题 - 首先，删除每次用户运行应用程序时运行的任何 WP-CRON 操作，并将其移动到服务器上的实际 CRON。 其次，我将使用负载平衡，以便单个服务器不会承担工作负载。 这是您真正的问题，即使您修复了感知到的代码问题，您仍然面临负载问题。
我认为您根本不需要更改工作流程或对现有系统进行重大修改。
每次加载页面时运行的 WP-CRON 任务会导致显著的负载和缓慢。 您可以将它从访问运行该进程的用户转移到仅在服务器级别运行它的服务器。 这减少了负载。它也很可能正在运行您认为正在减慢网站速度的这些进程。
请参阅本指南：http://www.inmotionhosting.com/support/website/wordpress/disabling-the-wp-cronphp-in-wordpress
下一个 - 负载平衡。 当您有大量流量时，让一台服务器为所有用户提供服务是一个糟糕的主意。 您需要拆分网络服务器负载。
我不确定您在哪里或如何托管，但我会将内容转移到 AWS。 设置我的WordPress网站进行负载平衡@AWS：http://www.mornin.org/blog/scalable-wordpress-amazon-web-services/
这将涉及：
- 负载均衡器
- 运行 PHP/Apache 的 EC2 实例
- 适用于所有 EC2 实例的数据库存储的 RDS
- 站点媒体的 S3 存储
对于用户会话，我建议您在负载均衡器上设置粘性，以便用户持续获得他们到达的同一节点。
您可以在此处获取有关如何执行此操作的详细指南：http://www.mornin.org/blog/scalable-wordpress-amazon-web-services/
或者在服务器故障时采用另一种方法：https://serverfault.com/questions/571658/load-balancing-wordpress-on-amazon-web-services-managing-changes
这里的假设是，如果你是高流量，你就会从这个高流量中赚取收入，所以每当你的服务响应缓慢时，它都会拒绝用户或可能阻止他们返回。 更改软件可能会有所帮助 - 但您正在治疗症状而不是疾病。 疾病是您的服务器负载过重。 这在WordPress和高流量中并不少见，因此您需要分散负载而不是尝试进行微优化。不同之处在于优化将是小收益，而负载的负载平衡和分布实际上解决了问题。
最后 - 考虑使用 CDN 来提供所有媒体。 这样可以更快地加载媒体，并通过减少对服务器的请求量来消除系统的负载，并将其输出到客户端。 它还通过从离他们最近的节点提供媒体，为访问任何地方的人更快地加载页面。在AWS，这被称为CloudFront。 WordPress还通过Jetpack免费提供这项服务（我相信），但根据我的理解，它不能处理所有媒体。
我喜欢使用GulpJS的想法。您可能会考虑的一件事是拥有一个 wp-cron 甚至只是一个每 5 分钟左右运行的系统 cron，然后运行一个 gulp 任务来缩小和连接您的 css 和 js 文件。
另一个不需要调度但基于观察文件系统的更改然后触发 Gulp 构建发生的选项是使用 incron （inotify cron）。查看 incron 手册页。Incron 的伟大之处在于它根据文件系统事件（如文件更改）触发操作。您可以使用它来在文件系统上的任何 css 文件更改时触发 gulp 构建。
需要注意的是，这是一个Linux解决方案，因此，如果您在Windows上托管，则可能需要寻找类似的东西。
编辑：增量文档