Sometimes our Web applications are very fast when tested locally, but when tested on the LAN, performance problems will be found; sometimes even applications with normal speed on the LAN will be found on the WAN. question. These problems are generally due to negligence or errors in the application and do not involve system architecture. The problem can be found and solved through debugging and testing in the real environment.
What we are talking about today is to fundamentally improve the performance of ASP.Net applications by improving the architecture.
Let's first test a few simple applications of ASP.Net.
Test environment: AthlonXP 3200+, DDR400 512M, WindowsXP SP2, native SQL Server 2000, product table of Chinese Northwind database (imported from Access), about 70 records.
| Test serial number | Program type | Test method | Test result (Requests per second) | SQLServer Resources occupied | ASP.Net Resources occupied |
| 1 | The Web service | fills the DataSet with the product table and returns the number of records | 250 times | 100% | - |
| 2 | The Web service | fills the DataSet with the product table and returns the DataSet | 138 times | 54% | 46% |
| 3 | The Web application | fills the DataSet with the product table and returns Bind DataGrid | 70 times | 28% | 72% |
In the first test, the Web service only reads records from the database, fills them into the DataSet, and returns the number of records (note that it does not return records). It occupies very few system resources. It is assumed that the system resources are completely occupied by SQL Server, and the conclusion is not clear. There will be negative effects.
In the second test, when the Web service returns a DataSet, the number of requests per second is reduced by almost half. Half of the system resources are used by ASP.Net to serialize the DataSet.
In the third test, where the Web application binds the DataSet to the DataGrid and returns the page, the number of requests per second is reduced by almost three-quarters. These system resources are used by ASP.Net to bind the DataSet to the DataGrid and return the page. Serialize the page.
From the above tests, we can see that the binding and serialization of DataGrid will occupy a lot of system resources. If you want to improve system performance, you need to improve the architecture.
1. Separate the operations on the database from the page and put them in an independent persistence layer.
In this way, the data is displayed as a table through DOM or XSLT on the client side, replacing the binding work of the DataGrid on the server side, which greatly reduces the pressure on the server. And the client obtains data from the persistence layer through AJAX, which will improve the user experience.
2. Completely separate the page from the data so that the cache can be used.
Some pages that apply AJAX will still read the initial data, so the page cannot be cached. These pages are generally more complex and occupy more resources than ordinary pages. If the cache can be used, the performance of the system will be further improved.
Through the above two points, the performance of ASP.Net can be almost doubled.
You can test it yourself, or visit our sample www.BizStruct.cn .