11. migrate call-intensive COM components to managed code . NET Framework provides a simple way to interact with traditional COM components. The advantage is that the new platform can be used while the existing investment is retained. However, in some cases, retaining the performance overhead of the old component makes it worthwhile to migrate the component to the managed code. Every situation is different. The best way to determine whether to migrate components is to measure the Running Performance of web sites. We recommend that you study how to migrate any COM component that requires a large number of calls for interaction to managed code. In many cases, it is impossible to migrate legacy components to managed code, especially when a web application is initially migrated. In this case, one of the biggest performance barriers is to mail data from an unmanaged environment to a hosted environment. Therefore, in interactive operations, perform as many tasks as possible at any end, and then make a large call instead of a series of small calls. For example, all strings in the Common Language Runtime Library are Unicode, so all strings in the component should be converted to unicode format before calling managed code. In addition, after processing any COM objects or local resources, release them. In this way, other requests can use them and minimize the performance problems caused by later requests to the garbage collector to release them. 12. Use early binding in Visual Basic. Net or JScript. Code In the past, one of the reasons why developers like to use Visual Basic, VBScript, and JScript is the so-called "non-type" nature. Variables do not need explicit type declarations and can be created simply by using them. When the data is allocated from one type to another, the conversion is automatically executed. However, this convenience will greatly damage the performance of the application. Visual Basic now supports type-safe programming by using the option strict compiler command. For backward compatibility, ASP. NET does not enable this option by default. However, to achieve optimal performance, we strongly recommend that you enable this option on the page. To enable option strict, include the strict attribute in the @ page command, or include this attribute in the @ control command for user controls. The following example shows how to set this attribute and calls four variables to show how this attribute causes a compiler error. JScript.. Net also supports non-type programming, but it does not provide compiler commands that force early binding. If any of the following conditions occurs, the variable is bound in the late stage: it is explicitly declared as an object and is a field of the class without type declaration, is a special function or method member without explicit type declaration, and cannot deduce the type from its use. The last difference is complicated, because if the JScript.. Net compiler can deduce the type based on the usage of the variable, it will be optimized. In the following example, variable A is bound early, but variable B is bound late. VaR A; var B; A = "hello"; B = "world"; B = 0; to achieve optimal performance, when declaring JScript .. net variable, assign a type to it. For example, var a: string. 13. Make all modules in the request pipeline as efficient as possible All modules in the request pipeline have the opportunity to be run in each request. Therefore, it is critical to quickly trigger code when a request enters and leaves the module, especially in the code path that does not use the module function. The throughput test is executed when modules and configuration files are used and not used separately, which is very useful for determining the execution speed of these methods. 14. Use httpserverutility. Transfer to redirect between pages of the same application Use the server. transfer syntax to avoid unnecessary client redirection by using this method on the page. 15. Adjust the number of threads for each auxiliary process of the application if necessary The request structure of ASP. net tries to strike a balance between the number of threads executing the request and the available resources. An application that uses sufficient CPU power is known. This structure determines the number of requests that can be executed simultaneously based on the CPU power available for requests. This technology is called thread-control. However, in some conditions, the thread-control algorithm is not very effective. By using the pipeline instance count performance counter associated with the performance object of ASP. NET applications, You can monitor thread-control in perfmon. When a page calls external resources, such as database access or XML Web Services requests, the page requests usually stop and release the CPU. If a request is waiting for processing and a thread in the thread pool is free, the waiting request will start to be processed. Unfortunately, sometimes this may lead to a large number of concurrent requests and many waiting threads on the Web server, which have adverse effects on server performance. Generally, if the gate factor is the response time of external resources, too many requests are waiting for resources, which is not helpful for the Web server throughput. To alleviate this problem, you can manually set the number of threads in the process by changing the maxworkerthreads and maxiothreads attributes of the machine. config configuration file node. Note: The auxiliary thread is used to process ASP. NET requests, while the IO thread is used to provide services for data from files, databases, or XML Web Services. The value assigned to these attributes is the maximum number of threads in each CPU type in the process. For dual-processor computers, the maximum number is twice the set value. For a four-processor computer, the maximum value is four times the set value. In any case, it is best to change the default value for computers with four or eight CPUs. The default value can be used for computers with one or two processors. However, for computers with more processors, one hundred or two hundred threads in a process may cause more disadvantages. Note that too many threads in a process will often reduce the server speed, because the operating system will spend the CPU cycle on the maintenance thread rather than processing the request due to extra context switching. 16. Use the Garbage Collector and Automatic Memory Management of the Common Language Runtime Library as appropriate Be careful not to allocate too much memory to each request, because the Garbage Collector must do more work more frequently. In addition, do not point unnecessary pointers to objects because they will keep objects active and avoid objects containing the Finalize method as much as possible, because they will lead to more work in the future. In particular, do not release resources in finalize calls, because resources may always consume memory before they are recycled by the garbage collector. At last, this problem often causes a devastating impact on the performance of the Web server environment, because it is easy to exhaust a specific resource while waiting for finalize to run. 17. If there is a large web application, consider executing pre-Batch compilation. Each time a first request to a directory is sent, a batch compilation is performed. If pages in the directory are not analyzed and compiled, this function analyzes and compiles all pages in the directory in batches to make better use of disks and memory. If this takes a long time, a single page is quickly analyzed and compiled so that the request can be processed. This feature brings ASP. NET performance benefits because it compiles many pages into a single assembly. Accessing a page from a loaded assembly is faster than loading a new assembly on each page. The disadvantage of batch compilation is that if the server receives many requests for pages that have not yet been compiled, the performance may be poor when the web server analyzes and compiles them. To solve this problem, you can execute pre-Batch compilation. Therefore, you only need to request a page from the application before it is activated, regardless of the page. Then, when the user visits your site for the first time, the page and its assembly will have been compiled. There is no simple mechanism to know when batch compilation will take place. Wait until the CPU is idle or no more compiler processes (such as csc.exe (C # compiler) or vbc.exe (Visual Basic compiler) Start. Avoid changing the assembly in the \ bin directory of the application. Changing the page will cause re-analysis and compilation of the page, and replacing the assembly in the \ bin directory will cause full re-Compilation of the directory. On a large site that contains many pages, a better way is to design different directory structures based on the frequency of page replacement or Assembly planned. Pages that do not often change can be stored in the same directory and pre-compiled at a specific time. Frequently changed pages should be in their own directories (each directory can contain hundreds of pages at most) for quick compilation. Web applications can contain many subdirectories. Batch compilation occurs at the directory level, not the application level. 18. Do not rely on exceptions in the code Exceptions greatly reduce performance, so you should not use them as a way to control normal program processes. If the code may cause exceptions, perform this operation. Do not capture exceptions before processing the status. Common solutions include checking null, assigning a value to a string that is analyzed as a numeric value, or checking a specific value before applying a mathematical operation. The following example shows the code that may cause exceptions and test whether code in a certain status exists. The two generate the same results. Try {result = 100/num;} catch (exception e) {result = 0;} //... to this. If (num! = 0) Result = 100/num; else result = 0; 19. Use httpresponse. Write to concatenate strings This method provides very effective buffering and connection services. However, if you are executing extensive connections, use multiple response. Write calls. The technology shown in the following example is faster than the connection string using a single call to the response. Write method. Response. write ("A"); response. write (mystring); response. write ("B"); response. write (myobj. tostring (); response. write ("C"); response. write (mystring2); response. write ("D"); 20. disable the buffer for special reasons. Disabling web form page buffering can cause a large amount of performance overhead. 21. Only save the Server Control view status when necessary Automatic view status management is a function of the server control. This function enables the Server Control to re-fill their attribute values during the round-trip process (you do not need to write any code ). However, because the view State of the server control is redirected to and from the server in the hidden form field, this function does have an impact on performance. You should know under which circumstances the view status will be helpful and under which circumstances it will affect the page performance. For example, if you bind the server control to the data in each round-trip process, the saved view status will be replaced with the new value obtained from the data binding operation. In this case, disabling the view status can save processing time. By default, view status is enabled for all server controls. To disable view status, set the enableviewstate attribute of the control to false, as shown in the following DataGrid Server Control example. You can also use the @ page command to disable the view status of the entire page. This is useful when you do not send the page back to the server: Note: The @ control command also supports the enableviewstate attribute, which allows you to control whether the view State is enabled for the user control. To analyze the number of view States used by the server control on the page, please (include the trace = "true" attribute in the @ page command) enable tracing on this page and view the viewstate column of the control hierarchy table. For more information about tracing and how to enable it, see ASP. NET tracing. 22. Avoid unnecessary round-trip to the server Although you may want to use the time-saving and code-saving functions of the web forms page framework as much as possible, ASP. NET Server controls and sending back events cannot be used in some cases. Generally, you only need to start the round-trip process to the server when retrieving or storing data. Most data operations can be performed on clients during the round-trip process. For example, it is often possible to verify user input from an HTML form on the client before the data is submitted to the server. Generally, if you do not need to pass the information to the server to store it in the database, you should not write the code that leads to the round-trip process. If you develop custom server controls, consider making them present client code for browsers that support ecmascript. By using the server control in this way, you can significantly reduce the number of times information is not necessary to be sent to the web server. Use Page. ispostback to avoid unnecessary operations on the round-trip Process If you write the code for processing the Server Control sending and processing, you may sometimes need to execute other code on the first request page, instead of the Code executed when the user sends an HTML form contained in the page. Whether the page is generated in response to the server control event. Use the page. ispostback attribute to execute code conditionally For example, the following code demonstrates how to create a database connection and command. This command binds data to the DataGrid server control when you request this page for the first time. Void page_load (Object sender, eventargs e) {// set up a connection and command here. If (! Page. ispostback) {string query = "select * from authors where firstname like '% Justin %'"; mycommand. fill (DS, "Authors"); mydatagrid. databind ();}} Because the page_load event is executed during each request, the code above checks whether the ispostback attribute is set to false. If yes, the code is executed. If this attribute is set to true, no code is executed. Note that if you do not run this check, the page sending behavior will not be changed. The code of the page_load event is executed before the Server Control event is executed, but only the results of the server control event can be displayed on the output page. If you do not run this check, the page_load event and any server control event on the page will still be processed. 23. Disable it when the session status is not used Not all applications or pages need to be specific to the user's session status. You should disable the session status for any applications or pages that do not need the session status. To disable the page session Status, set the enablesessionstate attribute in the @ page command to false. For example: Note: If the page needs to access session variables without creating or modifying them, set the enablesessionstate attribute in the @ page command to readonly. You can also disable the session Status of the XML Web Services method. For more information, see XML Web Services created using ASP. NET and XML Web Services clients. To disable the session Status of an application, set the mode attribute to off in the sessionstate configuration section of the Application Web. config file. For example: 24. Carefully select the session Status provider ASP. NET provides three different methods for storing application session data: in-process session Status, out-of-process session status as a Windows service, and out-of-process session Status in the SQL Server database. Each method has its own advantages, but the in-process session status is the fastest solution so far. If you only store a small amount of data that is prone to loss in the session state, we recommend that you use in-process providers. Out-of-process solutions are mainly used to scale applications across multiple processors or computers, or to prevent data loss during server or process restart. For more information, see ASP. NET status management. 25. Unnecessary Server Control In Asp.net, a large number of server-side controls facilitate program development, but may also lead to performance loss, because each time a user operates a server-side control, a round-trip process with the server is generated. Therefore, server control should be used less unless necessary. 26. ASP. NET application performance test Before performing a performance test on ASP. NET applications, ensure that the application is correctly functioning and has no errors. You can use the following tools to test the performance: Web application strees tool (was) is a free test tool released by Microsoft. It can be downloaded from http://webtool.rte.microsoft.com. It can simulate hundreds of thousands of users simultaneously to access web applications, form a traffic load on the server, so as to achieve the purpose of testing, can generate average ttfb, average TTLB and other performance summary reports. Application Center Test (ACT) is a testing tool that is attached to the Enterprise Edition of Visual Studio. NET and is a Web application testing tool officially supported by Microsoft. It can intuitively generate chart results with more functions than was, but does not have the ability to test multiple clients at the same time. The "performance" counter in the "Administrative Tools" of the server operating system can monitor the server to understand the application performance. Conclusion: For website developers, compile ASP. net Applications, develop good habits, improve application performance, at least can delay the necessary hardware upgrade, reduce the cost of the website. |