[XAF] How to improve the application's performance

【自己的解决方案】数据量大时，可显著提升用户使用体验!

1.Root ListView 参考官方的E1554

   点击导航菜单后首先跳出查询条件设置窗体进行设置

   可设置查询方案或查询方案的查询条件，排序字段、排序方向，是否只查询前1000条。

    

2.LookupListView 可设置 TopReturnedObjects = 600

3.Code:http://pan.baidu.com/s/1o8MVKkq  密码：qfmv
   

[官方方案]

https://www.devexpress.com/Support/Center/Question/Details/T148978

The best way to determine the precise cause of a performance problem is to profile your application using a specialized performance profiler tool, e.g., AQTime, ANTS Performance Profiler (if you are developing a Web app, then additionally profile the client side operation using the developer tools of your favorite browser (IE, Chrome)).
Such tools show what methods take the most time to execute, and in conjunction with queries profiling, this allows debugging practically all performance issues.
If there are issues with memory consumption in your application, follow the suggestions from our About profiling memory leaks blog post.

In addition, check this list of the most frequent causes of performance issues and make sure that you are following all the advice from this list in your application.

General issues:

1. The application or a certain View is loaded slowly for the first time, but subsequent loads are performed significantly faster.

Solution: The majority of this time is likely required to load additional assemblies or compile MSIL code. When the issue occurs in a certain View, this View likely uses a control that is not used by other Views, e.g., SchedulerControl, XtraReport. To improve performance in this case, use NGEN. Refer to the Why does my code take longer to execute the first time it's run? article for additional information.

2. A View is painted slowly, and the application freezes when it is necessary to redraw this View.

Solution: Check whether any exceptions are thrown when the View is displayed. Even if these exceptions are handled and do not break the application's execution, a lot of exceptions may cause noticeable freezes, especially during debugging. An example of such a situation is when there is a mistake in the column's display format definition. In this case, a FormatException will be thrown for each cell. To see these exceptions, enable Common Language Runtime Exceptions and disable the Just My Code option in Visual Studio. See How to: Break When an Exception is Thrown for more details.

3. The ListVIew is loaded slowly when the database table contains a lot of records (e.g., more than 100,000).

Solution 1: If you do not need to show all these records in a single View, apply a server-side filter to your ListView - see Filter List Views.

Solution 2: Enable partial data loading - Server Mode - to load records dynamically when the ListView’s control requests them. To do this, open the Model Editor, find the ListView model in the Views node and set its DataAccessMode to Server.

Issues caused by your persistent classes' specifics:

To debug such issues, check what queries are performed while loading data from the database. Here are ways to do this:

 - Using an SQL profiling tool. You can either use a third-party tool like SQL Server Profiler, or, if you are using XPO for your data layer, you can use the XPO Profiler.

 - If you are using XPO, you can enable the queries logging. To do this, open the application's configuration file and uncomment the XPO diagnostics switch:

[XML]Open in popup window

<system.diagnostics>
  <switches>
    <!-- Use the one of predefined values: 0-Off, 1-Errors, 2-Warnings, 3-Info, 4-Verbose. The default value is 3. -->
    <add name="eXpressAppFramework" value="3" />
    <add name="XPO" value="3" />
  </switches>
</system.diagnostics>

Queries will be displayed in the Output window and written to the eXpressAppFramework.log file (see Log Files).

After configuring one of these approaches, load the problematic ListView and check the logged queries. If their summary execution time takes the majority of the ListView's loading time, query optimization is required. Here are the most frequent cases:

4. Server-side filtering, sorting or grouping is performed slowly because the database table does not contain the necessary indices.

Solution: Check what columns are involved in the WHERE, ORDER BY and GROUP BY operations and add indices for them. To add an index using XPO, use the Indexed attribute.

5. The main SELECT query takes a long time to execute, although the result does not contain a lot of objects. This may occur if each persistent object selected by this query includes a lot of data, i.e., contains images, long texts, references to large persistent objects, etc.

Solution1: Set the ListView's DataAccessMode to DataView to load only properties displayed in this ListView (be default, all properties are loaded).

Solution2: Make large properties delayed, as described in the Delayed Loading topic. Note that delayed properties should not be displayed in the ListView, otherwise you will have case 7.1 (see below). If you need to display large reference properties in the ListView, use the solution from case 6.

6. A persistent class contains a lot of reference properties, and additional queries that load referenced objects are executed for a significant time.
Solution: Include referenced objects to the main SELECT query by applying the ExplicitLoading attribute to the corresponding properties.

Note that normally, all referenced objects of the same type are loaded through a single additional query for all records. If additional queries are performed for each record, see case 7.

7. XPO or Entity Framework executes a separate query or several queries for each record.

Solution: See what additional queries are executed and analyze your business class to understand what code causes this. Here are examples of such cases:

7.1. Additional queries load a property of the current business class that is not loaded in the main SELECT query.

Solution: This property is likely delayed, and there is a ListView column that displays it. In this case, either do not use delayed loading for this property, or remove the ListView column (see Change Field Layout and Visibility in a List View). The same issue will occur if the delayed property is accessed in code while loading objects, e.g., in another property's getter, or in the OnLoaded method.

7.2. Additional queries select data from other tables.

Solution 1: Check whether your persistent class executes the code that loads other persistent objects (e.g., creates an XPCollection or uses a Session's methods like Session.FindObject and Session.GetObjectByKey) in property getters or in the OnLoaded method. In this case, either call this method in another place, e.g., in a getter of a property that is not displayed in the ListView, or remove the problematic property from the ListView.

Solution 2: Check whether there are calculated properties implemented through the PersistentAlias attribute that use collection properties or join operands in their expression, e.g., "Orders.Sum(Amount)". It is important to remember that to get values of calculated properties, the getter that calls the EvaluateAlias method is called, and the EvaluateAlias method evaluates the specified expression on the client side. So, if the PersistentAlias expression contains a collection property, this collection will be loaded when calculating the value. The easiest way to resolve this issue is to hide such properties from the ListView. Alternatively, you can improve the performance of these properties by pre-fetching associated collections using the Session.PreFetch method. In this case, all associated objects will be loaded in a single query. See an example here: How do I prefetch related details data to increase performance for calculated fields.

Solution 3:  Change the ListView's DataAccessMode to DataView. In this case, queries that can be executed on the server side (PersistentAlias expressions) will be included to the main SELECT query, and client-side code that loads data will not be taken into account.

8. The applications periodically perform the same queries that return the same database records.

Solution: If these records are changed rarely, it makes sense to enable caching at the Data Layer level to prevent the duplicate requests, as described in the How to use XPO caching in XAF topic.


IMPORTANT NOTES
This list does not cover all possible cases. There are issues related to a specific database provider or caused by specifics of a legacy database,  scenario-specific issues, etc. A general suggestion is to find out how the query or the database table can be modified to improve performance, and then try to modify your persistent objects accordingly.

If none of these suggestions are helpful, feel free to contact our Support Team and provide the profiling logs for analysis.