dynatrace KPI 번역

툴팁 번역

First Request : time in ms until the first request was actually sent by the browser
> browser로부터 첫 request가 보내진 시점

First Impression : time in ms until the first rendering activity
> 첫 rendering (drawing) 활동이 끝난 시점, 처음 뭔가 그려진 시점

onLoad Time : time elapsed until the body of the page was loaded (time between the page was requested and the body onload event was triggerd)
> onload event가 발생한 시점,

Fully Loaded : time in ms until page was fully loaded
> 요청한 모든 자원이 로딩 완료된 시점

On Server : time spent on server for dynamic content generation until page was fully loaded
> fully loaded 시점 이전에 application 서버가 dynamic content를 생성하는데 걸린 시간, ?? FR to TTFB 인지 확인 필요

On Client : time spent in javascript until page was fully loaded
> fully loaded 시점 이전에 javascript 수행에 소요된 시간

Interactive : time spent in javascript on mouse and keyboard event handlers after page was fully loaded
> fully loaded 시점 이후에 마우스, 키보드 이벤트 핸들러로 부터 수행된 javascript 소요시간, 마우스 키보드 이벤트 처리에 소요된JS 수행시간

DNS : time elapsed during address resolution
> DNS lookup time, ?절대합

Connect : time elapsed until the network connection was established
> connection 맺는데 걸린 시간, establish the TCP/IP connection to the web server, ?절대합

Transfer : time elapsed transferring resources over the network
> 리소스 전송 시간, from TTFB to TTLB, ?절대합

Wait : average time a request has to wait to obtain a physical network connection in order to be downloaded
> 물리적 network connection 이루어 지기 까지 대기한 시간, domain 당 동시 connection 수 초과시 나머지 요청은 연결대기, ?절대합

Network : absolute time elapsed transfering resources over the network (note that several resources may have been transferred in parallel)
> Wait, DNS, Connect, Transfer 시간, ?병렬처리시간

JavaScript : time spent executing javascript code
> javascript 수행에 소요된 시간

Rendering : time spent on rendering browser content
> browser가 rendering하는데 소요한 시간

Total Size : total download size of this page
> page size

# of Requests : total number of network requests
> 요청 수

# of XHR : total number of XMLHttpRequests (AJAX Requests)
> AJAX 요청수






KPI 설명 페이지 번역
https://community.dynatrace.com/community/display/PUB/Best+Practices+on+Web+Site+Performance+Optimization?accessed=true&source=dae20

KPI’s on Load Time

There are 3 interesting phases of a web site from an end-user performance perspective. The dynaTrace AJAX Edition visualizes the page lifecycle in the TimeLine View where we can highlight First Impression, onLoad and Fully Loaded Time:

Time to First Impression

This is the time from when the URL is entered into the browser until the user has the first visual indication of the page that gets loaded. The first visual indication is the first drawing activity by the browser and can be traced with dynaTrace AJAX Edition. It depends on the initial HTML document when the browser can start drawing content. There are different Best Practices available that talk about different strategies. Google for example downloads a minimalistic page to provide fast first visual rendering. It then delay loads more content after onLoad or even later when the user starts interacting with the page.

Time to onLoad Event

This is the time until the browser triggers the onLoad event which happens when the initial document and all referenced objects are fully downloaded. JavaScript onLoad handlers use this event to manipulate the current initial state of the page. This event is one of the options explained earlier to download additional or delay load content.

Time to Fully Loaded

This is the time until all onLoad JavaScript handlers have finished their execution and all dynamically or delay loaded content triggered by those handlers has been retrieved. It is sometimes a bit hard to identify the exact time when the page is fully loaded especially when JavaScript handlers use reoccurring timeouts that constantly modify the page, e.g.: to implement a ticker.

KPI’s on Resources

A web page is composed out of the initial HTML document, embedded resources such as images, css, javascript and dynamically downloaded content via XHR or by modifying the DOM through javascript. The more resources there are on the page the more network roundtrips between the browser and the server to download the content. The larger these resources the more bandwidth is required to transfer the content. Please have a detailed look into the Best Practices on Network document that describes in more details on why reducing roundtrips and payload size is important. The dynaTrace AJAX Edition provides the Network View to analyze each individual network resource that has been downloaded:

Total Number of Requests

This is the total number of network requests that get downloaded with the website. The ultimate goal is to keep this number as low as possible in order to reduce roundtrips. Monitoring this KPI gives you early indications on newly introduced content that can negatively impact page performance.

Total Number of HTTP 300s/400s/500s

This is the total number of requests to the server that responded with an HTTP Status Code of 300 (Redirect), 400 (Authorization Problem) or 500 (Server Error). These are requests that should be avoided as they have a negative impact on the page load time. The root cause of these problems is often server-side related implementation, configuration or deployment issues.

Total Size of Web Site

This is the total size of all resources that make up your page. It is important to keep track of the total payload size. The larger web sites become the longer it takes to download. Changes to the page – such as adding images or new javascript libraries – can have a significant impact on download time.

Total Size of Images/CSS/JS

Besides keeping track of the total page size it is important to look into the sizes of the individual content types such as Images, Style Sheets and JavaScript files. With this it is easier to spot the main contributors of page size.

Total Number of XHR Requests

The total number of XmlHttpRequests (XHR) sent via JavaScript to retrieve data asynchronously from the server. Monitor this KPI to identify sudden changes in dynamic content retrieval via XHR. Some JavaScript frameworks provide update mechanisms with the server-side and use XHR for these purposes. Depending on the configuration you can end up with too many XHR requests that not only impact client side performance but also cause additional load on the application server.

KPI’s on Network Connections

The browsers underlying network connection has a major impact on the download speed of web site content. There are different phases when downloading content that impact the overall download time. The dynaTrace AJAX Edition shows all phases for every network request.

A request that gets handled by the browser runs through different stages. The following list explains these phases, what the measures tell us and how they get impacted by the browser, the network and other requests.

DNS Time

One DNS Lookup happens for every domain that hosts resources for the current web site. If you move between multiple pages the browser does not require another DNS lookup for a domain that has been resolved on the previous page. It is interesting to look at the total DNS time to identify problems with DNS Lookup Times that can be caused by DNS configuration problems.

Connect Time

Depending on the browser and the number of resources that are served by a domain the browser establishes one or multiple connections to each domain that hosts resources for the page. Connect Time is the time it takes to establish the TCP/IP connection to the web server. Connections usually stay open unless the Web Server directs the browser to close the connection (Connection HTTP Header). When using secure communication via SSL, the Connect Time also includes the time of the SSL handshake. High Connect Time can therefore have the following reasons: slow network connection to the web server, usage of SSL and not allowing the browser to keep the connection open.

Server Time

High Server Time means that the Web/Application Server required a long time to process the request. This is particularly relevant with requests that trigger application logic to be executed on the application server where higher Server Times can be expected – especially under heavy load periods. Monitoring Server Time is important to identify bottle necks, performance and scalability problems with the application server. It is usually easier to scale static content delivery by adding more web servers with load-balancers or by using a Content Delivery Network. It is not that easy to scale a dynamic application in the same way. Keeping an eye on this metric is important.

Transfer Time

This time directly correlates with the size and the connection speed between browser and server. Keeping transfer time low is important to ensure faster load times. Transfer Time can be improved by lowering the Total Page Size and by bringing content closer to the end user by using Content Delivery Networks (CDNs)
> 이 시간은 브라우저와 서버사이의 연결과 데이터 크기와 직접적인 연관이 있다. transfer time을 작게 유지하는 것은 빠른 로딩타임을 위해 중요하다. Transfer Time은 CDN으로 conent를 사용자 가까이 가져다 놓거나 page size를 줄임으로써 향상 시킬 수 있다.

Wait Time

Wait Time is directly correlated with the number of resources that are served by the same domain. The physical network limitation of a browser per domain causes resources to wait for a free connection. Reducing the number of resources or spreading the resources over different domains will bring this time down. Instead of looking at the total Wait Time the average Wait Time tells a better story whether Wait Time is of a concern.

Number of Domains / Single Resource Domains

The number of domains that host the web sites resources is important as it affects DNS, Connect and Wait Time. Additional domains that are utilized to download resources will have a direct reduction in the wait time because the browser ultimately uses more physical connections. This can have an opposite affect when more DNS lookups are needed and more time is spent to establish the physical connections. Single Resource Domains should be avoided as you pay a high price for performing the DNS and Connect to download a single resource. It is sometimes not avoidable when downloading content from external content providers (such as ad-services). When having the deployment under your own control you want to make sure to not have single resource domains.