Analysis reports for front-end and cloud performance analysis tools

The main function of the performance testing tool is to simulate the real business operation in the production environment, carry on the pressure load test to the tested system, monitor the performance of the tested system under different service and pressure performance, and find out the potential performance bottleneck to analyze and optimize.
The client and the server are equivalent to two people, communicating through the information. Because the first meeting embarrassed to communicate directly, and is to find the middle Messenger, the client to tell the message to the Messenger, by the Messenger to convey to the server. Then the server feedback information is also conveyed to the client by the messenger. General performance testing tools require recording or writing client-side behavior scripts.
This conveys the client's ability to act as a client to spoof the server and communicate with it. With the client behavior, the sender can replicate itself. Thus, more than n transmitters are sent to the server to communicate. -This conveys human behavior and ability is the basic trait of performance testing tools. (Suddenly feel that performance tools like a third party, but also can be self-replicating crazy abnormal third party, haha!) ）
For the current popular performance testing tools, their basic principle of work is consistent. The client simulates virtual user access through multi-threaded or multi-process, exerting pressure on the server side and then monitoring and collecting performance data during the process.

Characteristics that a performance test tool should have:
1, the tool itself occupies less system resources, good scalability, strong usability.
2, can simulate real business transaction operations, in the concurrency can really generate business pressure. (This point is the core)
3, the pressure test results can be a good performance analysis, quickly find the bottleneck of the system being tested.
4, the test script is strong repeatability.

Front and back side comparison:
Web applications are based on Hypertext Transfer Protocol (HTTP) and hyper-text Markup Language (HTML), the HTTP protocol itself is a non-connected protocol, the HTML language is a simple markup language for the production of hypertext document data.
For a page, both request and return data can occur more than once. This article cited a simple example of what I need to know before doing a performance test. Because of HTTP to the browser download resources, such as the number of concurrent requests, cache and other aspects are defined and limited, as well as the browser for the HTML processing process. It is entirely possible to say that a significant portion of the response time that the user feels is not entirely dependent on the time required for the app's background processing, but on the front end of the web App. In Yahoo, fewer than 50 teams have reduced end-user response time by more than 25% by using purely front-end performance-related techniques.
HTTP is an object-oriented protocol belonging to the application layer, which transmits data in WWW mode, uses the request \ Response model, the client sends a request to the server, the request header contains the requested method, the URI, the protocol version, and an HTML-like message structure that contains the request modifier, the customer information, and the content. The server responds with a status line that includes the version of the message protocol, success or error encoding plus the server information, entity meta information, and possible entity content.
HTML is a simple markup language for making hypertext documents, and hypertext documents written in HTML can be independent of various operating system platforms. Since the birth, the HTML language has been used to describe the Web page format design, the use of HTML-language files described by the WWW browser to display the effect.

Here are two ways to compare the difference between two test response times
Apache benchmark abbreviation AB, is a very famous and small pressure testing tools.
Download install Apache Web server after installation or decompression, there is an AB executable file under the bin\ directory.
Open the Run –cmd Open command prompt and navigate to the bin\ directory.
Basic usage:
ab-c [Number of concurrent users]-n [send requests] [URL of the page being tested]
Set a user a request for Baidu home pressure:
http://www.baidu.com/

From the table above we can see that the total number of bytes requested is 8024 bytes, and the response time is 0.173 seconds, which is the 173.010 milliseconds shown below.

Firebug is a very famous debug tool, the most proud of the integration tools of Firefox browser.
Browse the menu bar "Tools" in Firefox-Add components-search Firebug to download and install the restart browser.
also access to Baidu home page:
http://www.baidu.com/

The size of the request is 10KB from the figure above, and the response time is 1.4 seconds. Clearly found that the data can be far greater than the data obtained by the AB tool. Looking closely at the data that Firebug gives, when you visit the http://www.baidu.com/URL, the data interaction between the client (browser) and the app is not 1 times, but 5 times.
We'll analyze one of these requests, and in the graph given by Firefox, there are lines in both red and blue colors. Blue indicates that the domcontentloaded event has occurred at this moment. A red line indicates that the onload event is triggered. The standard event recommended by the Domcontentloaded event, which occurs when the DOM tree of a page is built, and onload occurs when all the resources on the page (image files, CSS files, JS files, etc.) are downloaded.
from the lower right corner, we get two response times, 1.41 seconds is the time the onload event is triggered, and the preceding 1.4 seconds is the total time required for all requests from the page to be returned. So which time is the response time that the user feels? Exactly, two are not. The user's feelings are an indeterminate state, depending on the type of the page itself and the means of presentation. If a page only provides reading information to the user, the user begins to read as soon as the page begins to appear for reading. Then, the user thinks that the response time is to make the request appear on the page to read the information. If the page has a large number of interactive content, users need to fill out or drag and drop on the page, in this case, only if all the elements of the page are rendered correctly, all the JS files have been completed, the user will feel that the page is ready.
The study of Web front-end performance is not to accurately get a response time data, in fact, depending on the results of the Friebug chart, the Web performance is partly dependent on the Web server and application server (establishing a connection, downloading the connection), and partly depending on the browser implementation mechanism, The execution of JS on the Web page. Depending on the response time of the Web server and application server is related to the load, pressure of the server, and depending on the browser implementation mechanism and the time required to execute the JS file is almost independent of the server-side load and pressure. The web-side response time is also part of the total response time, so it is necessary to understand the performance of the Web side.
So the front-end performance is so effective, why do you want to do back-end performance testing? Because their focus is different, front-end performance focuses on the individual user's feelings. Backend performance concern is that when more users access the system, the server can handle requests from users more stably and faster. A powerful backstage is the foundation of the foreground.

前端:

Performance testing has been a very interesting part of WEB applications. Most of the current focus on performance is mainly on the service side, most people when speaking of "performance testing", will focus on the service side of performance testing and tuning, that is, through a variety of methods to find the performance bottleneck of the service side and try to tune it. In fact, for Web applications, performance testing and performance tuning can be considered from the perspective of the page, in addition to considering that the server is returning the page data in short enough time.

Online website class:
Webpagetest
Description
Online Site performance evaluation website, address http://www.webpagetest.org/
Add:
In fact, this site is also an open source project, so support themselves to build an internal testing site

Standalone Program classes:
DynaTrace Ajax Edition
Description
Ie,firefox-based plug-ins that require version support for FF require a standalone installation file (more than 50 m). It supports measurement analysis at the function level, in addition to the functionality supported by other tools.

This tool can track JavaScript from the beginning of execution, through local xmlhttprequest, sending network requests, to the entire process of requesting a return.

What is DynaTrace Ajax
With the advent of the framework of JQuery, Dojo, YUI and so on, it is easier to build Web2.0 applications, but it is becoming more and more difficult to apply the positioning and other application problems, especially related to performance. DynaTrace Ajax Edition is a powerful underlying tracking, front-end profiling tool that not only records the browser's request on the network, the rendering time of the front-end page, the DOM method execution time, and the parsing and execution time of the JavaScript code. You can also track the whole process of JavaScript starting from execution, passing local XMLHttpRequest, sending network requests, and returning requests.
DynaTrace Ajax currently has two versions, the free version and the commercial edition, the differences between them can be seen in version comparison, this article is mainly for the free version of the introduction. Versions prior to 3.0 are only supported under IE, including IE6, IE7, IE8, and can support performance tracking on both IE and Firefox browsers after the 3.0 beta release.
Application Case Analysis
The result of the following record is a case in the actual project (IBM Docs) We are currently developing-open a PPT document in the WEB and analyze the performance issues based on the information collected by DynaTrace.
Performance report (Performance Reports view)
From the cockpit panel, open the performance report view:
Figure. Performance reports

The details of all the pages visited are recorded in the performance report view, from which we can get the following information:
Time taken to load the page: OnLoad time[ms] Displays the time it takes to load from the page to the browser to distribute the OnLoad event; Total load Time[ms] shows how long it took to load all the pages
JavaScript execution time: on Client[ms] Total time spent by all JavaScript functions executed by the JS API or library
How long the network request took: from Remark, you can see how many requests are in total, and how many of them XHR requests.
Server-side consumption time: on Server[ms] refers to the total amount of time that all requests made by the client begin responding when the server has been over for a long time
The overall performance analysis report can be obtained from the various panels in the lower right (more detailed information can be seen in the corresponding node in the cockpit panel), for example:
The network shows how many of the resources are read from the browser cache, how many HTTP forwarding requests consume unnecessary network transmission time, and how much time is saved by merging CSS and JS requests in the same domain.
The life cycle of the page is shown in TimeLine: The graph reflects the download of network resources in the page process, JavaScript execution, page rendering, CPU usage, and what happened, such as the Load event, XMLHttpRequest, and so on.
In my case, the following is what I noticed:
The network takes a long time and the number of requests is too large: a total of 896 network requests, of which 300+ request is requested for a picture, 300+ reads the same image from the cache.
JavaScript execution time takes 22 seconds: from the Javascript/ajax (a) report in the lower right, you can see that an OnLoad event consumes a total of 13 seconds, and double-click to see its front and back call stack information from the right window.
Server-side processing took a total of 20 seconds: This indicates that there may be performance issues on the server side, and it is recommended that you use the Performance Inspector tool to analyze server-side performance issues, which are no longer detailed.
The Remark Bar also shows a total of 23 XMLHttpRequest requests made by the page: This can be used to find the point in time from the event line in the timeline. The next section will discuss these issues in more detail.
Timeline (Timeline view)-Page life cycle
The timeline view can be opened by double-clicking the TimeLine node in the cockpit panel or by right-clicking on a URL in performance report and selecting Drilldown-timeline. Depending on the performance report view, you can open the TimeLine of a long-running URL by using the toolbar or the right-click menu to open more options, such as the color values of content types and JavaScript triggers, or to show more events such as mouse movements, clicks, and keyboard events. Open the timeline view of this case, as shown in:
Fig. Time axis

In this view, we can observe:
CPU usage shows the time that JavaScript execution causes the browser to consume CPU
Time spent in JavaScript execution: the segment from which the right blue block is viewed takes longer, and the mouse hovers over this section to see that it takes nearly 13 seconds to trigger the Load event on
Browser Rendering, hover can be found mostly due to the time required to calculate the layout, generally on IE above the relative will be more obvious
Network requests parallel download time, on the one hand from the number of requests too much, one of the more obvious is that there is a xmlhttprequest spent nearly 7 seconds of processing the Server
The event axis shows the mouse click event, the XMLHttpRequest event, and the OnLoad event
Enlarge the portion of the right network request for a long time (in my case, from 16s to 29s time slices), by clicking the left mouse button at the beginning and dragging to the end position to release the mouse drag and drop, the view zooms in to the time slice shown below, as shown in:
Figure. Zoom In time axis

By right-clicking on the magnified time slice, select "Drill down to timeframe E" into the PurePath view, showing all the activities on the currently magnified time slice.
DynaTrace Ajax is a very useful and important tool for front-end software development engineers and performance analysts. With the continuous updating of this tool, the power of functionality, the increasing number of supported browsers, and the combination of continuous integration tools make it easier, earlier and more frequent to discover the performance issues of applications on different browsers.

Back end:
No matter what the evaluation tool, the basic technology is the use of threading technology imitation and virtual users, here the main difficulty lies in the test script writing, each tool uses different scripts, but most tools provide recording function even if it is not coded testers can also test.
As we all know, the server is the core of the whole network system and computing platform, many important data are kept on the server, many network services are running on the server, so the performance of the server determines the performance of the whole application system.
Now on the market different brands, different types of servers There are many kinds of users in the purchase, how to choose from a variety of models required, suitable for their own application of the server products, only from the configuration of the identification is not enough, it is best to pass the actual test to screen. and a variety of evaluation software There are many kinds, you should choose which software test? Here are some of the more typical test tools:
(a) Server machine system performance testing tools
The performance of a server system can be divided by processor, memory, storage, network parts, and for different applications, some parts of the performance requirements may be higher.
(ii) application-specific testing tools

With the proliferation of Web applications, web-centric applications in server application solutions are growing, and many companies are using web-based architectures for a variety of applications. The general Web test is not exactly the same as the testing of the previous application, and after the basic functionality has passed the test, the important system performance test is performed. System performance is a very large concept, coverage is very broad, for a software system including execution efficiency, resource occupancy, stability, security, compatibility, reliability, and so on, the following focus on the load pressure aspects of the server system performance testing. Load and pressure of the system need to use load test tools, virtual a certain number of users to test the performance of the system, to see whether the expected design indicators to meet the requirements. The goal of the load test is to test how the corresponding output items of the system components, such as throughput, response time, CPU load, memory usage, and so on, determine the performance of the system, such as stability and responsiveness, when the load is gradually increasing. Load test generally use tools to complete, there are loadrunner,webload,qaload, etc., the main content is to write a test script, the script generally includes the user commonly used functions, and then run, to produce reports. Stress test the Web server using the Stress test tool. Testing can help you find some big problems, such as freezing, collapsing, memory leaks, and so on, because some programs with memory leak problems may not have problems running one or two times, but if you run thousands of times and memory leaks more and more, you can cause the system to slide.

AB is the performance Test tool for Apache Hypertext Transfer Protocol (HTTP). Its design intent is to depict the execution performance of the currently installed Apache, primarily to show how many requests per second Apache you have installed.

AB [-A Auth-username:password] [-c concurrency] [-c Cookie-name=value] [-d] [-e Csv-file] [-G gnuplot-file] [ -h] [-H custom-header] [-i] [-K] [-N requests] [-P post-file] [-P proxy-auth-username:password] [-Q] [-S] [-S] [-T TimeLimit] [-T Content-type] [-V verbosity] [-V] [-W] [-X

-attributes] [-X proxy[:p ort]] [-y-attributes] [-Z

-attributes] [http://]hostname[:p Ort]/path

Options

-A Auth-username:password
Provides a basic authentication trust to the server. The user name and password are separated by a: and sent in Base64 encoded form. This string is sent regardless of whether the server is required (that is, if the 401 authentication requirement code is sent).
-C concurrency
The number of requests produced at one time. The default is one at a time.
-C Cookie-name=value
Attach a cookie to the request: line. Its typical form is a parameter pair of Name=value. This parameter can be repeated.
-D
The message "percentage served within XX [MS] table" is not displayed (supported for previous versions).
-E Csv-file
Produces a comma-delimited (CSV) file that contains the corresponding percentage (in subtle units) of time that is required to process requests for each corresponding percentage (from 1% to 100%). This format is more useful than the ' gnuplot ' format because it is "binary".
-G Gnuplot-file
Writes all test results to a ' gnuplot ' or a TSV (tab-delimited) file. This file can be easily imported into gnuplot, IDL, Mathematica, Igor or even Excel. One of the first behavior headings.
-H
Displays the usage method.
-H Custom-header
Additional header information is attached to the request. A typical form of this parameter is a valid header information row that contains a pair of fields and values separated by colons (for example, "Accept-encoding:zip/zop;8bit").
-I.
Executes the head request instead of get.
-K
Enable the HTTP KeepAlive feature, which is to execute multiple requests in an HTTP session. By default, the KeepAlive feature is not enabled.
-N Requests
The number of requests executed in the test session. By default, only one request is executed, but usually its result does not represent meaning.
-P Post-file
A file that contains the data that needs to be post.
-P Proxy-auth-username:password
Provides a basic authentication trust for a transit agent. The user name and password are separated by a: and sent in Base64 encoded form. This string is sent regardless of whether the server is required (that is, if the 401 authentication requirement code is sent).
-Q
If the number of requests processed is greater than 10%, AB outputs a progress count in stderr each time the request is processed by approximately one or 100 requests. This-Q flag can suppress this information.
-S
Used to compile (Ab-h will display relevant information) using SSL for protected HTTPS instead of HTTP protocol. This feature is experimental and very rudimentary. It's better not to use.
-S
Median and standard divergence values are not displayed, and warning or error messages are not displayed when the mean and median values are 1 to twice times the standard deviation value. By default, values such as min/mean/maximum values are displayed. (Support for previous versions).
-T TimeLimit
The maximum number of seconds the test takes. Its internal implied value is-n 50000. It allows you to limit the testing of the server to a fixed total time. By default, there is no time limit.
-T Content-type
The Content-type header information used by the post data.
-V verbosity
Setting the level of detail to display information-4 or greater displays header information, 3 or greater values can display response codes (404, 200, etc.), and 2 or greater values can display warnings and other information.
-V
Displays the version number and exits.
-W
Outputs the result in the format of an HTML table. By default, it is a table with a two-column width on a white background.
-X

-attributes
Set up The string for the property. This property is filled in

Tar zxvf http_load-12mar2006.tar.gzcd http_load-12mar2006make && make install

Command format: http_load-p number of concurrent access processes-S access time URL file to access
Parameters can be freely combined, and there is no limit to the choice between parameters. Like you wrote Http_load-parallel 5-seconds.
The urls.txt is also possible. Let's give you a brief explanation of the parameters.
-parallel Shorthand-P: means the number of concurrent user processes.
-fetches abbreviated-F: Meaning total number of accesses
-rate Shorthand-P: meaning the frequency of visits per second
-seconds shorthand-S: meaning Total access time
Prepare URL file: Urllist.txt, file format is one url,url per line preferably more than 50-100 test results better. file format
As follows:
Http://www.vpser.net/uncategorized/choose-vps.html
Http://www.vpser.net/vps-cp/hypervm-tutorial.html
Http://www.vpser.net/coupons/diavps-april-coupons.html
Http://www.vpser.net/security/vps-backup-web-mysql.html
For example:
Http_load-p 30-s Urllist.txt
Parameter understanding, let's look at running a command to see its return result
Command:%./http_load-rate 5-seconds The URLs description performed a test that lasted for 10 seconds, with a frequency of 5 per second.
Fetches, 2 max parallel, 289884 bytes, in 10.0148 seconds5916 mean bytes/connection4.89274
Fetches/sec, 28945.5 bytes/secmsecs/connect:28.8932 mean, 44.243 Max, 24.488 Minmsecs/first
-response:63.5362 mean, 81.624 Max, 57.803 minhttp response Codes:code 200–49
Results Analysis:
1. Fetches, 2 max parallel, 289884 bytes, in 10.0148 seconds
Description in the above test run 49 requests, the maximum number of concurrent processes is 2, the total transfer of data is 289884bytes, the run time is 10.0148 seconds
2. 5916 mean bytes/connection shows the average amount of data transmitted per connection 289884/49=5916
3. 4.89274 fetches/sec, 28945.5 bytes/sec
Indicates that the response request per second is 4.89274, and the data passed per second is 28945.5 bytes/sec
4. msecs/connect:28.8932 mean, 44.243 max, 24.488 min indicates that the average response time per connection is 28.8932 msecs
, maximum response time 44.243 msecs, minimum response time 24.488 msecs
5. msecs/first-response:63.5362 mean, 81.624 max, 57.803 min
6, HTTP response codes:code 200–49 Description Open the type of response page, if the type of 403 too many, it may
Be aware that the system is experiencing bottlenecks.
Special Instructions:
The main indicators in the test results are fetches/sec, Msecs/connect, which is the number of queries that the server can respond to per second.
Use this indicator to measure performance. Seems to be a bit higher than Apache's AB accuracy and more persuasive.
Qpt-responds to user times per second and response time per connection.
The result of the test is mainly to look at these two values. Of course only these two indicators do not complete the performance analysis, we also need to the server
CPU, men to analyze, to draw conclusions

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

Analysis reports for front-end and cloud performance analysis tools