Heavy use of XML and controls cause slow web application.

Today I was called to help web application that failed to pass sniffer test (pass too much bytes on network) and performance test. After discuss the system with the team leader that manages the development I found to major problems:

1)      They use XML heavily. They use DAL classes to load data from DB, convert it into XML format, save it in session object and update the XML data by user actions.

2)      For performance reason (that what they thought) they load one page with lot of controls. They have page with 3 tabs (every tab contain about 50 controls) and they want to load all controls and play with controls visibility to gain performance.

3)      COM+ has been used in high isolation level to separate application domain logic from web application. But they call application domain logic for domain logic class’s properties directly from page.

 

First of all we change XML uses to Domain classes holding and managing controls data. This change prevents many string manipulation/casting and improves performance slightly. Then we add façade to domain model classes and change page calls to go through domain model façade. Adding the façade really improve performance. In the end we change the page to use “lazy load” and to load tab controls just when certain tab clicked by the user. Using lazy load we decrease the amount of bytes transferred when the user asked for a page.

 

Now they’re running profiler (Ants) in order to find other problems in the system.

2 Comments

  • Hi Natty,



    Could you post a link that explains a little bit more about #3? I don't understand the concept of seperating "application domain logic" from the web application. I understand isolation levels (the higher the level the more stable the environment is but that stability uses more system resources). I'm lost on storing code at different levels and the performance hits calling that code.



    Thanks very much.



    Chris

  • First of all you right separation of code to other process has bad impact on performance. This technique that I mention is pretty simple. While using IIS 5 all web applications are running under single aspnet_wp process therefore crash might infect other application. Even though every application is running in their own application domain, reality shows that the entire aspnet_wp process might crash when errors happened in certain web domain logic (mainly for using legacy COM code). To work around this behavior you can run application domain logic under dedicate process by using COM+. The technique is simply creating domain logic façade and registers it as COM+ server.



    I don’t think this is the right solution for every situation. It depends on your enterprise demands. The enterprise that I mentioned runs about 100 mission critical web applications on one server (in a matter of fact cluster of 4 servers). Their top priorities are availability and server consolidation so they willing to pay performance penalty.

Comments have been disabled for this content.