在CI/CD中，我们的构建时间已经达到了极限。我们已经预先渲染了9 k的页面，我们已经切换到ISR，我们可以在运行中更新和生成不太相关的页面。在小负载测试中，我们看到整个next.js应用程序的整体性能大幅下降。奇怪的是：所有的服务器从来没有死过。负载测试也以超时结束，Web服务器以某种方式排队。我们已经看到一些页面的构建时间长达60秒，之后它被交付并在缓存中可用。有人遇到过类似的问题吗？也有人知道如果我们使用CI/CD位桶来减少构建时间，我们如何增加马？
cuxqih211#
我面临着一个非常类似的问题，一个大型的ecomerce /价格比较网站，大约有180 k的页面，都需要不断更新，以显示正确的价格/相关数据。我们遇到的问题是，当在后台重新验证页面时，在我们的情况下，很容易每秒不少于100个页面，服务器将花费非常长的时间来生成页面，并且还将导致对已经存在的页面/应用程序的实际网络请求变得非常缓慢。我会推荐三种方法之一，这取决于您的托管可用性和您希望解决方案的复杂程度1.垂直缩放。1.水平缩放。1.使用自定义服务器的自定义ISR实现1和2基本上只是要么支付更强大的服务器，要么将应用程序分布在多个服务器上3（这是我们的选择）。我们实现了一个custom server，并使用getstaticprops进行重新验证，而不是使用getServerSidePropson每个页面。这允许我们将页面内容存储在缓存数据库中。这对我们来说是非常好的，因为它允许我们在返回响应的实际服务器之外生成页面。这意味着无论我们在运行的站点的不同版本中后台生成的页面数量如何，都不会对将页面返回给用户的服务器产生影响
1条答案
按热度按时间cuxqih211#
我面临着一个非常类似的问题，一个大型的ecomerce /价格比较网站，大约有180 k的页面，都需要不断更新，以显示正确的价格/相关数据。
我们遇到的问题是，当在后台重新验证页面时，在我们的情况下，很容易每秒不少于100个页面，服务器将花费非常长的时间来生成页面，并且还将导致对已经存在的页面/应用程序的实际网络请求变得非常缓慢。
我会推荐三种方法之一，这取决于您的托管可用性和您希望解决方案的复杂程度
1.垂直缩放。
1.水平缩放。
1.使用自定义服务器的自定义ISR实现
1和2基本上只是要么支付更强大的服务器，要么将应用程序分布在多个服务器上
3（这是我们的选择）。我们实现了一个custom server，并使用getstaticprops进行重新验证，而不是使用getServerSidePropson每个页面。这允许我们将页面内容存储在缓存数据库中。这对我们来说是非常好的，因为它允许我们在返回响应的实际服务器之外生成页面。这意味着无论我们在运行的站点的不同版本中后台生成的页面数量如何，都不会对将页面返回给用户的服务器产生影响