christophorus 11 Geschrieben 16. Dezember 2011 Melden Teilen Geschrieben 16. Dezember 2011 Hallo zusammen, ich habe eine kurze Frage und hoffe jemand kann mir hierbei weiterhelfen. Wir haben eine WebAPP die auf .NET sowie einer SQLDB basiert. Mit steigender Benutzerzahl, bricht die Performance der WebAPP regelrecht ein. Als Quelle kann ich definitiv alles ausschließen bis auf die IIS Konfiguration der WebAPP denn: Wir haben einen zweiten Katalog angelegt auf dem gleichen ISS mit der identischen Konfiguration des ersten Katalogs (gleicher DB, gleicher physikalischer Pfad, etc.). Wenn ich nun über diesen Katalog arbeite läuft die APP einwandfrei. Da ich hier auf dem gleichen Server und dem gleichen physikalischem Pfad arbeite, kann ich Hardwareprobleme eigentlich aussschließen. Da ich mich mit der gleichen SQLDB verbinde, kommt der SQL Server hier auch nicht in Frage. Es sieht so aus, als würde der IIS Katalog bei einer gewissen Benutzeranzahl einfach einbrechen. Kann mir nur vorstellen dass ich hier an der ein oder anderen IIS Schraube drehen muss? Die Tests wurden natürlich endliche male wiederholt um den Faktor "zeitliche Auslastung" auszuschließen. Danke und Gruß Chris Zitieren Link zu diesem Kommentar
jose 10 Geschrieben 17. Dezember 2011 Melden Teilen Geschrieben 17. Dezember 2011 Hallo christophorus, wie sieht die Speicherauslastung des Worker Process im Fehlerfall aus? Ich würde an Deiner Stelle zunächst darauf ein Auge werfen. Bei fehlerbehafteten Applikationen schafft das Recyceln im IIS u.U. Abhilfe... Technet: Configure Application Pool Recycling Zitieren Link zu diesem Kommentar
christophorus 11 Geschrieben 19. Dezember 2011 Autor Melden Teilen Geschrieben 19. Dezember 2011 Hi Jose. Eigentlich ist die Speicherauslastung des Worker Processes relativ gering (liegt bei ca. 3GB) Der Server verfügt über 60GB RAM. Bin Momentan etwas ratlos muss ich sagen vorallem weil das Web auch nichts hergibt zu dem Thema. Werde vorübergehen die Last auf mehrere Kataloge verteilen je nach Herkunft des Benutzers. Ist natürlich nicht unbedingt des Rätsels Lösung aber ein Performanceeinbruch um 75% verlangt wohl nach etwas unkonvertionellen Schritten. Den Worker Process zurück zu setzen wäre mit dem Verlust der SeassionID verbunden und alle User müssten sich erneut Einloggen. Kommt also auch nicht wirklich in Frage für den Live-Betrieb. Gruß Chris Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.