LoadRunner-When Discuznt meets LoadRunner (next) (forwarded)

When Discuznt met LoadRunner (next)

In the previous two articles, you basically described how to record scripts and generate concurrent users, as well as a brief description of several of the charts in the test report. Today's article is the last of the series and will show you how to see how the system works through the test report, identify the factors that affect performance, and how to optimize it.

First, take a look at this picture of the concurrent user:

This is the test report that I generated before the optimization, which can be seen in this diagram for up to 24 minutes (which is representative in countless previous tests).

The peak value of concurrent users is from 4--15 minutes, which lasts for nearly 11 minutes. For now, the test time and peak duration of its execution will certainly be much worse than Discuz (PHP), as DZ is almost more than 10 minutes ' end of life. Here, let's take a look at the average thing response time graph, as follows:

It can be seen that the most time-consuming operation is "posttopic", and we merge the graph by clicking the right mouse button on the graph and then checking merge graphs, which merges the concurrent user () with this diagram:

The following diagram follows the merge:

The first thing to be sure is that when the concurrency comes up (1000 users, Posttopic is basically the highest bit, while viewing the theme (Showtopic), the Display section (Showforum) also has ' uptrend '). It was not until the concurrency passed that the number of users came down and the response time for these operations was fast. In fact, I think we can use Posttopic as the starting point for optimization, then the Showtopic,showforum transaction in turn. Note that I use a ' transaction ' instead of a page for a simple reason, such as posttopic transaction internals including: Topic and jump to Showtopic page (recall my description in the first article). In order to see more ' clearly ', it is necessary to add several graphs, as follows:

Then click on the "Opengraph" button to add these four graphs, then we will open the Web page breakdown and set to Posttopic_transaction, to see the transaction in the corresponding

The execution of the operation is as follows:

The first ' discovery ' is that the page string is not just about the "hair theme", "Show theme", but also another Ajax request , which takes 15 seconds, which is not supposed to occur in this transaction. In other words, the issue of the topic of the Ajax load back the ' Take the Blame ' (note: Later, after the test found that the request is issued when the page is loaded, and can be loaded after the user mouse click), as follows:

Then look at the hair theme after the success, jump back to the "Show Topic page" (showtopic) operation situation:

The following is posttopic, the processing time when submitting a POST request (19 seconds, although currently acceptable, but after the estimate, this time is greatly improved):

It seems that the light on the submission, posttopic or faster than showtopic, it seems that the optimization order before the adjustment, the Posttopic and showtopic are placed on the same priority to optimize the two pages. Let's take a look at the implementation of Showtopic this transaction, such as:

A look scare, how this page also has that Ajax load ah, it seems that the problem is not that simple, and then look at the showtopic page load time:

It seems that this Ajax loading has been like Dogskin plaster stick in our product body, hurriedly put the problem to the relevant developers, hehe.

After the analysis of these transactions, there is also a problem, is the observation of throughput, because if the throughput (throughput) curve with the increase in the number of vuser does not increase, but instead shows a relatively flat line, indicating that the current network speed is not able to meet the current system requirements, The network is causing bottlenecks. To eliminate this possibility, it is necessary to look at the throughput graph, as follows:

The chart is still normal, and it's a relief (it must be 100 trillion bandwidth). The following is a special optimization of the corresponding page and data access operations.

Here, I still use the profiler to observe that SQL operations are performed frequently, such as:

Note: In order to simplify the space, the final observation results are listed directly here.

first is the frequent online table operation Update, method name: Onlineuser.updateaction (...), optimized, the number of calls that the operation has in the Showforum,showtopic,posttopic page changed from two times to one.

Next is the operation to obtain the user information, method name: User.getshortuserinfo (), method because the parameter is used in the improper parameters, resulting in the update of the user's integration needs to be executed one to two times.

Update User points: Users.updateusercredit (), this operation is mainly used in the Posttopic page, because its original design simultaneous can not be universal, resulting in the subsequent developers have to write an inefficient method to meet their own needs, Affects the execution efficiency of the submission topic page.

Of course, in addition to the above three major problems, there are some other issues, not listed here. Of course, these problems are solved by refactoring optimizations (including previous AJAX request issues). So finally the results we see after the optimization are as follows (note: For ease of comparison, I will optimize before and after the optimization of the Post):

First, before the optimization :

after optimization:

It can be seen that the main page performance has been lifted up, especially posttopic this transaction, from 65 mentioned 26. In particular, before writing this article, we are still optimizing the performance of the program, so that "in the face of optimization, only the starting point, there is no end ."

The following are 1000 concurrent CPU usage before and after optimization:

Optimized CPU Utilization:

At the same time, here is a load test of the Discuz when the 1000 concurrent users of the CPU run:

And the Discuz test report is as follows:

OK, basically the process is finished, the following is a small episode, so as not to let others make the same mistakes as me.

In the previous round of optimization, because our product has the pop -up theme and non-pop theme two settings, and on the non-pop-up theme of the issue, causing me to spend a few 1 days on this functional test time to find reasons, such as:

Of course, because we have this feature is a page, that is, posttopic, and in this page CS, "Non-pop window" Using this method: Setmetarefresh (5)

The effect is that after the theme is successful, do not jump to the Showtopic page, but pause on this page for 5 seconds (to display the word " submit success ", such as the words, such as):

Then the meta element to jump to the showtopic, and this is the 5 seconds, artificially reduced the page response time, and LR is really ' honest ' to record the 5 seconds, resulting in a high response time on this transaction scary. The discuz has a corresponding switch in the background to control whether the ' submit success ' is displayed. Of course now we've added a similar setting in the background.

Another point is that through the optimization of some important pages, but also may bring other pages to improve the efficiency of the work, it will be difficult to do faster, the system can be free to speed up the execution of other work speed , hehe.

In LR, this kind of thing is just the tip of the iceberg, as long as you have lisence, you can see more things, such as you can see the effect of CPU context switching on system throughput , such as:

There are many useful functions such as database stress test , set point , parameterization and so on.

Well, today's content will be here first, continue to optimize the program to:)

Original link: http://www.cnblogs.com/daizhj/archive/2009/09/27/1575091.html

Author: Daizhj, the earthquake-generation army

Website: http://daizhj.cnblogs.com/

Category: discuz! NT, pressure test (LoadRunner) Tags: discuznt, loadrunner, pressure test

LoadRunner-When Discuznt meets LoadRunner (next) (forwarded)