數據分析 績效
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.
數據分析不僅有助于確定問題的根源,而且將所有利益相關者納入同一頁面并管理期望并交付結果也至關重要。 因此,在進行性能改進時,我們必須給這個適當的時間和重點。
翻譯自: https://towardsdatascience.com/how-to-use-data-analysis-in-performance-improvement-119cfad6414
數據分析 績效
本文來自互聯網用戶投稿,該文觀點僅代表作者本人,不代表本站立場。本站僅提供信息存儲空間服務,不擁有所有權,不承擔相關法律責任。 如若轉載,請注明出處:http://www.pswp.cn/news/389150.shtml 繁體地址,請注明出處:http://hk.pswp.cn/news/389150.shtml 英文地址,請注明出處:http://en.pswp.cn/news/389150.shtml
如若內容造成侵權/違法違規/事實不符,請聯系多彩編程網進行投訴反饋email:809451989@qq.com,一經查實,立即刪除!