Imagine you need to do a bank transaction, but the website is so slow. The page takes so much time to load, all you can see is a blue circle.

想象您需要进行银行交易，但是网站是如此缓慢。 该页面需要花费很多时间来加载，您只能看到一个蓝色圆圈。

Or imagine you are presenting something important to key stakeholders, but your screen is stuck. You wait for a few seconds, and again for a few more but with no luck. It would be terribly frustrating.

或者想象您正在向重要的利益相关者展示重要的内容，但是屏幕却卡住了。 您等待几秒钟，然后再等待几秒钟，但是没有运气。 这将非常令人沮丧。

System Performance issues are a reality. We face it from time to time.

系统性能问题是现实。 我们不时面对。

So much thought and time goes into designing a software application to enhance the user experience. Each minute detail around the layout, the look and feel, and the usability features would be given so much attention. Equally important is to design for optimum system performance.

设计软件应用程序以增强用户体验需要花费大量的精力和时间。 围绕布局，外观和使用功能以及可用性功能的每一分钟细节都将给予极大的关注。 同样重要的是要设计出最佳的系统性能。

The system should perform fast. The user would expect on the click of a button, the page should load or transaction should get processed. The experience should be seamless. There should not be any wait times. Otherwise, you might lose a client.

系统应能快速执行。 用户希望单击按钮即可加载页面或处理事务。 经验应该是无缝的。 不应有任何等待时间。 否则，您可能会失去客户。

Despite careful designing, development, testing, and implementation, there will be a time when the software applications perform badly for various reasons — businesses may undergo change, the design was not optimal or scalable, there were unknowns not thought through, etc.

尽管进行了精心的设计，开发，测试和实施，但有时由于各种原因，软件应用程序的性能会很差—业务可能会发生变化，设计不是最佳的或可扩展的，没有深思熟虑等等。

How do we approach performance optimization? Why and how does data analysis help in performance improvement? Can we have a framework to predict and prevent performance issues?

我们如何进行性能优化？ 数据分析为何以及如何帮助改善性能？ 我们可以有一个框架来预测和预防性能问题吗？

I have come across several such scenarios and in this article, I will share some views on each of these questions.

我遇到了几种这样的情况，在本文中，我将对每个问题分享一些看法。

如何进行系统性能优化？ —从发现问题开始。 (How to approach system performance optimization? — Start with the problem finding.)

When there is a system performance issue, everyone will come to know there is a performance issue, but most of the time, most of the people don’t know the exact problem.

当出现系统性能问题时，每个人都会知道存在性能问题，但是大多数时候，大多数人都不知道确切的问题。

There will be several user complaints to the service desk, Emails directly from frustrated end users, and possibly an escalation to senior management in severe cases.

将会有几位用户投诉服务台，直接从沮丧的最终用户那里收到电子邮件，在严重情况下可能会升级为高级管理人员。

At such a stage, it is a common tendency to come up with a quick fix to resolve the issue as soon as possible. While that is the need of the hour and may work sometimes many times, that won’t work.

在这样的阶段，通常的趋势是想尽快解决该问题。 尽管这是一个小时的需求，并且有时可能会工作很多次，但这是行不通的。

It requires finding out what exactly is the real problem, and that is hard. The business might have a view of a problem, IT developers and backend administrators might have a view that may differ, management may have an altogether a different view.

它需要找出真正的问题到底是什么，而这是很难的。 业务可能有问题的观点，IT开发人员和后端管理员的观点可能会有所不同，管理层的看法可能完全不同。

Performance specialists, database administrators, and application developers and functional consultants, business users — all need to work collaboratively to get to the root of the issue in many cases.

在许多情况下，性能专家，数据库管理员，应用程序开发人员和职能顾问，业务用户—在所有情况下，都需要协同工作才能找到问题的根源。

Questions like the below will get some insights.

诸如下面的问题将获得一些见解。

• What exactly is the performance issue? It impacts which business scenario?
  性能问题到底是什么？ 它影响哪种业务方案？
• Is there a performance benchmark? What was the expected performance and what is it now? What is the deviation?
  有绩效基准吗？ 预期的性能是什么，现在是什么？ 偏差是多少？
• Is the issue observed by all the end-users or it is specific business users? If the application is global, is the issue specific to any geography or applicable everywhere?
  是所有最终用户都发现了该问题，还是特定的业务用户？ 如果该应用程序是全球性的，那么该问题是针对特定地理环境还是在所有地方都适用？
• Has the system performance degraded at a specific time of the day or week? Is there any pattern?
  系统性能在一天或一周的特定时间降低了吗？ 有没有图案？
• How is the user accessing the software application? Over office internet? Via VPN? or home network? There could be several variations.
  用户如何访问软件应用程序？ 通过办公室互联网？ 通过VPN？ 或家庭网络？ 可能会有几种变化。
• What are the top scenarios that have been impacted? Does the scenario that has an impact matter? Sometimes, there is no correlation.
  受影响的主要方案是什么？ 有影响的场景重要吗？ 有时，没有关联。
• Is the issue reproducible?
  问题可以重现吗？

There could be so many such questions specific to the context above, just an indication, you get the point. With the right set of questions, you get the insight to work towards finding the real problem.

上面的上下文可能有很多这样的问题，只是一个提示，您就明白了。 有了正确的问题集，您将获得洞察力，以寻求真正的问题。

数据分析有何帮助？ (How does Data Analysis Help?)

Once we gather the info from the users, IT developers, and support staff and management, we get a sense of the problem much better than before. However, we don’t really know the exact problem in most cases.

从用户，IT开发人员以及支持人员和管理人员那里收集信息后，我们对问题的认识将比以前更好。 但是，在大多数情况下，我们并不真正知道确切的问题。

Is it due to poor software design or coding? Are the system resources too low? Has the transaction volume grown significantly causing the issue? Is business causing the issue by following scenarios and actions that should not be done? There will still be many such questions for which we still need to find out.

是由于不良的软件设计或编码？ 系统资源是否太低？ 交易量是否显着增加导致了问题？ 业务是否通过遵循不应该执行的方案和操作来引起问题？ 我们仍然需要找出许多这样的问题。

This happens because of multiple reasons. I have seen cases where no one had a complete picture. Each stakeholder looks at the issue from their vantage point, which may or may not be the right viewpoint. But we do get a sense of the problem to proceed further.

发生这种情况是由于多种原因。 我见过没有人完整了解情况的情况。 每个利益相关者都从有利的角度审视问题，这可能是正确的观点，也可能不是正确的观点。 但是，我们确实对问题有进一步的认识。

That’s where data analysis helps a great deal. Data can’t lie. If the order processing is slow, data shows — for specific orders, what time of the day, when, etc, you can drill down and find a great deal about when the problem started, what has changed, etc.

那就是数据分析有很大帮助的地方。 数据不能撒谎。 如果订单处理缓慢，则数据会显示-对于特定的订单，一天中的什么时间，什么时间等，您可以深入了解并查找有关问题何时开始，发生了什么变化等的大量信息。

I will illustrate this with an example.

我将通过一个例子来说明。

I worked in an environment where Oracle EBusiness Suite ERP and Oracle Mobile Field Service (MFS) applications were implemented for their business operations.

我在一个为其业务运营实施Oracle EBusiness Suite ERP和Oracle Mobile Field Service(MFS)应用程序的环境中工作。

Oracle EBS database would have all the required data of the enterprise. The field staff would get their service request information synched onto their laptop regularly to service their clients. This synchronization process would run between Oracle MFS and Oracle EBS in the background.

Oracle EBS数据库将具有企业所需的所有数据。 现场工作人员会定期将他们的服务请求信息同步到他们的笔记本电脑上，以服务他们的客户。 该同步过程将在后台在Oracle MFS和Oracle EBS之间运行。

This data needed to be real-time, with a maximum lag of say 5–10 mins, not more than that. The synchronization process needed to perform extremely well otherwise field staff wouldn’t get the necessary data to service the clients.

该数据需要是实时的，最大滞后时间为5-10分钟，不能超过此时间。 同步过程需要非常出色的执行，否则现场工作人员将无法获得必要的数据来为客户提供服务。

In this context, the system was performing badly. The field staff had raised several complaints that the synchronization process was slow. They were frustrated.

在这种情况下，系统运行不佳。 现场工作人员提出了几项抱怨，称同步过程很慢。 他们感到沮丧。

Most users reported this problem globally. Sometimes, they said, they had to wait several minutes, sometimes even hours. It had affected not only their work, even personal life too.

大多数用户在全球范围内报告了此问题。 他们说，有时他们不得不等待几分钟，有时甚至是几个小时。 它不仅影响了他们的工作，甚至影响了他们的个人生活。

Everyone had their own thoughts and ideas on what was the problem and possible fix. Even short term fixes like query tuning, increasing infrastructure resources like CPU, memory etc). Nothing had worked for long.

每个人对于什么是问题以及可能的解决方案都有自己的想法和想法。 即使是短期修复，例如查询调整，增加基础结构资源(如CPU，内存等)。 长期没有任何工作。

What was needed was to take a step back and understand what exactly was the problem and fix it forever. That's where the data analysis came into help.

所需要的是退后一步，确切地了解问题所在并永久解决。 这就是数据分析的帮助。

A model that was an outcome of data analysis. There was no data model to show the performance problem until that point. It was bit tricky to get to that point in an integration scenario, but a simple view as below helped all the stakeholders, which looked like the below.

这是数据分析的结果。 到目前为止，还没有数据模型可以显示性能问题。 在集成场景中达到这一点有点棘手，但是如下所示的简单视图帮助了所有利益相关者，如下所示。

As you can see in the above, the acceptable limit for business was less than 2 mins for data synchronization, and no longer than 10 mins even for a larger data set, but in reality, 73% of the data synchronization was taking longer than 10 mins. There was massive improvement needed.

正如您在上面看到的，对于数据同步，可接受的业务限制是少于2分钟，对于较大的数据集，该限制不超过10分钟，但实际上，73％的数据同步花费的时间超过10分钟分钟。 需要进行大量改进。

No one was aware of this data until that point. Everyone had their own perception. Business users thought the problem was much worse than this, whereas IT developers thought the situation was better than this, the problem was somewhere in between.

直到那时，没有人知道这一数据。 每个人都有自己的看法。 业务用户认为问题比这严重得多，而IT开发人员认为情况要好于此，问题介于两者之间。

While this may look like a simple outcome, in a practical scenario, it would be hard to come up with a simple view. Keeping things simple is not easy. It is just one example, but in a real scenario, required analysis could be much different.

尽管这看起来像是简单的结果，但在实际情况下，很难提出简单的观点。 保持简单并非易事。 这只是一个示例，但在实际情况下，所需的分析可能会大不相同。

As a next step, the target was clearly laid out — 90% data synchronization in less than 2mins, 6% between 2–5 mins, 4% 5–10 mins, in discussion with the stakeholders.

下一步，明确列出了目标-在与利益相关者的讨论中，在2分钟以内实现90％的数据同步，在2-5分钟之间实现6％的同步，在5-5分钟之间实现4％的同步。

It is amazing how such data analysis helps various stakeholders even in purely technical problem. I have seen this practically useful at IT developers level, business user community level and even at program board meetings.

令人惊讶的是，这样的数据分析如何甚至在纯粹的技术问题上也能帮助各种利益相关者。 我已经看到这在IT开发人员级别，业务用户社区级别甚至计划委员会会议上都非常有用。

Should we go ahead with the rollout to other global regions? How long this may take to fix? Will we be able to deliver services to customers within agreed SLAs? The data analysis and trends may answer a lot of questions.

我们是否应该继续向其他全球地区推广？ 解决这个问题可能需要多长时间？ 我们是否能够在商定的SLA中向客户提供服务？ 数据分析和趋势可能会回答很多问题。

Once this was established, the as-is, and the targets were shared and communicated in layman terms so that even a non-technical person could easily understand.

一旦建立起来，便以通俗易懂的方式按原样共享和交流目标，即使是非技术人员也可以轻松理解。

Once the problem is defined, half the battle is won.

一旦确定了问题，就可以赢得一半的胜利。

It is extremely important to clearly identify, state, and communicate the problem which brings in all the stakeholders on the same page and to avoid ambiguity. This generates positivity to work towards that target.

清楚地识别，陈述和传达使所有利益相关者都在同一页面上并避免歧义的问题，这一点非常重要。 这产生了朝着该目标努力的积极性。

There were a number of solutions that could be done in this context, which is outside scope of this article, but briefly, architects, developers, business analysts, and users were involved in taking this forward.

在这种情况下，可以实现许多解决方案，这不在本文的讨论范围之内，但是简要地说，架构师，开发人员，业务分析师和用户都参与了这一工作。

Identifying top 10 SQL queries consuming more time which were getting executed beyond 15 mins, tuning them by either rewriting them, optimizing execution through indexing, or altering execution plans and overall performance tuning.

确定前15分钟消耗的时间最多的前10条SQL查询，这些查询将通过重写，通过索引优化执行，更改执行计划和整体性能来进行优化。

Another approach was batching. Split the overall execution from serial processing to parallel processing, creating threads. Improve the execution time of each thread. Another solution was to reduce network delay because of data volume.

另一种方法是批处理。 将整体执行从串行处理拆分为并行处理，从而创建线程。 缩短每个线程的执行时间。 另一个解决方案是减少由于数据量引起的网络延迟。

A combination of these solutions helped to solve the problem and improve performance in this context. The above data analysis also helped to validate and verify the results to satisfaction after the optimization.

这些解决方案的组合有助于解决此问题并提高性能。 上述数据分析还有助于优化之后对结果进行验证和验证。

绩效分析的预测模型 (A predictive model for performance analysis)

I have come across various performance problems in a production environment. Sometimes a single SQL query performing badly had affected the entire system. This had happened because of an overnight gather statistics batch program run which had altered the execution plan of the query.

我在生产环境中遇到了各种性能问题。 有时，单个SQL查询的执行效果很差，影响了整个系统。 之所以发生这种情况，是因为通宵运行了一次收集统计信息批处理程序，从而改变了查询的执行计划。

In another instance, the order shipment process had severe lag affecting the employees on the floor at the warehouse. We face this often in spite of the measures in place.

在另一种情况下，订单发货过程严重滞后，影响了仓库地板上的员工。 尽管采取了适当的措施，我们仍然经常面对这一问题。

Performance specialists are quick to identify and put fixes in such cases by applying better execution plans, SQL profiles, etc.

性能专家可以通过应用更好的执行计划，SQL配置文件等快速识别并修复此类情况。

What I have found useful is to have dashboards for performance monitoring and preventing potential issues upfront, and regularly.

我发现有用的是定期设置仪表板，以进行性能监控和预防潜在问题。

This is tricky, but effort in this direction goes a long way in building best-performing applications. The system can have intelligence and predictive capability based on past data and trends to predict the performance issue.

这很棘手，但是在构建性能最佳的应用程序方面，朝着这个方向的努力大有帮助。 该系统可以具有基于过去的数据和趋势的智能和预测能力，以预测性能问题。

Let’s say, the system can predict the inflow data volume much higher than a regular day, we can build intelligence in to alert for potential performance issues downstream and possibly fix.

假设系统可以预测流入的数据量比正常情况要高得多，我们可以内置情报以警告下游可能存在的性能问题并可能进行修复。

Building a data analysis framework and dashboards is important so that we carry out the analysis at regular intervals to alert administrators, architects, and the business as needed. Simulate the data volume growth, having a strategy for archival and purging, options are so many.

建立数据分析框架和仪表板非常重要，因此我们可以定期执行分析，以根据需要提醒管理员，架构师和业务。 模拟数据量增长，有存档和清除策略，因此选择很多。

最后的想法 (Final Thoughts)

The whole exercise of performance improvement doesn’t follow a fixed pattern. An approach successful in addressing one kind of problem may not work for another, although it may look like a similar problem.

性能改善的整个过程并不遵循固定的模式。 成功解决一种问题的方法可能对另一种问题不起作用，尽管它看起来像是类似的问题。

As much as a system performance issue is a design and technology problem, the solution needs more human involvement and management of expectations and emotions. We need to work with actual people in a practical environment.

尽管系统性能问题是设计和技术问题，但解决方案需要更多的人员参与以及对期望和情感的管理。 我们需要在实际环境中与实际人员合作。

This exercise is partly software engineering, partly it requires broad skills which are a combination of art, communication, and humanity along with technology.

该练习部分是软件工程，部分则需要广泛的技能，这些技能需要结合艺术，沟通和人性以及技术。

Data analysis not only helps to identify the root of the problem, but it is also essential to bring in all stakeholders on the same page and manage expectations and deliver results. So, we must give this due time and focus when we approach performance improvement.

数据分析不仅有助于确定问题的根源，而且将所有利益相关者纳入同一页面并管理期望并交付结果也至关重要。 因此，在进行性能改进时，我们必须给这个适当的时间和重点。

If you found the above article useful, you may find the below useful too regarding how to approach solving complex problems.

如果您发现上述文章很有用，那么关于如何解决复杂问题，您可能会发现以下文章也很有用。