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.