|
|
|
|
|
- Lesson 2 - Performance profiler
- Performance profiler overview
- Starting the performance profiler
- Analyzing the result
- Result of the example
- Project optimization
- Conclusion
Tutorial - Optimizing a WEBDEV project
Lesson 2 - Performance profiler We will cover the following topics: - Overview.
- Starting the performance profiler.
- Analyzing the result.
 15 min Performance profiler overview The performance profiler checks and optimizes the execution time of the website processes. The principle is straightforward: - The website test is run.
- During this test, the performance profiler keeps track of all the actions performed and saves the execution times of each one of the processes.
At the end of the test, the performance profiler displays: - the 10 most time-consuming operations,
- the duration and the number of calls of all processes executed.
The "WW_Optimization" project we used in the previous lesson has a specific page that shows examples of results obtained with the performance profiler. Starting the performance profiler The performance profiler can be started directly from the WEBDEV editor.
Warning
In this lesson, we will use the example used in lesson 1.
To start the performance profiler on the "WW_Optimization" project: - In the ribbon, on the "Project" page, "Audit and performance" group, expand "Analyze performance" and select "Analyze performance".
- The project test is run.
- Click "TEST PAGE OF PERFORMANCE PROFILER".
- Click "PROCESS TO ANALYZE".
- Validate the information window and close the browser to stop the project test. The performance profiler report window appears.
Results are displayed in several tabs: - the "Summary" tab shows the ten longest processes.
- the "Mapping" tab shows a graphical view of the main processes.
- the "Details" tab shows all the processes run during the test of the application (from the slowest to the fastest).
- the "Calls" tab shows the details of the operations performed in a process.
Result of the example Let's take a closer look at the result of our example. - The "Summary" tab shows the ten longest processes. In our example, you can see that the "UpdateProductStock" local procedure takes more than 3 seconds to be executed (this time may change according to the power of your computer).
- The "Mapping" tab shows a graphical view of the elements that took the longest. In our case, it's a call to HTTPRequest:
- The "Details" tab shows all the processes or events executed, from the slowest to the fastest.
In our case, the "Details" tab indicates that the call to HTTPRequest is one of the elements taking the longest time. - Select this line. We are going to check whether this slowdown is caused by a specific problem.
- Click "Calls" to view the details of the calls to the UpdateProductStock procedure.
- Select the "HTTPRequest" line and click the "Code" button. The corresponding line of WLanguage code is displayed the code editor.
- Close the performance profiler.
- The following line of WLanguage code is executed:
HTTPRequest("supplier-addr")
The slowdown is caused by the fact that the address specified for HTTPRequest is not accessible.
 The code editor shows a "Wrong way" icon to indicate that an error has been found on this line of code at runtime. The details of the error are shown when hovering over the icon.
Project optimization We will optimize this code: - Replace the line of code containing HTTPRequest by the following line of code:
HTTPRequest("www.google.com")
- Save the code (Ctrl + S).
We will restart the performance profiler: - On the "Project" tab, "Audit and performance" group, expand "Analyze performance" and select "Analyze performance".
- The project test is run.
- Click "TEST PAGE OF PERFORMANCE PROFILER".
- Click "PROCESS TO ANALYZE".
- Validate the information window and stop the project test. The performance profiler report window appears.
- On the "Mapping" tab, HTTPRequest does not appear with the same importance.
We have optimized the website using the performance profiler Close the performance profiler report window. In this lesson, we saw how to use the performance profiler. The performance profiler can also be run from a WLanguage process, using the following functions: - ProfilerStart, which starts "collecting data" for the performance profiler.
- ProfilerEnd, which stops "collecting data" for the performance profiler.
In this case, only the code between ProfilerStart and ProfilerEnd will be analyzed. The result is saved as a WPF file that can be read by WEBDEV.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|