none
Queries zwischenspeichern - automatisch? RRS feed

  • Allgemeine Diskussion

  • Ich bin derzeit dabei, Möglichkeiten zu suchen um die Performance einer Applikation zu verbessern.

    Es gibt allerdings einige Einschränkungen:

    1. An den Queries kann nichts geändert werden

    2. An der Applikation selbst kann nichts geändert werden

    Die Benutzer beklagen sich über eine schlechte Performance, sobald sie Daten von der Applikation abfragen...und ja, für 1000 Werte warten die eine Minute. Sql Profiler liefert mir haarsträubendes zu Tage: Erst kommen hundertfache Joins. Dann wird alles in eine Temptabelle geschrieben. Von da weitere Joins...irgendwann wird das Ergebnis zurückgegeben. In meinen Augen ziemlich viel unnötig, aber wir haben keinen Einfluss in den Source. Nun ist es so, dass diese 1000 Daten immer wieder abgefragt werden, ohne dass es Updates dazwischen gibt. Und jedesmal wird der ganze Aufbau neu gemacht...gibt es irgendwie eine intelligente Schicht zwischen Applikation und SQL, die genau dies verhindert? Kenne mich applikatorisch bei SQL nicht wirklich aus. Aber es sollte doch möglich sein, dass wiederkehrende Queries nicht alles neu aufbauen sondern auf cache Ergebnisse zugreiffen..?

    Donnerstag, 4. Oktober 2012 10:10

Alle Antworten

  • Hallo Kamban,

    IMHO leider NEIN!
    Die von Dir beschriebenen Probleme kenne ich auch aus der täglichen Arbeit.

    Sobald es sich um eine "Vendor-Applikation" handelt, hast Du selbst "kaum" Möglichkeiten, etwas zu machen ohne die Gewährleistungen zu verlieren.
    Leider reden sich sehr viele Vendoren gerade damit immer wieder heraus und verbergen so ihre eigenen Unfähigkeiten :(

    Was kannst Du konkret machen?

    Die einzige Möglichkeit, die Dir selbst zur Verfügung steht, ist das technische Umfeld Deiner Datenbanken zu optimieren:

    - Überprüfung, ob Indexe fragmentiert sind!
    - Statistiken veraltet?
    - wie schnell ist das IO-Subsystem?
    - kann man durch Parallelisierung Performance steigern
    - mehr RAM, um mehr Daten im Speicher zu halten ("logical reads vs. physikal reads")

    Das sind eine ganze Menge Optionen, die Dir zur Verfügung stehen - ich bin sicher, daß sich das eine oder andere Prozentchen dabei herausholen läßt.
    Aber wenn eine Applikation scheixxe programmier ist, kannst Du daraus leider auch keinen Goldtaler machen ;)


    Uwe Ricken

    MCITP Database Administrator 2005
    MCITP Database Administrator 2008
    MCITP Microsoft SQL Server 2008, Database Development

    db Berater GmbH
    http://www-db-berater.de

    Donnerstag, 4. Oktober 2012 10:21
  • Hi,

    wenn Du keinerlei Möglichkeit hast, die Abfragen zu ändern, wird man da nur bedingt was machen können.

    Man sollte sich auf jeden Fall mal die Ausführungspläne anschauen und darüber prüfen, ob es Optimierungsmöglichkeiten in Form von Indizes, ... gibt.

    "Hundertfache Joins" klingt für mich nach einem haarsträubenden Datenbankdesign und/oder Abfrageaufbau.

    Man kann natürlich versuchen, die Daten, die von der Abfrage zusammengetragen werden, in eine Tabelle zu überführen und die Applikation so umschreiben, dass sie nicht direkt die Abfragen aufruft, sondern neue Abfragen, die auf diese neue(n) Tabelle(n) zugreifen. Aber dafür müsstest Du die Anwendung anpassen können.


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET
    http://www.asp-solutions.de/ - Consulting, Development
    http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community


    Donnerstag, 4. Oktober 2012 10:23
    Moderator
  • Hallo,

    wenn Du keinen Einfluß auf die Applikation hast, sieht es eher schlecht aus.

    Natürlich cached der SQL Server häufig abgefragte Daten, aber irgendwann ist nun mal der Cachespeicher voll und alte Daten fliegen wieder raus.

    Du könntest Dir die Ausführungspläne der Abfragen ansehen, ob da vorhandene Indizes genutzt werden und falls nicht, könntest Du passende anlegen, um die Abfragen zu beschleunigen. Das hilft aber nur für die Initialen Abfragen gehen. Ob die temporären Tabellen im weiteren indiziert werden (falls nötig), hängt wieder von der Applikation ab.

    Am besten tritts Du mal dem Hersteller auf die Füße, das er da mal nachbessert.


    Olaf Helper

    Blog Xing

    Donnerstag, 4. Oktober 2012 10:24
  • Hallo Stefan,
    hallo Olaf,

    aus eigener - leidlichen - Erfahrung möchte ich dringend davon abraten, eigene Indexes zu setzen.
    Das reicht in der Regel schon aus, dem Vendor das Leben leicht zu machen!

    Damit greift der TE in die Strukturen des Systems ein und der Vendor kann jegliche Gewährleistung verweigern.
    Leider schon selbst erlebt :(

    Ein Index gesetzt - Performance war gut.
    Sideeffect - andere Abfragen wurde dramatisch langsamer und wir hatten erhebliche Timeout-Fehler in der Applikation.

    Der Vendor hat sich klar distanziert und ist rechtlich damit auch auf der sicheren Seite.
    Nachdem wir den Index wieder gelöscht haben, waren auch die Timeouts verschwunden ...

    Meiner Meinung nach kann man nur über Maintenance (Index-Defrag, Statistic Updates, ...) und Hardware (RAM / IO-Subsystem / ...) eine Steigerung erreichen.

    Ein weiterer Engpaß ist IMHO die tempdb. Auch hier kann ohne Probleme verbessert werden, da ich vermute, daß ORDER BY / GROUP BY / ... verwendet wird.

    @kamban,

    Wie sieht denn das Layout der TEMPDB auf dem Server aus?

    - wieviele Files?
    - wie groß sind die Files (initial)?
    - liegt die TEMPDB auf einer dedizierten HDD (unabhängig von Benutzerdatenbanken!)


    Uwe Ricken

    MCITP Database Administrator 2005
    MCITP Database Administrator 2008
    MCITP Microsoft SQL Server 2008, Database Development

    db Berater GmbH
    http://www-db-berater.de

    Donnerstag, 4. Oktober 2012 10:42
  • Hallo alle zusammen,

    Viele Dank für eure Antworten! Auch wenn es leider nicht rosig aussieht...

    Eigene Indexes etc. sind aus oberen geschilderten Gründen leider tabu. Die anderen erwähnten Dinge bin ich nebenher am testen, derzeit leider mit wenig Erfolg.

    Grüsse

    Donnerstag, 11. Oktober 2012 12:48
  • Bei der Tempdb sollte man auch über eine SSD nachdenken..
    Donnerstag, 11. Oktober 2012 12:51