Post reply

Totally Caching a Frequent Query for Maximum Performance

  • October 5, 2009 at 10:49 am

    #211850

    Hi All,

    I've been using T-SQL for several months now, but sometimes I still feel like a newbie. I created a stored procedure which downloads about 1,500 rows worth of data across about 8 columns that are in about 5 tables. The results are the same every time it is called as no variables are used. Only a few times a day are the tables updated. On first run, the query takes about

    I created a C# method that calls this query on every page of my Web site and it pretty much brings the SQL server down. How do I make this procedure really cache for several hours so it just spits out the results rather than redoing the expensive table joins and such?

    Here are the stats from a first run:

    SQL Server parse and compile time:

    CPU time = 0 ms, elapsed time = 1 ms.

    SQL Server parse and compile time:

    CPU time = 109 ms, elapsed time = 117 ms.

    (1125 row(s) affected)

    SQL Server Execution Times:

    CPU time = 62 ms, elapsed time = 2804 ms.

    SQL Server Execution Times:

    CPU time = 171 ms, elapsed time = 2920 ms.

  • October 5, 2009 at 10:55 am

    #1061881

    Hi,

    I am not aware of a technique to completely cache the results of a query. Here's what I suggest you though:

    1. Post the query with the DDL of the tables, we might be able to improve the query a lot, and that would fix your problem.

    2. You can "cache" the results of this query from your web application, using a in memory dataset that you can reuse for a given period of time, it will require some C# coding, but you can do it. In our system, we "cache" the translations of every field in the screens/database/error messages we want to show up to the user in a dataset, that is accessed from the application directly, from every windows screen.

    Nevertheless I think you should really post the DDL of the tables and your complete query, we will be able to tweak it, than you can start from this, and see if it's quickly enough for you.

    Hope that helps,

    Cheers,

    J-F

  • October 5, 2009 at 11:12 am

    #1061887

    Caching is something you need to do on the client, SQL doesn't have the capabilities of caching a query's result (unless you go and stick the result into a table)

    If you want some help optimising the query so that it doesn't bring the SQL instance down, please post the query, table definitions, index definitions and execution plan, as per http://www.sqlservercentral.com/articles/SQLServerCentral/66909/

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass

  • October 5, 2009 at 4:25 pm

    #1062030

    It may also be a good idea to re-evaluate the need to return that number of rows to a webpage in one hit.

  • October 5, 2009 at 9:57 pm

    #1062082

    Hmm, you might get better results from an Indexed View.

    [font="Times New Roman"]-- RBarryYoung[/font], [font="Times New Roman"] (302)375-0451[/font] blog: MovingSQL.com, Twitter: @RBarryYoung[font="Arial Black"]
    Proactive Performance Solutions, Inc.     [/font]    [font="Verdana"] "Performance is our middle name."[/font]

  • October 5, 2009 at 10:01 pm

    #1062084

    Post the query.

    --Jeff Moden

    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

Viewing 6 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic. Login to reply