Bug Report T581043
Visible to All Users

Win - It takes significant time to show a DetailView with a large number of editors

created 7 years ago (modified 7 years ago)
Show previous comments (4)

    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.

      DevExpress Support Team 7 years ago

        Hello José Enrique,

        Thank you for sharing your findings. However, the cause of the performance issue with DetailViews in a Win application is different than in a Web one. I've created a separate ticket on your behalf to discuss the issue you described: T595701: Web DetailView performance is slow because of the excessive amount of IO operations. I will reply in that ticket shortly.

        Answers approved by DevExpress Support

        created 7 years ago

        We have fixed the issue described in this ticket and will include the fix in our next maintenance update. To apply this solution before the official update, request a hotfix by clicking the corresponding link for product versions you require.

        Note: Hotfixes may be unavailable for beta versions and updates that are about to be released.

          Show previous comments (4)
          M M
          Martin Praxmarer - DevExpress MVP 7 years ago

            Thanks Dan - now please hit the red button ;)

            M M
            Martin Praxmarer - DevExpress MVP 7 years ago

              thx for the fix Dan - as we are currently rolling out our next release positive feedback is coming now from users and also from internal testing! So Looks perfect - while there is still one Situation where Performance could be better. Dennise should know the situation - it happens when the detailview contains 3 or 4 nested listviews - this configuration is the slowest of all our tests. would be great if this could also optimized as that would be the last area where it lacks performance.

              thx
              Noxe

              DevExpress Support Team 7 years ago

                I'm happy to hear about these results in a real world application and thank you for informing us about the next slowest scenario.
                We will see how to improve this situation, though I cannot promise any time frame. Nevertheless, thank you for your feedback. I greatly appreciate your cooperation.

                Disclaimer: The information provided on DevExpress.com and affiliated web properties (including the DevExpress Support Center) is provided "as is" without warranty of any kind. Developer Express Inc disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.

                Confidential Information: Developer Express Inc does not wish to receive, will not act to procure, nor will it solicit, confidential or proprietary materials and information from you through the DevExpress Support Center or its web properties. Any and all materials or information divulged during chats, email communications, online discussions, Support Center tickets, or made available to Developer Express Inc in any manner will be deemed NOT to be confidential by Developer Express Inc. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.