[DevExpress Support Team: CLONED FROM T581043: Win - It takes significant time to show a DetailView with a large number of editors]
Hello, I would like to share my experience with this, hoping this could help. This is really a headache, I'm in the same situation and with web application, complex detail opening performance is a little bit worse. I have improved it (few milliseconds) splitting details into 2 or 3 variants and adding an image to the variants ChoiceAction (still not very UX but better than only a caption), but is not enough. The web application runs in a very fast CPU Cloud server with at least 2000IOPS disk, and access to complex detail takes CPU up to 40-50% (not so bad) and 100% of disk during several seconds. Navigating through tabs is also very slow.
Casually I check the same application deployed into a slower VPS server with very fast SSD disk and performance is much more better.
So I decided separate database of fast CPU cloud server into a second fast CPU server with very fast SSD disk. I was pretty sure that then it was gonna be faster than the all in one VPS slower server… but… Surprise!!! performance is still worst than the slower VPS server with SSD disk and both, application and database on the same server.
Analyzing in detail, the fast CPU server without database, still put the disk usage at 100% and CPU at 40-50% when opening complex detail view, so I have to conclude that nevermind where the database is because the real bottleneck is excessive disk operations when rendering the view, even with database in another fast server with very fast SSD disk. So the only way to improve this is using SSD disk on the application server.
Saying that, in my opinion, devexpress XAF team should focus on identifying why so much I/O operations are needed to draw the layout and how to improve it.
==========================================================================================================================
I'm not sure if I've explained correctly. My test has consisted on deploy the application using a 2 servers arquitecture:
1- First server is the application server without database: Very Fast CPU with fast 2000 IOPS disk. ConnectionString points to second server and connectivity between both server is perfect.
2- Second Server is dedicated only to Database purpose. Very Fast CPU with very fast SSD disk.
So all database operations are performed at second server. This is the preffered arquitecture and is still slower than running the application and the database (both) in a slower (but also fast CPU) VPS with SSD disk (note that VPS share CPU so equal processor is slower than dedicated Cloud), and VPS runs application faster than the above better arquitecture approach. Obviously, adding an SSD disk to first server becomes application faster than VPS but it reveals an I/O performance problem with layouts.
Hello José Enrique,
Thank you for contacting us. By default, XAF applications store all data in the database and do not use the file system to store data required to load a DetailView. If the application is configured to write messages to a Log File, temporarily disable this functionality to see if the issue is related to it. Also, make sure that the application does not store model differences in the file system. To do this, find and check the UserModelDiffsLocation option in the Web.config file (refer to the Model Difference Storages article for details).
If you see that the issue is not related to the settings described above, it will be necessary to determine which files the application uses when a user opens DetailView. You can try to determine this by running the application on the developer machine and using the Process Monitor tool to log the application activity. This information can shed some light on the issue.