sql - Optimize 0ms query (or optimizing ahead)? -


In the last phase of development, I started looking for code to find some bad behaviors. I came to know that while reaching a page, I am asking the question about the DB N times (N is the number of rows of an HTML table), to get translations (different languages) for just one record ... I Immediately thought it was bad and I tried a little adaptation.

Running SQL Profiler shows that those questions take 0 mm.

Since I'm checking these tables, they are small (20-100 records) I can get all the data I thought and can cache them in the web server RAM, later on to the LINQ object Can be retrieved by using. The execution time is also 0 this way.

I am running these tests, where the environment is a DB and web server with 0% load on the same machine. This is only using the application to me.

The question starts here because I do not have any performance differences absolutely Should I avoid that optimization? Should I keep it as a balance in the use of both DB and Web server (there will be 2 separate machines in the server production environment)?

In my opinion, this optimization can not damage the performance, it can only make something better in the heavy weighted DB case, there is something in my mind who says that if there is no need to adapt it Wrong in ...

Thank you for your opinion.

I do not think that you have actually shown that there is no performance difference.

Try to run the query one million times in every way, and how much time it takes in total ... I think you will see a big difference.

The SQL Profiler shows you only (as far as I know) it does not matter to query on the database :

  • It took time to set up the connection or prepare a query
  • Time taken in the network latency issuing queries
  • The time taken in network latency to return the results < / Li>
  • Time to convert results into useful items

Of course, adaptation is prematurely a bad thing, but it does sound like the proper change to do - if you know that the table The content will not change.


Comments