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

内存泄漏的主题完全是一篇文章，但是这里有两个非常有用的链接可以节省您的时间和精力：
· 我如何花两周的时间来寻找Ruby中的内存泄漏
· 使用jemalloc改善ruby应用程序的内存使用率和性能
代管我们使用的某些服务所关注的区域与服务器所在的区域不同。
我们的服务器位于弗吉尼亚北部（us-east-2），但某些服务（例如S3）位于俄勒冈州（us-west-2）。当执行许多操作的工作流必须与该服务进行通信时，所产生的延迟会迅速加起来。
这里的几个MS和几个MS可以快速累加起来。通过确保我们的服务位于同一区域，我们消除了不必要的延迟，从而极大地加快了查询和操作的速度。
帕累托再次罢工上面的部分说明了我为提高性能而使用的各种性能杠杆。但是，我很快发现，它们是低落的果实。
调整和拉动杠杆可以显著提高性能和稳定性，但很快就可以看出，系统的单个部分负责绝大部分的性能，稳定性和扩展性问题。这完全是80/20规则。
这是瓶颈。这是我的白鲸。
停机时间剖析我加入公司后不久，就在一天结束的那一天，我们突然收到了来自客户成功团队的大量错误警报和疯狂消息。
SOS很清楚：该站点已关闭且无法使用。

文章插图
> The pale green section is request queuing time.

上图说明了发生的情况-负载显着增加，导致该站点长时间无法使用。
随着数据库使用率的增加（黄色区域），每个请求处理的时间也增加了，导致其他请求开始备份和排队（浅绿色区域）。
令人印象深刻的是停机时间的速度。事情非常非常迅速地备份。白天所有信号都很好，然后服务器突然不堪重负。
过时的事件响应手册当时我们执行了她的标准操作程序，这是启动更多服务器。
不幸的是，它的影响为零，因为大量的计算都延迟了所有Web请求，因此增加应用服务器的数量并不能解决问题。
与直觉相反，这实际上使问题变得更糟-向服务器提供更多请求使数据库承受更大压力。
是什么原因造成的？发生了什么？我们有一个缓存系统，从所有方面来看，它都运行良好。
深入研究，我发现如何实现缓存存在多个明显的问题。大量的漏洞使缓存系统成为整个平台的单点故障。
缓存为王让我们深入研究我们的缓存系统如何工作。
class Campaign cache_fields :first_name, :total_raiseddef total_raised # ...complex calculation here endendcache_fields将调用一个混合函数，该函数将对属性的访问包装在一个函数中，该函数将在尝试访问属性（或函数结果）之前先查看缓存。
但是，如果由于某种原因或其他原因在redis缓存中不存在值，会发生什么情况？
处理缓存未命中像所有高速缓存未命中一样，它将尝试实时重新计算该值并提供它，将新计算的值保存到高速缓存中。
但是，这有一些问题。如果存在缓存丢失，请求将在高负载时间内强制执行资源密集型计算。
很明显，以前的开发人员曾考虑过这一点-代码已经尝试过一种解决方案：计划缓存。
按计划缓存每5分钟将运行CacheUpdateJob，它将更新所有设置为要缓存的字段。
该缓存系统在理论上运行良好-通过定期缓存，该系统可以将内容保留在缓存中。
但是，它在实践中存在很多问题，我们在几天的奉献中发现了这些问题。
缓存更新问题的主要原因是缓存的填充和更新时间。
CacheUpdateJob将每5分钟运行一次，以尽责的方式计算值，并自计算之时起设置5分钟的到期时间。
这是一个隐藏的问题。从本质上讲，它保证了CacheUpdateJob始终仅在值从高速缓存中丢失后才进行更新。
缓存未命中当用户尝试在某个值从缓存中调出之后但在CacheUpdateJob可以缓存新值之前尝试访问该值时，将导致缓存未命中，从而导致实时计算该值。
对于少量的人来说，这是可以接受的，但是在主要的捐赠日，它将为每个请求执行重新计算。

文章插图
> Cache failures led to increased 500 Internal Server Error responses — a result of timeouts.

发生高速缓存未命中之后，直到任何一个请求成功完成并成功将值插入高速缓存为止，所有访问该数据的请求都将执行资源密集型查询，从而大大提高了使用率，尤其是在数据库CPU上。