Lasttest für Webserver

Klick dir weitere Instanzen beim Cloudanbieter, wirf da Software zum Last erzeugen drauf und lass die auf deinen Windows Webserver los.
 
Weiß dein "Cloud"-Anbieter was du da vor hast? Denn auch wenn es für deine Arbeit ist, bleibt es ein vorsätzlicher "Angriff" auf die Infrastruktur des Anbieters.

Zu deinem Lasttest: Ist die Webseite, die der IIS ausliefern soll statisch oder dynamisch? Wie groß ist die Seite? Woher weißt du, dass dein Cloud-Anbieter nicht irgendeine Art von Loadbalancer oder CDN zwischen dir und deinem Server hat? Was verschafft dir Gewissheit, dass zuerst der Webserver in die Knie geht und nicht vorher schon der Netzwerk-Stack des OS? Wie stellst du sicher, dass das Netzwerk nicht der Flaschenhals ist? (Daher am besten Tests direkt aus dem selben Netz)
Wie misst du die Performance des Servers während der Tests? (Letzteres mehr aus Neugierde^^)

Ansonsten wenige Minuten $Suchmaschine und du findest z.B: direkt diese Liste von Stresstesting Tools: https://stackoverflow.com/questions/5139953/web-server-load-testing-tool oder nimmst das hier: https://www.de.paessler.com/tools/webstress oder hier http://www.devcurry.com/2010/07/10-free-tools-to-loadstress-test-your.html oder du nimmst https://de.wikipedia.org/wiki/Low_Orbit_Ion_Cannon und feuerst nur mit HTTP-Requests.
 
Steht idR in den AGB was erlaubt ist und was nicht... ;)

Loadbalancer/CDN:
Okay, ich muss hier glaube ich differenzieren: Sofern du (multiple) Server hast, kannst du natürlich für deine Systeme Loadbalancing hinzu buchen. Trotzdem läuft dein gemieteter Server ja auf deren Infrastruktur und damit das alles so schön einfach klickibunti und dynamisch und flexibel ist hat jeder größere Anbieter für seine zugrunde liegende Infrastruktur Loadbalancer oder CDNs davor. Einfaches Beispiel: Hätten sie dies nicht und du wärst mit deinem "Angriff" erfolgreich so könntest du u.U. weitere VMs auf dem Host ausbremsen und damit ungewollt andere Kunden schädigen. Damit dies nicht passiert werden Zugriffe bereits vorher limitiert. Selbst wenn aus dem Internet heraus also dein Server nicht mehr erreichbar ist oder reagiert, so bedeutet dies nicht zwangsläufig, dass du den Server an sich abgeschossen hast sondern dies kann auch bedeuten, dass schon vorher deine Verbindungen gekappt wurden.
Ob und in welchem Umfang dies dein Hoster macht wird aber nur dieser dir sagen können.

Was geht zuerst in die Knie:
Dann tut es mir Leid aber damit ist dein Projekt fast hinfällig, da du ja eben nicht mehr nur Webserver miteinander vergleichst sondern eben OS + Webserver. Win + IIS auf der einen Seite und z.B. $Linux + Apache2 oder $Linux + nginx auf der anderen. Oder $Linux + lighttpd oder ein $BSD und dort einen Webserver. Du müsstest also unterschiedliche Kombinationen durchtesten allein Win Server 2008 R2, 2012 R2 und 2016. Optional noch die jeweiligen Core-Varianten davon. Gleiches beim Linux. Zumindest die gängigen Serverdistributionen würde ich vergleichen ob sich dort Unterschiede ergeben. In dem Fall musst du natürlich die Config möglichst schlank und klein und vor allem identisch halten.

Ebenso gehst du davon aus, dass es keinerlei Optimierungen gibt, die so üblich sind. Dazu gehört u.a. so klassische Dinge wie eben: Wenn zu viele Zugriffe von einer bestimmten IP kommen, so drossel die Zugriffe von dieser IP damit andere User den Webserver noch erreichen können. Oder ich installiere selten einen dicken fetten Server sondern lieber mehrere kleine/mittlere Systeme und einen nginx als reinen Loadbalancer davor. Selbst wenn du dann einen Angriff auf $domain startest schickt dich der nginx zu einem meiner Webserver. Irgendwann steigt der ggf. aus und er scheint für dich down, für andere User, die vom nginx woanders hin verwiesen werden, ist alles erreichbar.

Performance-Messung:
Heartbeat kannst zwar machen aber wie bereits weiter oben beschrieben ist das nicht praxistauglich. Heartbeat kannst vom Loadbalancer aus machen um zu gucken ob deine Systeme im Lastverbund noch da sind oder eben nicht um dann Anfragen ggf. umzuleiten.
Ich würde ein Monitoring auch nie auf dem selben "Weg" betreiben wie die Nutzeranfragen kommen sondern diese Performancedaten "nach hinten weg" abziehen und auswerten. Dafür gibts div. Monitoring Tools die dir diese Werte auslesen und auch gleich aufbereiten können. Icinga2, Zabbix, check_mk, PRTG, usw. usf. oder mal Google mit "$name_webserver performance monitoring" füttern.

Stresstests:
Der einzige, der da mit dem Hacker-Paragraf kommt wird dein Hostinganbieter sein. Wenn es dir deine private Fritzbox mit $Tool bereits zerlegt und du dies aber im Rahmen einer "wissenschaftlichen Arbeit" machen sollst: Dann starte die Tests doch vom Anschluss des Auftraggebers. Der wird wohl einen besseren Anschluss und Equipment haben um dies umzusetzen.

Ich bleibe aber dabei, dass das Projekt viel zu schwammig definiert ist oder den Rahmen sprengen wird. Du untersuchst ja offensichtlich nicht einmal den Aspekt bzw die Performance eines Webservers bei vielen parallelen Zugriffen sondern nur bei vielen Zugriffen von einem User sowie die vielen unbekannten Variablen wie z.B. (für dich unsichtbares) Loadbalancing/Traffic Throttling durch den Anbieter, Vergleich von verschiedenen Betriebssystemen usw. usf. Wenn du wenigstens da eine gleiche Basis nehmen würdest aber so testest du ein IIS auf irgendeinem Windows, einen Apache2 auf einem $Linux ohne zu untersuchen ob ggf. ein Red Hat sich besser schlägt als ein Ubuntu.
 
Zurück
Oben