I. Basic Introduction
In LoadRunner usage, browser emulation settings under run-time settings are confusing. Next we will take a look at the purpose of each option and the impact on the test using sniffer.
Browser emulation Diagram
The meaning of each option is as follows:
Check for newer versions of stored pages every visit to the page Option
This setting instructs the browser to check the newer version of the specified URL (compared with the URL stored in the cache. When this option is enabled, vugen adds the "if-modified-since" attribute to the HTTP header. This option will open the latest version of the page, but will generate more traffic during scenario or session execution. By default, the browser does not check newer resources, so this option is disabled. Configure this option to match the settings in the browser to be simulated.
Download non-HTML resources options
This option indicates that the vuser loads a graphic image when accessing the webpage during playback. This includes the images recorded together with the page, and the images not explicitly recorded together with the page. When users access a webpage, they need to wait for the image to be loaded. Therefore, if you try to test the entire system (including end user time), enable this option (enabled by default ). To improve performance without simulating actual users, disable this option.
Note: if there is a difference in image check, disable this option because some images change (for example, ad banners) each time you access a webpage ).
Simulate a new user on each iteration Option
Indicates that vugen resets all HTTP contexts between iterations to the corresponding status when the init part ends. With this setting, vusers can more accurately simulate new users who start browsing sessions. It will delete all cookies, close all TCP connections (including keep-alive connections), clear the cache of the simulated browser, and reset the HTML frame hierarchy (the frame number starts from 1) and clear the user name and password. This option is enabled by default.
Clear cache on each iteration Option
Clear the browser cache during each iteration to simulate the user accessing the web page for the first time. Clear this check box to disable this option and allow vusers to use the information stored in the browser cache to simulate users who have recently visited the web page.
Let's talk about my thoughts:
Performance testing is a comprehensive technology that requires testers not only to understand the application of performance testing tools, you also need to know about the operating system, database, and application software. We can also see the setting of different parameters for LR, which leads to different test data. LR settings correspond to some relevant settings of IE. This shows that we should not only be familiar with LR, but also have a deep understanding of the correspondence between LR and IE. I believe that if we understand and apply these settings, we will surely surprise you in many situations, such as on-site users and shortlisted products!
We can see that different options have different loads for server problems. loads are mainly generated when the number of connections and the size of downloaded packets are different. We have clearly understood the potential impact of different choices on the server, so how can we apply it to the actual performance testing scenario? I am often confused about this! From my perspective, there are usually several combinations of policies to deal:
First, the easiest policy is to download all resources and generate the maximum number of connections possible to interact with the server.
(I tried, but we always have this concept in mind: if the system can withstand the maximum load, there will be a cache mechanism in the real process, so this performance will certainly pass the sentence to the truth. If you do more, your conscience will be uneasy! Haha! Once the developer knows it, he will give us a comment!
Second: simulation. The actual performance test itself is in the simulation process. The more accurate the simulation process is, the more accurate our performance test results will be. There are three types of simulation processes in performance testing, and I put them in the simulation of operation behavior. Let's look back at the several setting options of LoadRunner. I divided these options into two types of simulation settings: simulation of IE behavior and Simulation of program behavior.
Simulation of IE behavior (corresponding to the ABCD introduced in Tacy ):Ie can set different policies for cache resources or data. So we will return to the actual user operation. What policies will the user set for IE? Smart users will certainly use the browser cache to speed up the operation. However, in our actual survey, we feel that most users will basically use the browser settings, no changes. Unless the development program automatically limits or reminds you of this. Therefore, I usually set this option using the default settings of the browser or the requirements of the program operation manual! However, we will also consider the proportions of new users and old users for different setting policies.
Simulation of program behavior:Some programs set to clear the cache in JavaScript and require that the connection be established again for each operation. We will use this policy to simulate it, therefore, the simulation of this behavior is usually set based on the program settings.
In this setting, I feel that LR has a bad place. If I set the operations for new users (and users whose files are retained and expired) and set these options for old users, I have to put the same script in two controllers, and set different run time setting options to simulate the reality. webload seems to be better than it!
Ii. Cases and tools
1. Test Case:
Open the homepage twice and compare the LoadRunner behavior in different browser emulation settings. The script is as follows.
Action(){ web_url("www.primeton.com", "URL=http://www.primeton.com/", "Resource=0", "RecContentType=text/html", "Referer=", "Snapshot=t2.inf", "Mode=HTML", LAST); web_url("www.primeton.com", "URL=http://www.primeton.com/", "Resource=0", "RecContentType=text/html", "Referer=", "Snapshot=t2.inf", "Mode=HTML", LAST); return 0;}
2. sniffer Tool
Open-source tool: Wireshark (formerly Ethereal) (www.wireshark.org)
Iii. Test process
To facilitate the description, we agree to use:
A stands for Simulate browser cache
B Indicates cache URLs requiring content (htmls)
C stands for check for newer versions of stored pages every visit to the page
D stands for download non-HTML Resources
E-generation table simulate a new user on each iteratioin
F indicates clear cache on each iteration
First, set iteration in run logic to 2. Let action run twice to check the changes in data packets and connections when the script runs cyclically twice.
1. Remove all options
Results: A total of 95 data packets were obtained, 1 was established (marked in red), and 1 was disconnected (marked in blue)
No. Time source Destination Protocol info
1 0.000000 192.168.1.61 203.81.29.20.tcp 13835> HTTP [SYN] seq = 0 Len = 0 mss = 1460 Ws = 2
2 0.036053 203.81.29.20.192.168.1.61 tcp http> 13835 [SYN, ack] seq = 0 ACK = 1 win = 17280 Len = 0 mss = 1440 Ws = 0
92 1.415887 192.168.1.61 203.81.29.20.tcp 13835> HTTP [Fin, ack] seq = 817 ACK = 71762 win = 257760 Len = 0
94 1.449960 203.81.29.20.192.168.1.61 tcp http> 13835 [Fin, ack] seq = 71762 ACK = 818 win = 16464 Len = 0
In this case, there are very few data packets (no choice to download the resource file into CSS, JS, GIF, etc.), and you can see that only one TCP connection is established when you open the home page four times.
At this time, even if you select a, you will find that the number of data packets page does not change, because the cache is mainly for resource files
2. Select E (f)
Result: a total of 102 data packets are obtained, two connections are established (marked in red), and two are disconnected (marked in blue)
No. Time source Destination Protocol info
1 0.000000 192.168.1.61 203.81.29.20.tcp 13886> HTTP [SYN] seq = 0 Len = 0 mss = 1460 Ws = 2
2 0.037013 203.81.29.20.192.168.1.61 tcp http> 13886 [SYN, ack] seq = 0 ACK = 1 win = 17280 Len = 0 mss = 1440 Ws = 0
48 0.618117 192.168.1.61 203.81.29.20.tcp 13886> HTTP [Fin, ack] seq = 409 ACK = 35882 win = 257760 Len = 0
49 0.644106 192.168.1.61 203.81.29.20.tcp 13887> HTTP [SYN] seq = 0 Len = 0 mss = 1460 Ws = 2
51 0.651919 203.81.29.20.192.168.1.61 tcp http> 13886 [Fin, ack] seq = 35882 ACK = 410 win = 16872 Len = 0
53 0.676377 203.81.29.20.192.168.1.61 tcp http> 13887 [SYN, ack] seq = 0 ACK = 1 win = 17280 Len = 0 mss = 1440 Ws = 0
99 1.310379 192.168.1.61 203.81.29.20.tcp 13887> HTTP [Fin, ack] seq = 409 ACK = 35882 win = 257760 Len = 0
101 1.347949 203.81.29.20.192.168.1.61 tcp http> 13887 [Fin, ack] seq = 35882 ACK = 410 win = 16872 Len = 0
In this case, there are very few data packets (no choice to download the resource file into CSS, JS, GIF, etc.). Compared with the first case, you will find that it has established two connections, this is the role of E. For every iteration, it is regarded as a new user, and a new connection needs to be established.
3. Select de (f)
Result: A total of 1782 data packets are obtained, 6 connections are established (marked in red), and 6 are disconnected (marked in blue)
No. Time source Destination Protocol info
1 0.000000 192.168.1.61 203.81.29.20.tcp 14016> HTTP [SYN] seq = 0 Len = 0 mss = 1460 Ws = 2
2 0.037911 203.81.29.20.192.168.1.61 tcp http> 14016 [SYN, ack] seq = 0 ACK = 1 win = 17280 Len = 0 mss = 1440 Ws = 0
6 0.107432 192.168.1.61 203.81.29.20.tcp 14017> HTTP [SYN] seq = 0 Len = 0 mss = 1460 Ws = 2 9 0.141816 203.81.29.20.192.168.1.61 tcp http> 14017 [SYN, ack] seq = 0 ACK = 1 win = 17280 Len = 0 mss = 1440 Ws = 0
426 3.334889 192.168.1.61 203.81.29.20.tcp 14017> HTTP [Fin, ack] seq = 1852 ACK = 150284 win = 257484 Len = 0
428 3.372253 203.81.29.20.192.168.1.61 tcp http> 14017 [Fin, ack] seq = 150284 ACK = 1853 win = 16998 Len = 0
448 4.395488 192.168.1.61 203.81.29.20.tcp 14020> HTTP [SYN] seq = 0 Len = 0 mss = 1460 Ws = 2
457 4.439604 203.81.29.20.192.168.1.61 tcp http> 14020 [SYN, ack] seq = 0 ACK = 1 win = 17280 Len = 0 mss = 1440 Ws = 0
859 7.593610 192.168.1.61 203.81.29.20.tcp 14016> HTTP [Fin, ack] seq = 2849 ACK = 377404 win = 257484 Len = 0
870 7.659680 203.81.29.20.192.168.1.61 tcp http> 14016 [Fin, ack] seq = 377404 ACK = 2850 win = 15935 Len = 0
888 8.511308 192.168.1.61 203.81.29.20.tcp 14020> HTTP [Fin, ack] seq = 1602 ACK = 208150 win = 257760 Len = 0
890 8.549451 203.81.29.20.192.168.1.61 tcp http> 14020 [Fin, ack] seq = 208150 ACK = 1603 win = 17280 Len = 0
892 8.566246 192.168.1.61 203.81.29.20.tcp 14022> HTTP [SYN] seq = 0 Len = 0 mss = 1460 Ws = 2
893 8.601893 203.81.29.20.192.168.1.61 tcp http> 14022 [SYN, ack] seq = 0 ACK = 1 win = 17280 Len = 0 mss = 1440 Ws = 0
899 8.702628 192.168.1.61 203.81.29.20.tcp 14023> HTTP [SYN] seq = 0 Len = 0 mss = 1460 Ws = 2
904 8.741807 203.81.29.20.192.168.1.61 tcp http> 14023 [SYN, ack] seq = 0 ACK = 1 win = 17280 Len = 0 mss = 1440 Ws = 0
1298 11.809456 192.168.1.61 203.81.29.20.tcp 14022> HTTP [Fin, ack] seq = 1550 ACK = 159770 win = 257484 Len = 0
1310 11.878665 203.81.29.20.192.168.1.61 tcp http> 14022 [Fin, ack] seq = 159770 ACK = 1551 win = 17280 Len = 0
1341 12.771707 192.168.1.61 203.81.29.20.tcp 14026> HTTP [SYN] seq = 0 Len = 0 mss = 1460 Ws = 2
1348 12.813950 203.81.29.20.192.168.1.61 tcp http> 14026 [SYN, ack] seq = 0 ACK = 1 win = 17280 Len = 0 mss = 1440 Ws = 0
1759 16.032952 192.168.1.61 203.81.29.20.tcp 14023> HTTP [Fin, ack] seq = 3151 ACK = 367918 win = 257484 Len = 0
1761 16.068296 203.81.29.20.192.168.1.61 tcp http> 14023 [Fin, ack] seq = 367918 ACK = 3152 win = 17280 Len = 0
1779 16.983042 192.168.1.61 203.81.29.20.tcp 14026> HTTP [Fin, ack] seq = 1602 ACK = 208150 win = 257760 Len = 0
1781 17.016836 203.81.29.20.192.168.1.61 tcp http> 14026 [Fin, ack] seq = 208150 ACK = 1603 win = 17280 Len = 0
In this case, the number of data packets is very large and there are many connections. Because the cache function is not available, you need to download all the resource files every time you open the page.
4. Select Ade
Result: A total of 525 data packets are obtained, 3 connections are established, and 3 are disconnected (no longer identified, SYN is the connection request, and fin is the disconnection request)
No. Time source Destination Protocol info
1 0.000000 192.168.1.61 203.81.29.20.tcp 14189> HTTP [SYN] seq = 0 Len = 0 mss = 1460 Ws = 2
2 0.033657 203.81.29.20.192.168.1.61 tcp http> 14189 [SYN, ack] seq = 0 ACK = 1 win = 17280 Len = 0 mss = 1440 Ws = 0
6 0.100636 192.168.1.61 203.81.29.20.tcp 14190> HTTP [SYN] seq = 0 Len = 0 mss = 1460 Ws = 2
9 0.133703 203.81.29.20.192.168.1.61 tcp http> 14190 [SYN, ack] seq = 0 ACK = 1 win = 17280 Len = 0 mss = 1440 Ws = 0
429 3.383748 192.168.1.61 203.81.29.20.tcp 14190> HTTP [Fin, ack] seq = 1852 ACK = 150284 win = 257484 Len = 0
431 3.418556 203.81.29.20.192.168.1.61 tcp http> 14190 [Fin, ack] seq = 150284 ACK = 1853 win = 16998 Len = 0
471 4.352071 192.168.1.61 203.81.29.20.tcp 14189> HTTP [Fin, ack] seq = 1504 ACK = 235576 win = 257760 Len = 0
472 4.380312 192.168.1.61 203.81.29.20.tcp 14192> HTTP [SYN] seq = 0 Len = 0 mss = 1460 Ws = 2
474 4.389778 203.81.29.20.192.168.1.61 tcp http> 14189 [Fin, ack] seq = 235576 ACK = 1505 win = 17280 Len = 0
476 4.413220 203.81.29.20.192.168.1.61 tcp http> 14192 [SYN, ack] seq = 0 ACK = 1 win = 17280 Len = 0 mss = 1440 Ws = 0
522 5.078068 192.168.1.61 203.81.29.20.tcp 14192> HTTP [Fin, ack] seq = 409 ACK = 35882 win = 257760 Len = 0
524 5.115099 203.81.29.20.192.168.1.61 tcp http> 14192 [Fin, ack] seq = 35882 ACK = 410 win = 16872 Len = 0
In this case, the cache plays a role, and data packets are greatly reduced compared to the third case, which is almost equal to the data volume (449 data packets) on the homepage once ), you only need to download the complete page (including resource files) when you open the page for the first time. You only need to download the HTML page (excluding resource files) when you open the page for the next three times ).
5. Select adef
After selecting F, let's look at the result: a total of 942 data packets are obtained, 4 are established, and 4 are disconnected.
No. Time source Destination Protocol info
1 0.000000 192.168.1.61 203.81.29.20.tcp 14292> HTTP [SYN] seq = 0 Len = 0 mss = 1460 Ws = 2
2 0.034524 203.81.29.20.192.168.1.61 tcp http> 14292 [SYN, ack] seq = 0 ACK = 1 win = 17280 Len = 0 mss = 1440 Ws = 0
6 0.102314 192.168.1.61 203.81.29.20.tcp 14294> HTTP [SYN] seq = 0 Len = 0 mss = 1460 Ws = 2
9 0.139752 203.81.29.20.192.168.1.61 tcp http> 14294 [SYN, ack] seq = 0 ACK = 1 win = 17280 Len = 0 mss = 1440 Ws = 0
426 3.791111 192.168.1.61 203.81.29.20.tcp 14294> HTTP [Fin, ack] seq = 1852 ACK = 150284 win = 257484 Len = 0
428 3.824970 203.81.29.20.192.168.1.61 tcp http> 14294 [Fin, ack] seq = 150284 ACK = 1853 win = 16998 Len = 0
468 6.213276 192.168.1.61 203.81.29.20.tcp 14292> HTTP [Fin, ack] seq = 1504 ACK = 235576 win = 257760 Len = 0
469 6.244052 192.168.1.61 203.81.29.20.tcp 14297> HTTP [SYN] seq = 0 Len = 0 mss = 1460 Ws = 2
471 6.249564 203.81.29.20.192.168.1.61 tcp http> 14292 [Fin, ack] seq = 235576 ACK = 1505 win = 17280 Len = 0
473 6.279647 203.81.29.20.192.168.1.61 tcp http> 14297 [SYN, ack] seq = 0 ACK = 1 win = 17280 Len = 0 mss = 1440 Ws = 0
479 6.374967 192.168.1.61 203.81.29.20.tcp 14298> HTTP [SYN] seq = 0 Len = 0 mss = 1460 Ws = 2
484 6.419597 203.81.29.20.192.168.1.61 tcp http> 14298 [SYN, ack] seq = 0 ACK = 1 win = 17280 Len = 0 mss = 1440 Ws = 0
897 9.858493 192.168.1.61 203.81.29.20.tcp 14297> HTTP [Fin, ack] seq = 1550 ACK = 159770 win = 257484 Len = 0
899 9.895188 203.81.29.20.192.168.1.61 tcp http> 14297 [Fin, ack] seq = 159770 ACK = 1551 win = 17280 Len = 0
939 12.840029 192.168.1.61 203.81.29.20.tcp 14298> HTTP [Fin, ack] seq = 1806 ACK = 226090 win = 257760 Len = 0
941 12.876120 203.81.29.20.192.168.1.61 tcp http> 14298 [Fin, ack] seq = 226090 ACK = 1807 win = 17076 Len = 0
In this case, because f is selected and the cache is cleared during iteration, the resource file needs to be re-downloaded for each iteration. A data packet is about half of the third case, which is about the data volume of the home page opened twice (449x2 data packets ).
6. About BC options
C's explanation (Check for newer versions of stored pages every visit to the page)
C is easy to understand. It is similar to the check in IE settings. If C is not set, LR will not send a new request to the server for cached files. If C is selected, you can find a lot of 304 information in the data packet.
B's explanation (Cache URLs requiring content (htmls ))
LR does not actually cache resource files in the memory or on the disk. This option indicates that the page resolution content is actually cached in the memory for some associations, verifications, and page resolutions that need to be used, reduce repetitive work on the client.
Of course, if you want to cache the GIF to the memory, you can set it in advanced, select specify URL requiring content in addition to HTML pages, add the entry image/GIF, and select. When vuseris running, you can compare the memory consumption of the mongommdrv.exe process (more memory usage ).
Iv. Conclusion
Through the test analysis above, we probably know the true meaning of each option. You need to select the appropriate settings based on your testing purpose:
1. for a specific application test, the front-end web server cannot be ignored. The default settings are very suitable and do not need to be adjusted (sometimes you need to consider selecting C)
Note: many users are used to storing the login operation in vuser_init when recording the script. At this time, the default setting may cause an error. We recommend that you include all these operations in the action.
2. If you are more concerned about the performance of the backend application server or do some architecture Verification and analysis, then your default settings are not suitable for you. You need to cancel all settings.
Of course, you can also make different adjustments based on your actual situation, but you must understand the specific meaning of these options to avoid making mistakes.