Wie testen Sie, ob ein bestimmter Überlastungsalgorithmus für Sie funktioniert? Ich frage, weil ich für die meisten Algorithmen nicht so einfach eine repräsentative Arbeitslast nachbilden kann.
Ich schaue mir derzeit zwei Dinge an, bin aber offen für weitere Vorschläge:
- Die "weitergesendeten Segmente" aus der Ausgabe von
netstat -s
Ich gehe derzeit davon aus, dass eine Überlastung in einem gewissen Prozentsatz der Fälle zu Paketverlusten führen kann. Auch wenn also möglicherweise keine 1:1-Beziehung zwischen dem Verlust eines Pakets und der Benachrichtigung des Servers über ein Überlastungsereignis besteht, kann möglicherweise doch eine lose Korrelation hergestellt werden, wenn die Umstellung auf einen Algorithmus zu weniger Paketverlusten führt.
Zeigt diese Abbildung Segmente, die aufgrund von Überlastung erneut übertragen wurden, oder ist sie auf verlustbehaftete Verbindungen beschränkt? Wenn ja (und ich denke, das könnte der Fall sein), könnte das die Sache noch komplizierter machen, sodass dies kein gutes Maß mehr ist.
- Gibt es eine Metrik zur Messung des Durchschnittsalters von TCP-Verbindungen?
Ich denke hierbei, dass TCP-Verbindungen, die früher beendet werden (ohne dass es zu einem Anstieg der Fehler und verlorenen Pakete kommt), darauf hinweisen könnten, dass die Daten mit weniger Verzögerung durchgeschickt werden.
Antwort1
Zeigt diese Abbildung Segmente, die aufgrund von Überlastung erneut übertragen wurden, oder ist sie auf verlustbehaftete Verbindungen beschränkt? Wenn ja (und ich denke, das könnte der Fall sein), könnte das die Sache noch komplizierter machen, sodass dies kein gutes Maß mehr ist.
segments retransmittedin netstat -sumfasst alle TCP-Neuübertragungen des Kernels aus beliebigem Grund, einschließlich der in Ihrer Frage aufgeführten. Diese Gründe könnten auch sein:
- Linkfehler
- Überlastung des Ethernet-Switches
- Lokaler Host wird aufgrund von QoS oder Ressourcenerschöpfung abgeschaltet
- Der Remote-Host bricht ab (möglicherweise aufgrund einer Form von QoS/Ressourcenerschöpfung auf dem Remote-Host)
Leistungstestingenieure befassen sich routinemäßig mit all diesen Variablen und stellen sicher, dass sie diese angemessen messen können. Einer der ersten Tests, die Sie durchführen sollten, besteht darin, sicherzustellen, dass die Verkabelung/das Netzwerk bei den betreffenden Paketgrößen und Verkehrsraten einwandfrei funktioniert. Dies geschieht normalerweise mit einem dedizierten Testgerät, wie beispielsweise denen von Ixia oder Spirent.
Sobald Sie die Netzwerkleistung ermittelt haben, können Sie den gewünschten Test ausführen. Auch wenn das Netzwerk einwandfrei getestet wurde, sollten Sie während des Host-TCP-Tests Switch-Schnittstellenfehler/-ausfälle überwachen, um sicherzustellen, dass Ihre Ergebnisse dadurch nicht verfälscht werden.
Was Ihre Gedanken zur Schaffung von Überlastungsbedingungen betrifft, könnte es hilfreich sein, absichtlich iperf UDP-Hintergrundverkehr knapp unterhalb der Warteschlangenschwelle der QoS-Klasse zu generieren, bevor Sie Ihren TCP-Verkehr ausführen. Wenn Sie feststellen, dass Sie die vorhandene Verbindung nicht auslasten können, könnte es auch hilfreich sein, die Netzwerkkarte auf 1 GE oder 100 M herunterzuhandeln.
Dies alles klingt möglicherweise kompliziert und in gewisser Weise ist es das vielleicht auch; mit der richtigen Konzentration und Sichtbarkeit aller Systemkomponenten sind QoS-Tests jedoch durchaus machbar.
Antwort2
Kurzfassung:
Wie @ninjalj betonte, sollte die Workload-Anwendung wahrscheinlich als maßgebliche Quelle dafür betrachtet werden, ob eine bestimmte Anpassung sich positiv auf die Workload-Leistung auswirkt. Je nachdem, ob Ihre Anforderungen Latenz oder nur den Gesamtdurchsatz des Systems betreffen, können Sie entscheiden, ob Verhaltensänderungen Ihren Leistungsanforderungen besser entsprechen.
In diesem Fall würde die Änderung vorgenommen und festgestellt werden, ob httpddie Gesamtlatenz gesunken ist.
Längere Version mit konkreten Beispielen:
Um das näher zu erläutern, werde ich dies in einen Kontext setzen. Sehen wir uns Apache an httpd. Sie können die Zeit zum Abschließen einer Anfrage in Mikrosekunden und die Größe jeder Anfrage mithilfe der LogFormat- und CustomLog-Anweisungen protokollieren. Zum Beispiel:
LogFormat "%h %m %D %b" perflog
CustomLog /var/log/httpd/performance.log perflog
Die Ausgabe sieht ungefähr so aus:
xxx.xxx.28.20 GET 41140 86
xxx.xxx.28.20 GET 34468 28
xxx.xxx.28.20 GET 47612 1434
xxx.xxx.28.20 GET 54860 868
xxx.xxx.28.20 POST 97055 6283
xxx.xxx.28.20 GET 33754 53
xxx.xxx.28.20 GET 68964 8416
xxx.xxx.28.20 GET 1143827 11528
xxx.xxx.28.20 GET 38055 61
xxx.xxx.64.208 HEAD 6255 -
xxx.xxx.28.20 GET 36922 142
xxx.xxx.28.20 GET 51871 5581
Ich werde mich nur mit GETAnfragen hierzu befassen:
root@xxxxxxvlp14 /tmp $ grep GET /var/log/httpd/performance.log > work.log
root@xxxxxxvlp14 /tmp $ sed -i 's/-$/0/g' work.log
root@xxxxxvlp14 /tmp $
(aus welchem Grund auch immer, httpdgeben wir Ihnen einen Bindestrich statt einer Ganzzahl 0 ein).
Wir können es dann programmgesteuert auseinandernehmen:
#!/bin/bash
totalRequests=$(cat /tmp/work.log | wc -l )
totalTime=$(awk 'BEGIN{ count=0 } {count = count + $3} END { print count }' /tmp/work.log)
averageTime=$( printf "%.2f" $(bc -l <<< "$totalTime / $totalRequests "))
minTime=$(sort -nk 3 work.log | head -1 | awk '{print $3}')
maxTime=$(sort -rnk 3 work.log | head -1 | awk '{print $3}')
totalBytes=$(awk 'BEGIN{ count=0 } {count = count + $4} END { print count }' /tmp/work.log)
minBytes=$(sort -nk 4 work.log | head -1 | awk '{print $4}')
maxBytes=$(sort -rnk 4 work.log | head -1 | awk '{print $4}')
echo "Total Requests In Sample: $totalRequests"
echo
echo "Total Time Taken: $totalTime ms (average: $averageTime ms)"
echo "Longest Request: $maxTime ms"
echo "Shortest Request: $minTime ms"
echo
echo "Total Data Moved: $totalBytes bytes"
echo "Largest Request: $maxBytes bytes"
echo "Smallest Request: $minBytes bytes"
Bitte keine Kommentare zum Skript, es ist auf Klarheit und nicht auf Effizienz ausgelegt. Das Obige ergibt Folgendes:
Total Requests In Sample: 207
Total Time Taken: 15138613 ms (average: 73133.40 ms)
Longest Request: 1143827 ms
Shortest Request: 1788 ms
Total Data Moved: 409825 bytes
Largest Request: 20476 bytes
Smallest Request: 0 bytes
Das Obige veranschaulicht offensichtlich, warum es wichtig ist, eine lange Stichprobe zu erhalten. Die Zahlen sind jedoch korrekt (für Neugierige: Die anderthalb Minuten lange Anfrage stammte von jemandem, der einen Bericht im Word-Format erstellte, der Bilder/Grafiken enthielt).
Sie würden Apache also dazu bringen, Ihnen eine längere Probe (wahrscheinlich über den Verlauf eines ganzen Tages) normaler Aktivität zu geben, Ihre Änderung vornehmen, die Protokolle rotieren und dann erneut mit dem Sammeln der Protokolle beginnen (z. B. indem Sie einen weiteren Zeitraum von 24 Stunden abwarten).
Jeder Dienst (NFS, andere HTTP-Server, Samba, FTP-Server usw.) hat seine eigene Art, Informationen zu sammeln, aber im Allgemeinen gibt esmancheMittel zur Erfassung von Zeit und Durchsatz.