none
Webservice Antwortrate verschlechtert sich mit der Anzahl und Dauer der Aufrufe RRS feed

  • Frage

  • Hallo, vielleicht kann mir hier jemand diese Frage beantworten, habe einen Loadtest geschrieben der aufgeteilt auf mehrere Threads von einer IP Adresse ununterbrochen in einer Schleife die selben Webservice Methoden auf einem Webserver in der selben Domaine in unserem Netzwerk aufruft, einer der Webservice Methoden z.bsp. selbst schreibt jedesmal einen einzelnen Datensatz in eine Sql Tabelle und liest max. 2 Datensätze aus der selben Datenbank (dazu wird jedesmal eine connection aus dem Connection Pool benötigt). Folgendes habe ich beobachtet: Am Anfang werden die Aufrufe mit einer hohen Rate beantwortet, aber je länger die Methoden aufgerufen werden, desto schlechter ist die Antwortrate die ich am Client beobachte, d.h. . Das geschieht alles noch in einer Phase wo die Sql Zugriffe selbst mit einer konstanten Zeit beantwortet werden, sprich, die Verschlechterung des throughputs wird nicht durch eine zurückgehende Performance am Sql Server aufgrund eines Anwachsens der Daten in den Tabellen verursacht, zumindest nicht zu Beginn noch mit weniger als ein paar hunderttausend Datensätzen in diese Tabelle. Wenn ich den Load Test Prozess terminiere und ihn später wieder starte beginnt das ganze wieder von Vorne, mit hoher Rate zu Beginn und schlechter werdender Rate mit Fortdauer des Beschusses durch meinen Load Test Client. Am Clientprozess selbst kann ich keine Auffälligkeiten bemerken, die CPU Auslastung am WEb Server ist auch eher gering, in etwa unter 10 %, auch am Sql Server. Jedenfalls auf mich wirkt es so, als ob der IIS Server selbst die Antwortrate von Aufrufen von der selben IP Adresse drosselt, so als ob er DOS Attacken abwehren wollte, weil ich ja auch nicht mehr als 10 Threads am Client starte, d.h. max. 10 parallele Webservice Aufrufe zu einer Zeit und es daher auch kaum an der Netzwerkauslastung liegen kann, außerdem ist die ja während der ganzen Ausführungszeit konstant, sprich eine Überlastung müsste schon zu Beginn spürbar sein. Hab auch schon ein wenig in den processModel Einstellungen im machine.config herumgestellt, d.h. MaxWorkerThreads, MaxIOThreads Werte erhöht usw. ohne Auswirkung. Beobachtet hab ich das Phänomen sowohl unter IIS6 als IIS7 auf einem 64 Bit System. Das Load Test Szenario ist aber durchaus realistisch, weil auch im Livebetrieb unsere Webservices in manchen Installationen  immer von ein und dem selben externen Server aufgerufen werden. Vielleicht kenn hier jemand das Problem, bzw. kennt einen Schalter oder IIS Setting mit dem man ein solches Verhalten abschalten könnte??

    danke im voraus

    Montag, 6. Dezember 2010 16:31

Alle Antworten

  • Hallo Hannes,

    vorab: Es wäre wirklich sehr hilfreich, wenn Du dein Posting etwas strukturieren könntest. Ein paar Absätze hätten dem Lesefluss sehr gut getan.

    Zum Problem selbst: Welches OS verwendest Du?

    Wenn das Problem auf unterschiedlichsten Servern , also bspw. auch Windows Server 2008 auftritt, liegt es wahrscheinlich an eurer Anwendung und nicht am IIS. Natürlich wird mit wachsender Anzahl an Requests die Abarbeitung langsamer, allerdings kommt es auch genau darauf an, was ihr da im Code macht.

    Grundsätzlich wüsste ich im IIS erstmal nicht (schon gar nicht bei Windows Server 2003/IIS 6), was da drosseln sollte. Ihr solltet serverseitig in der Anwendung mal die Antwortzeiten (also genauer Timestamp des Requesteingangs und des Sendes der Antwort) protokollieren.

    Falls die Anwendung im Debugmode kompiliert wurde bzw. in der web.config ggfs. debug="true" steht, ist das schlecht, das müsst ihr ändern.

     


    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
    Montag, 6. Dezember 2010 20:24
    Moderator
  • Danke Stefan,

    hab leider bei den vielen Infos vergessen zu erwähnen, dass ich Timestamps, unseren Webserviceaufruf hab ich mit Zählern ausgestattet und die Ausführdauer unseres Codes bleibt anfangs konstant, ich messe immer so zw. 15 und 30 Millisekunden in dem Webservice der einen Usersatz (mit grade mal 5 Spalten) in einer Tabelle einfügt, die wird zwar mit der Dauer länger, aber wie ich bereits erwähnt habe erst so ab ca. 500 000 Datensätzen in der Tabelle und die sind erklärbar weil ja ab dem Zeitpunkt die Sql Aufrufe auch länger dauern, das hab ich natürlich auch mitgemessen, jeden einzelenen Sql Aufruf!!!

    Getestet haben wir jetzt einmal hauptsächlich am 2008 Server mit IIS7, ich zähle am Beginn so etwa 15 Webserviceaufrufe pro Sekunde und nach ca. 300 mal 10 Aufrufen, bin ich gerade nur mehr bei 2 Aufrufen pro Sekunde, das Produktmanagement hat bei einem ähnlichen Test gestern ein ähnliches Phänomen festgestellt, nachdem ein Prozess für längere Zeit blockiert war bzw. pausiert hatte(kenne den Test nicht in allen Einzelheiten), wurde nachdem er wieder lief genau auf diesem einen Prozess eine wieder viel bessere Performance festgestellt, allerdings getestet unter 2003/IIS6, bei diesem Test wurde dieses Phänomen allerdings nur am Client gemessen/beobachtet.

    Die Auführzeit unserer business logic hab ich nur bei meinen Tests mitgemessen und wenn ich nicht im Code unseres Webservices selbst immer die selbe, kurze Ausführungszeit festgestellt hätte, wär mir natürlich gar nicht in den Sinn gekommen über eine mögliche Drosselung irgendwo zw. Stack und Aufruf unseres Codes zu denken!!???

    Wir haben so zum Test einmal von verschiedenen Rechnern (IP.s) den selben Load Test gleichzeitig ausgeführt, hier lief der Test jeweils nur in einem Thread, auch hier haben wir festgestellt dass an manchen Rechnern die Aufrufrate (verwenden übrigens synchrone) stärker an anderen weniger stark zurückging, am meisten wurde der Load Prozess gedrosselt (immer das selbe Compilat das jeweils die selben Webservices aufruft) der lokal lief und nicht wie die anderen auf externen IP's gestartet wurde, und zwar doppelt bis dreifach so stark, für mich ein eindeutiges Indiz dass hier geregelt wird, nur ist halt die Frage in welcher Schicht bzw. durch welchen Fehler wenn es nicht beabsichtigt ist???

    ah, ja, kompiliert wird eine Release Version und debug im client.config stellen wir beim deployen auf false, das hab ich nochmal überprüft, beim Kompilieren durch den ASP.Net Compiler ist dieser Schalter allerdings noch auf true.

     

    Dienstag, 7. Dezember 2010 08:10