A application isnt stronger then its weakest layer

When you want to increse the preformance of one of your web applications, what is the first thing you look at? For many developers, the answer is the data access. How can I write this query in a more sufficiant way, so that I can get preformance gain? In my expreiance, we tend to think that this is the part of the application that we can optimize the most.

The reality, however, is a little bit different. Sure, we need to build queries that run as fast as possible and sure, the database should be able to handle alot of traffic at the same time. But when you have a application that has a very big viewstate, or a application with alot of different .js and .css files to download each request, or why not just alot of images. Then you might think a little bit wrong when you are trying to fix that one query that should return the latest news. The fact is, that the transfer speed between a database sever and the application server is alot faster then the transfer speed between the webserver and the client that wants to view your site. After all, its just data you want to transfer between different sources in different formats.

Another thing about the data access is, that on top of it you will in many cases have a caching layer. A properly used cache can take a lot of work of from your database. For a big website with many visitors, a 5 min cache can make a huge differance. We do allso have to consider the negative effects of our "optamization". A application with the data access code written with simple ADO.NET code in the code behind file that simply outputs it to the UI will mostly preforma pretty well. But would you like to maintain it? I would not want to do that. It would take way to much time and effort just to fix a simple bug that its faster just rebuilding the whole application. No one writes bug free code, but we can atleast try and write code that makes bugs easy to fix and find. A good application, in my opinion, has a nice balance between maintainability and preformance as those two do not allways walk hand in hand. This balance is different from application to application.

I find, that in many cases, the ui is the part of the application that need to be tuned for better preformance. This can mean a simple thing like turning of the viewstate for controls that doesnt need it in a webforms application, or caching static content on the client, and using spritesn instead of serving each image individual to the client. Those are very simple changes and we have nice tools to find what needs to be done, like yslow or page speed for firefox.

There is of course times when you need to rewrite some of your data access code as well. I just think that we should find the real bottle neck, and fix that. Then move to the next one. And allso think about how much maintainability we are willing to sacrifise for a preformance gain. It all comes down to what application you are developing.

kick it on DotNetKicks.com
Shout it

Comments

Add comment

Name:

Mail:

Website:

Comment:


<< [1] >>
  • 1 years ago by Patrik

    I agree with you on some parts. However, if you have a sluggish database query then no optimization in the world on the UI will help you get a great throughput and therefore not scale well.

    As you already said, optimization needs to be done on booth ui and back-end.

    I can also recommend the web site http://www.webpagetest.org for UI testing.


    Reply | Hide replys

    • 1 years ago by Jakobsson

      Of course, if the data access is the issue at hand. Then that is where you need to do your work. The point I'm trying to make is, that we should first find out what part of the application is slowing it down. Then fix that. Not make any assumptions about what part can cause a slow response time.

      Thanks for the link. Never used it before.



      Reply

<< [1] >>