我如何将软件系统的性能提高35,000％( 二 ) _软件系统

从技术上讲，Heroku上的整体请求响应时间限制为30秒超时，实际上，我们希望大多数面向客户页面的请求能在3秒内完成。我个人认为超过8秒的任何时间都被视为中断。
第50个百分位数通常在100毫秒以下，因为许多请求都是快速完成的API端点。
第99个百分位数可能会超过20秒而没有问题，因为某些管理页面仅花了一段时间才能完成。
我真正关心的是第95个百分点-我们希望95％的请求在3秒内完成。这95％代表了大部分客户请求和参与，并代表了捐助者将经历的事情。
低挂优化让我们看一下低挂的优化成果是什么：
· 垂直和水平缩放
· N + 1个查询
· 低效的代码
· 背景
· 资产最小化
· 内存泄漏
· 共置
垂直和水平缩放垂直缩放我要做的第一件事就是增加每个服务器的功能-通过垂直扩展实现性能。我为每个服务器提供了更多的内存和处理资源，以帮助更快地服务和满足请求。

文章插图
> Here, New Relic is showing a large spike in request queue time. In this case, it was time spent wa

但是，垂直缩放具有一些缺点。其中之一是您可以垂直扩展单个实例的数量有实际限制。
第二个缺点是垂直扩展会变得非常昂贵。当您没有无限的资源时，成本将成为主要考虑因素，也是决定权衡因素的一个因素。
水平缩放如果一台服务器每秒可满足10个用户请求，则粗略估算表明10台服务器每秒可满足100个请求。实际上，它并不能完全线性地扩展，但是对于一个假设来说是很好的。这称为水平缩放。
我们将服务器配置为根据各种指标自动扩展。随着服务器启动以处理任何增加的活动，我们发现等待延迟/排队时间通常会出现一个小的峰值。一旦额外的服务器完全启动，随着系统适应增加的负载，流量请求队列时间就会减少。

文章插图
> As activity increased, we automatically spun up more servers, which allowed us to handle the incre

几个挑战水平缩放并非一帆风顺。
在代码库中有很多不是线程安全的实践。例如，在代码库中使用类实例变量作为共享状态非常流行，这导致线程彼此覆盖。我不得不花费大量时间来遍历它，并修改算法和代码来以某种方式管理数据这对于多线程环境是安全的。
我还必须实现更好的连接池和管理技术-我们经常会耗尽与各个商店的连接，因为许多存储都是硬编码的，并在实例化时建立了直接连接，这意味着如果存在，应用程序实例将无法处理任何事务。没有可用的连接。
在Heroku上缩放虽然您可以并且应该在其他平台上设置缩放比例，但是我们使用的是Heroku，而Heroku使缩放变得容易。
【我如何将软件系统的性能提高35,000％】您拥有可控制的测功机数量，并且具有增加每个测功机功率的能力。如果您需要更细粒度的控件，那么像HireFire这样易于集成的供应商将提供扩展配置选项，这些功能可为您提供强大的功能和灵活性。
您还可以设置与网络服务器并发性相关的内容。我们正在使用Puma，它不仅可以通过WEB_CONCURRENCY标志来更改工作程序的数量，还可以选择更改每个进程的线程数。
结果可自定义的垂直和水平缩放比例相结合，使我们在为各种性能特征准备场地时具有极大的灵活性。
这是一项长期的工作。在确定将成本，性能和资源使用量平衡到可接受水平之前，我不得不在扩展阈值方面做很多工作。由于可接受的级别在公司及其环境中会有所不同，因此我建议将其作为一种实践，以不断地适当地测试扩展配置。
N + 1个查询N + 1查询是需要其他查询才能完整了解数据的查询。它们通常是由于数据检索注意事项或体系结构问题而引起的。
例如，假设您有一个需要返回捐赠的端点和捐赠的捐赠者。N + 1查询可能隐藏在其中-首先必须进行查询以检索所有捐赠，然后对于每次捐赠，还必须获取捐赠者记录。
通常，附加查询会隐藏在检索后的序列化器中，尤其是在Ruby on Rails中：

class DonationsControllerdef index donations = Donation.allendendclass DonationSerializerbelongs_to :donor# This will result in a N+1 query (see above)# because the query it is being used on doesn't load donors.end

N + 1查询的解决方案通常包括急于加载相关记录并确保在初始查询中将其提取：