Chapter 1 Performance (1)

[Translation]
Over the past few days, I 've carefully reviewed inside dynamics ax4.0, and several chapters after Chapter 8 are very attractive. Chapter 17th impressed me the most, because I usually write Program The implementation of functions is often more important, performance problems are often ignored, and there is no guidance on how to write high efficiency in ax Code This is the first time you see a similar Article . I originally wanted to write my reading notes. After reading it several times, I found that the author's writing is concise enough. Any reduction may be against the author's original intention, I really like the content written in this chapter, so I decided to translate it word by word.

I'm not sure whether translating the original text on the blog will infringe the copyright of the original author. Therefore, if you see this article, do not reprint it. (Of course, no one is interested in reprinting it, however, for the sake of disclaimers, I would like to say that I have infringed the copyright, and I will withdraw this article as quickly as possible.

In addition, I can only translate documents from off-duty time. I am sorry for the limited time, and my understanding of ax is very simple and I am very sorry for the level of bird language. If there are some mistakes in translation, I would like to see my colleagues in this article discuss it together, we are very grateful for your support.

Content of this chapter:
Introduction 427
Client/Server performance 428
Transaction performance 432
The original Article is transaction performance. I don't think there is a way to summarize the content in the text whether translated into transactions or transactions. The actual content is how the server can better interact with the database server, how to Use the cache to improve performance)
Dynamics ax monitoring tool 457
Summary 461
Objectives of this chapter:
1. describes how to control the execution of logic in a three-tier environment and what to pay attention to when designing and implementing x ++ code.
2. Explain how to optimize database performance, how to limit lock applications and optimize select statements through batch operations and caching to reduce database interaction.
3. describes the tools used to monitor Client/Server calls, database calls, and code execution in the development environment of dynamics ax4.0.
Introduction
Performance is often considered later. many development teams seldom pay attention to performance before the development stage. What's more, they only pay attention to performance issues when users report performance issues in the formal environment. after a function is implemented, it is very difficult to do a little performance improvement. however, if you know how to use the performance optimization features in ax, you can design a good performance in ax development and running environments.
In this chapter, we will introduce the notes for developing functions to run in a three-tier environment. In a three-tier environment, the X ++ code can run either on the server or on the client. other features of performance enhancement will also be introduced, such as batch update and cache for database interaction, which can be set in metadata or through X ++ code, and use Optimistic Concurrency Control to limit database locking. finally, this chapter ends by introducing several dynamicsax performance monitoring tools that provide a reliable foundation for monitoring Client/Server calls, database activities, and the execution of X ++ code: it is awkward to translate the foundation here ......).
Client/Server Performance
As described in Chapter 1 "Architecture Overview", dynamicsax is a three-tier client/server application. When a dynamicsax application is running, the application running logic can be executed on the client or server.
Note: The dynamicsax application does not support application logic execution at the database layer (in fact, many systems fully implement the business layer using stored procedures. Of course, the execution of business logic is placed at the database layer)
By default, all x ++ code is defined as "called from", meaning that the method runs in the place where the call occurs. the instance method of the class will run on the layer where the object is instantiated.
The application logic that relies heavily on databases (the original article is database-intensive) should run as close as possible to the database, of course, it is the server layer. The application logic to interact with the user should be as close as possible to the user, that is, the client layer. This reduces the round-trip between the client and the server. These round-trips involve sending data packets between two layers. This usually happens in a network with a certain bandwidth and latency, which affects performance. At the same time, the communication between the client and the server is synchronized, which means that the client must wait for the server to complete the client's call to the server, this means that the client requests the server to execute a certain logic. Because the logic is synchronous, the client must wait for the server to execute this code), and vice versa.
Note for those that do not involve interaction with users and databases but are strongly dependent on CPU) the application logic of is to allow them to run on the client or to always hand over to the server for controversial opinions. Generally, a client serves only one user and another user. The server usually processes requests from multiple users. However, the server performs much better than the client, so it is difficult to decide which layer has the most resource operation logic during the development stage. In the latest dynamicsax version, reducing the client/server traffic is the development goal, but the execution of the application logic that is strongly dependent on the CPU is moved to a specific layer and implemented as a target.
Execution of control logic
When a dynamicsax application is running, you can set metadata or use X ++ code to specify a method signature to control where the application logic is executed, the client and server method modifiers can be applied to table instances and static methods of classes. When the client modifier is applied, the method will always be executed on the client. When the server modifier is applied, the method will always run on the server. If the caller and the called method are the calling method, the call method should be called. However, in my understanding, it should be the caller and the called method, maybe my understanding is biased. For the moment, the translation is not on the same layer. The application logic will run on the layer specified by the called method, the call layer waits for the called method to exit or the call layer to call a method to forcibly return the result.
The running layer of the class instance method is controlled by the class runon attribute. this attribute can be set to called from, server, or client. if this attribute is set to called from, this type of object is called at the instantiation layer, which layer is the instantiation layer) is instantiated, and all instance methods are also executed in this layer. If this attribute is specified as a server or client, the object is strengthened at the specified layer (no matter which layer the new method is called, the instantiation action always occurs at the layer specified by the runon attribute. For example, if the new method of this class is called on the client, but the runon attribute specifies the server, the instantiation of this object occurs on the server, this can be determined by calling the Global: isrunningonserver method in the new method ). only when the runon attribute of the base class is set to called from can the runon attribute of the derived class be modified. if the runon attribute of the base class is set to client or server, the derived class inherits its settings.
By default, if the server or client modifier table is not specified, the instance and static method are executed by "called from. you can specify both the client and server modifiers for a method, but this does not affect the execution of the method; it means that the developer of this method has evaluated this method and decided that this method should be executed according to "called from" instead of running on the client or server: the original Article is client bound or server bound ).
Note by default, the insert, update, and delete methods of the table are always run on the server side, even if they are not identified during method definition. these methods cannot be forcibly run on the client, because the client modifier will be ignored when the dynamicsax application is running, if you try to add the client modifier in these methods, an error will be reported during compilation. "error: 140, client modifier cannot be used for data access methods ")
If the client or server modifier is not specified on the static method of the class, these methods will run on the layer specified by the runon attribute of the class. You can specify the client and server Modifier on the method at the same time, which forces the method to run in the "called from" way and ignore the specified attribute value on the class.
Annotations can be used to specify the client and server modifiers for the instance method and form report method of the class, but they are ignored during application running: in fact, if you try to specify the client and server modifier in the above method, an error "error: 50, the client and server modifier can only be used for static methods" will be reported during compilation. ").
When the class is called through the menu item, you can also specify the class running on the server side in the menu item, the client or the call layer. this is because the menu item also has the runon attribute, which can be set to the same value as the class attribute (: called from, client, server), which is equivalent to setting on the class, of course, the menu item cannot overwrite the settings of the class (Note: only when the runon attribute of the menu item is set to called from Will it run according to the attribute specified on the menu item ).
Optimize Client/Server calls
When developing methods and table methods, you need to consider whether classes can be instantiated on the client and server, or only one of them can be instantiated. this decision depends on the application logic implemented in the method. when developing a class, you also need to consider the application interface (API ), especially when developing a class that only runs on the server side and the class is called by the application logic of the client side.
Consider the following X ++ example. server-side binding is translated as running only on the server side, which is represented by server-side binding, the actual meaning is that the class serverclass runs only on the server side) is instantiated, and two variables are passed to the object to return the result. this section of X ++ code is at least five rounds between the client and the server: one is when the serverclass class is instantiated, and the other two occur when the parameter is passed, when the result is obtained, the last time the reference of the serverclass object exceeds the scope. The object will be recycled on the server end. Static   Void Callingserverclass (ARGs _ ARGs)
{
Serverclass;
Int Result;
;
Serverclass =   New Serverclass (); // Call to server
Serverclass. parmvariable1 ( 20 ); // Call to server
Serverclass. parmvariable2 ( 30 ); // Call to server
Result = Serverclass. Result (); // Call to server
 
// Destory object-call to server
}

You can combine the operations that call the parm method and result method to reduce the number of calls. The Code is as follows: Static   Void Callingserverclass (ARGs _ ARGs)
{
Serverclass;
Int Result;
;
Serverclass =   New Serverclass (); // Call to server
Result = Serverclass. Result ( 20 , 30 ); // Call to server
 
// Destory object-call to server
}

This method reduces the number of server calls twice, and the total number of calls is reduced to three. the optimization solution is not to instantiate the server-side binding class on the client, but to call the static method of the server-side binding class. The Code is as follows: Static   Void Callingserverclass (ARGs _ ARGs)
{
IntResult;
;
Result=Serverclass: calcresult (20,30);//Single call to server
}

The same optimization can be used for the table method bound to the server. if the client needs to call multiple server binding methods sequentially, a single call can be encapsulated using one server binding method, and other methods can be called on the server.
Passing parameters with reference and Value
When the client has a reference pointing to a server object, the server will query the client from time to time by calling the client to determine whether the client also contains a reference pointing to the object. if not, the server layer recycles the object. if the server layer also contains references to the client object, the client executes the same query. of course, in the example above, when a server-bound class is instantiated on the client, the above situation occurs. if an object is instantiated on the client and passed as a parameter to a method bound to the server, the above situation also occurs. In this case, object references exist in both layers. These references point to the same object, which leads to additional Client/Server calls to determine whether these objects can be recycled.
You can consider using the value-passing method to replace passing objects between layers by referencing. that is to say, the value is passed to another layer, and then these values are used to instantiate an object of the same type. in this way, two different objects that are not associated with each other exist in two layers, so there is no need to trace object references between layers.
The annotation runbase framework automatically supports passing by value. the runbase framework packs variables into a container, passes the iner to another layer, unpacks the container, and instantiates a new object based on the variables in the container.
Reports and forms
Dynamicsax reports can be executed on a client or server. where the execution is defined by the menu items for opening the report. if the report is executed on the server but displayed on the client, the report page is generated on the server and then sent to the client. if a report is executed on the client, the client displays and generates a report page (the original article is renders and generates, but do I think generates and render are better? It is first generated and then displayed. I don't know if my understanding of these two words is incorrect ).
Fat form (original article: rich forms, rich client is generally translated into a fat client, this fat form is really hard to hear ......) it is always executed on the client, which increases the Client/Server Communication volume when obtaining and operating records. in addition, the display method reduces the performance of the form, because the display method is called when the form control is refreshed when the form application is running, the display method bound to a server can cause a large number of client/server calls. Especially if the display method is displayed in the grid, multiple return values from the display method are used at the same time. you can cache the value of the dispaly method by calling the cacheaddmethod method of the formdatasource object. these return values are cached when the form application is running and refreshed only when the record is modified or re-read.