[vz-dev] Erreichbarkeit Wiki

[sirell]

Hi,

So als Vorschlag:

Überprüft mal die HTTP-Returncodes auf übermäßig lange Keepalives.
Im zweifel einfach mal mit max_keepalives und timeout spielen.

Mit "MaxKeepAliveRequests 0" hab ich gerade bei diesem Lastprofil
schlechte Erfahrung gesammelt. Am besten von
"KeepAliveTimeout 30" und
"MaxKeepAliveRequests 500" herunter tasten.

Beginne mit dem Timeout, der schafft RAM frei wenn doofe IPv6
DSL-Clients ge-cgnat-tet über IPv4 kommen.
Da funktioniert das CGNat nicht ordentlich. Ich habe derzeit zum
Beispiel über 1000 Clients die Keepalives versuchen aber jedes mal den
Port ändern. Die bekommen dann einen HTTP-Error 408. KDG und Vodafone
sind im Moment ganz übel.

Wie sehen denn die Antwortzeiten einer geparsten Seite aus ?
Ich versuche (ohne Grafiken) unter 70 ms zu bleiben (von extern
gemessen), ab 250 ms warnt check_mk.

netstat -anp anzuschauen könnte auch helfen, genauso wie das access log
des Indianers. Filter alles raus was 2xx oder 3xx ist. Der Rest ist
interessant.

Hth!

Micha


Am 06.04.2017 um 19:41 schrieb Justin Otherguy:
> Hi,
> 
>> Am 06.04.2017 um 16:48 schrieb Andreas Goetz <cpuidle at gmail.com>:
>>
>> Ich denke das Muster wird langsam klar. Hier der Apache Status:
>>
>> CPU Usage: u1237.04 s161.58 cu.21 cs.08 - .433% CPU load
>> 3.36 requests/sec - 82.9 kB/second - 24.7 kB/request
>> 84 requests currently being processed, 6 idle workers
>> GGWGGGGGGGGGGGGG_GGGGG_G_WG_GGGGWGGGGGGWGGGGGGGWWGWWGWGGGGGGG_GG
>> WGGGGGG_GGGGCWGGCCCCCCCCCC
>>
>> Nur 6 Worker sind frei um Arbeit zu leisten. Die G sind websocket Connections die offen gehalten werden.
>>
>> Also Maßnahme 1: die doppelten WS Connections verhindern (mache ich)
>> Maßnahme 2: verfügbare Worker nochmal erhöhen (@Justin)
> 
> erledigt; das ist aber doch eher kontraproduktiv, oder? (weil: jetzt wird noch mehr RAM belegt).
> 
> 
> Gruß, J.
>