在Freshdesk，我们致力于为客户提供卓越的体验。因此，速度对我们至关重要。为了实现这一点，我们的前端（在这里加载资产并完成UI的绘制）以及为Web和API客户端提供数据的后端应该能够正常工作。在这篇文章中，我们将解释Freshdesk如何从后端的角度来跟踪性能Freshdesk主要构建在rubyonrails上。在10年的时间里，代码库变得越来越大，它提供了1600多个url（Controller#action）。我们希望确保添加新特性和改进不会降低应用程序的性能。客户在使用我们的应用程序时应该感到高兴，并且不应该因为应用程序速度慢而分心。在一个庞大的代码库中，每一个版本中都有超过100名开发人员添加特性并对产品进行改进，因此性能下降或多或少是不可避免的。由于性能是客户满意度的关键，我们开始将其作为愉悦度指标进行跟踪我们每周都会对我们的表现进行评估。我们通过仪表板、票证列表和配置等模块跟踪和报告性能，每个模块都由不同的开发团队拥有。每个模块都有自己的一组URL路由。如果某个模块的性能已降级，则该模块中的一个或多个url将开始表现不佳。这可能是因为在最近几周的一次部署中，新的代码变更被推到了生产环境中，淘客qq群，或者可能是其他问题，包括基础设施的限制。相应的团队将对问题进行调试并立即修复到目前为止，我们追踪了Freshdesk超过85%的流量，在我们排名前10%的路线中提供服务。这样，我们就可以监控我们的性能，并为客户提供更好的体验。我们的跟踪方法对于每个HTTP请求，我们生成访问日志并写入一个名为应用程序.log，其中包含的详细信息包括控制器及其命中的操作、请求的原始IP、在DB、Redis、Memcache等各种组件中所用的时间、作为请求流一部分的Redis调用和Memcache调用的数量，以及处理请求的总持续时间；全部以逗号分隔的值记录（如下图所示）。它还包含了请求背后的帐户id和用户等详细信息，我们非常依赖Redis和Memcache，因此，我们也有必要记录它们的持续时间。在Ruby库time_bandits的帮助下，我们计算在Redis和Memcache中花费的时间，这有助于我们调试性能问题。我们运行一个logrotate容器作为一个sidebar和一个app容器。Logrotate负责将过去15分钟累积的应用程序日志放入S3中的bucket中。我们的应用程序将日志从baikals3的应用程序中提取出来，并将其从baikals3平台解析到日志中。我们的应用程序访问日志以可查询格式提供，用于分析和报告。我们还为每个控制器操作对（每个路由）设置正确的阈值。例如，对于所有客户，大数据技术，ticketshow API必须在150毫秒（毫秒）内执行。定义阈值根据我们产品团队的分析和建议，我们非常小心地设置了后端阈值。分析如下：在优化web和应用程序性能时，有三个主要的时间限制（由人类的感知能力决定）。0.1秒是让用户感觉到系统正在即时反应的限制，这意味着除了显示结果外，不需要任何特殊的反馈。1.0秒是用户思想流不受干扰的限制，即使用户会注意到延迟。通常，对于0.1到1.0秒之间的延迟，不需要任何特殊的反馈，但是用户确实失去了直接操作数据的感觉。10秒是保持用户注意力集中在对话上的限制。在较长的延迟期间，用户会转向其他任务，因此应该向他们提供反馈，指示计算机何时完成任务。如果响应时间可能是高度可变的，企业管理软件下载，那么延迟期间的反馈尤其重要，因为用户将不知道会发生什么。（另请阅读：10的力量：用户体验的时间尺度，返利商城系统开发，响应时间和延迟的最佳实践）除此之外，在服务器端定义阈值时，我们还做了以下假设：我们需要在URL的阈值限制中添加往返时间，以达到最终的用户交互时间。看看平均AWS延迟，假设用户位于我们4个数据中心中最近的一个，几百毫秒应该是我们可以添加到服务器的API响应时间的适当往返时间。UI呈现也需要时间，尤其是对于呈现的大量元素。Freshdesk的操作方式可能第一次加载需要时间，但之后每次交互都更像是浏览器上现有应用程序上的差异。基于这些，我们将后端阈值分为四个部分（数字是指示性的）。1） 有些行动需要看起来是即时的。我们应该对他们有极低的门槛。用户不应该觉得他们在等待。对于这些行动，我们定义了更严格的门槛。2） 对于经常发生但用户不耐烦地等待完成的操作，快感阈值为200ms。3） 对于经常发生但用户知道正在加载列表的操作，快感阈值约为600毫秒。4） 对于在后台进行的操作（不是由用户和工作流发起的，也没有影响），愉悦度指标是1500毫秒。报告生成我们有一个阈值表，它映射了每个控制器动作及其所属模块的阈值例如： 我们希望每一次行动中，我们95%的请求都在阈值范围内，以便认为自己在该行动中表现更好。我们使用以下示例查询计算该指标：1234567891011213选择舍入（100*总和（如果(持续时间>t.threshold，0，1）），2）/COUNT（1）表示高兴，COUNT（1）表示没有请求al.控制器,       行动,t.module AS moduleFROM application_记录为alJOIN thresholds t ONal.控制器=t.控制器和行动=t.actionWHERE在${START_DATE}和${END{DATE}之间创建了一天，status=200分组依据al.控制器,         行动，t模块；我们的报道也是这样的。我们计算每个操作的请求在阈值范围内的百分比，并通过获取映射到该模块的操作的加权平均值来报告it模块。我们使用我们的内部工具Supreme每周生成此报告。一个示例报告如下图所示（屏幕截图中的数字是指示性的）。 如果一个加权平均数下的两个或多个操作，或者有大量请求的单个操作执行得不好，则加权平均值将显示出下降。这样，我们就可以把更多的精力放在重要的问题上。例如，国内云服务器哪家好，上一个模块在6月的前两周表现不佳，因为加权平均值分别只有88.73和88.81，如上面的屏幕截图所示。因此，我们必须检查模块，看看哪些操作执行得不好，并修复与之相关的问题。Supreme还为我们提供了每日报告中的加权平均指标，这有助于我们了解问题何时存在，是否存在性能下降。除此之外，Supreme还为我们提供了各种高级指标，如过去90天和过去28天内所有模块的加权平均值，这让我们对上个月和过去三个月的总体表现进行了概述。我们还获得了地区层面的指标，因为找出客户在出现任何问题时可能面临的业务放缓的地区非常重要。通过这种方式，我们能够发现性能问题并更快地采取行动。这对我们的客户和我们自己来说是双赢的。它有助于我们控制我们的基础设施。我们不需要增加基础设施，因此会因为性能问题而产生更多的成本。同时，我们不仅仅是在客户提出的性能问题上使用创可贴，而是积极主动地采取行动，从长远来看，这将使我们的应用程序的性能保持良好。这有助于我们在内部形成一种文化，即在开发产品时也要注意性能，这是赢得大客户和终身拥有客户的一种手段如果报告显示性能下降，我们如何调试问题所在？我们会尽快通知你的。相关岗位快速破解，用最少的代码减轻数据库负载使用定制中间件的Sidekiq队列管理