我的公司使用SilverStripe v3.1.21以及子网站模块来显示和管理许多销售产品的客户网站。这导致接近200个子网站和数万个页面计数。这些网站加载速度非常慢，Google的PageSpeed等工具告诉我们页面速度很差。我们已经完成了组合和最小化JS以及压缩成像等资源的步骤，这提供了一些改进，但页面仍然很慢。该系统在此状态下交给我们，进一步的硬件升级不作为选项，也没有获得额外的资源用于重新开发。
我们已经看过静态发布模块（https://github.com/silverstripe/silverstripe-staticpublisher）并发现当我们生成静态页面时，页面变得很快并且在各种工具上获得了很好的分数，但是重新生成所有这些页面需要14个小时，这是不可接受的，因为这些产品每天都会从外部来源更新。我们还发现再生过程是一个内存耗尽，因为模块在转储到文件之前构建内存中的所有页面，导致进程崩溃。我们不得不改变流程以逐个子网站进行运行。
然后我们看一下静态发布队列模块（https://github.com/silverstripe/silverstripe-staticpublishqueue），它似乎通过让页面根据需要进行重新排队来解决我们的问题，使其对更改更加敏感。但是，该模块似乎非常错误，并且在生成页面时经常崩溃。
是否有人有使用这些模块（或类似）与大型网站的经验，并且可以提供有关如何成功实施静态发布的任何指示或想法？
答案 0 :(得分：1)
我们目前在多个网站上使用staticpublishqueue。我们遇到的唯一问题是由于长时间构建和锁定不良而导致崩溃。或者确切地说，它实际上并没有崩溃，而是在服务器变得不负责任之前不断产生越来越多的实例。
我认为我们在fork中已经解决了这个问题。至少我们在使用修改后的锁定后没有任何问题。您可以尝试安装the fork而不是正式版。如果这可以解决你的问题，我们应该提出拉动请求：）
答案 1 :(得分：1)
第一个：我们只使用staticpublishqueue，我没有任何关于子站点模块的经验。所以我不能说出你的确切组合。
我们在一个巨大的网站上使用staticpublishqueue。设置：我们有多台运行SilverStripe网站的服务器。他们共享MySQL数据库并使用Redis作为会话存储。 关于staticpublishqueue的一个好处：你可以并行运行它。因此，服务器都运行staticpublishqueue实例并发布到共享文件夹，然后在实际的Web服务器之前同步到nginx负载均衡器。工作得很好，但它无法无限扩展。在某些时候，staticpublishqueue实例开始选择相同的记录来渲染和浪费资源。我认为6对我们来说是最大的。
我们学到了关于staticpublishqueue的一些事情：
不要同时运行多个实例（见上文）
确保它有足够的内存
确保它以与网站
它使用的记录外观与MariaDB Galera群集不兼容
如果可能，请切换到SilverStripe 3.6.x和PHP7。性能提升很大。
我们正在从staticpublishqueue迁移到Cloudflare（或者可能是另一个CDN）。为什么？因为如果尚未呈现请求的页面，则服务器将单独为每个请求呈现它，然后将其丢弃。直到que为缓存执行单独的渲染。资源浪费总量，特别是在全站点布局更改后清除缓存时。