Server overbelasting

[Foxie_s]

Na vorige thread (linkje) is onze opstelling ondertussen operationeel, maar helaas zitten we met paar onverwachte problemen waar we bij het ontwerp geen rekening mee hebben gehouden. Bij het ontwerp zijn we uitgegaan van data traffic van ongeveer 200GB per maand. Tevens zijn we er vanuit gegaan dat een verbinding van 10Mb/s zonder overboeking genoeg zou zijn, aangezien er geen langdurige downloads zouden zijn maar kleine RSS feed updates.

Nu blijkt dat we vorige maand een dataverkeer van 500 GB hadden en deze maand zitten we al op 1,5TB (dus over de ganse maand gaat het ongeveer 3TB worden). Wat bijna het maximum is wat de lijn kan hebben. Daarnaast blijkt dat we op sommige momenten meer dan 65.000 simultane connecties hebben naar onze servers.

Op dit moment is het systeem al overbelast en kunnen we volgende stappen snel ondernemen:

• Verbinding verhogen naar 100Mb/s zonder overboeking.
• Rem op de groei zetten.

Nu heb ik van onze provider doorgekregen dat de verbindingsnelheid niet het enigste probleem is maar het aantal gelijktijdige verbindingen ook te hoog is. Hierdoor loopt de IP tabel van de firewall over. Een zwaardere firewall zou een mogelijke oplossing zijn, maar het aantal IP adressen dat naar 1 IP adres wordt geleid, is volgens hem ook beperkt.

Dus een mogelijke oplossing is gebruik te maken van meerdere locaties en vervolgens een DNS loadbalancing toe te passen.

Nu vroeg ik me af of er nog mensen hier zo een setup gebouwd hebben en tegen deze problemen zijn aangelopen ( beperking aantal simultane connecties, data traffic enz)?

[BCC]

Hoeveel requests per seconde heb je nou precies? Doe je wel of geen keepalive (en zo ja, hoe lang dan?) Gebruik je Gzip of juist niet? Lever je je statics los en met welke server dan en via een losse URL? Waar bestaat de bulk van je verkeer uit? Kortom: more info please

[ Voor 25% gewijzigd door BCC op 15-01-2009 21:32 ]

[Foxie_s]

BCC schreef op donderdag 15 januari 2009 @ 21:30:
Hoeveel requests per seconde heb je nou precies? Doe je wel of geen keepalive (en zo ja, hoe lang dan?) Gebruik je Gzip of juist niet? Lever je je statics los en met welke server dan en via een losse URL? Waar bestaat de bulk van je verkeer uit? Kortom: more info please

Helaas heb ik niet zoveel bij de hand (tis al laat ) maar volgens de loadbalancer grafieken heb ik nu ongeveer 2000 connecties en een connectie rate van 50 CPS.
Van de firewall heb ik geen gegevens aangezien die in extern beheer is dus weet ik niet hoeveel er daar wordt tegengehouden. Zal morgen die informatie toevoegen.
Een sessie (op de loadbalancer is dit op 120s gezet) en in IIS is keepalive op elke website ingesteld op 120s.

Gzip, statics los en met welke server dan en via een losse URL zegt me niets . De bulk van het verkeer is afkomstig van andere websites die bestandjes aanroepen op onze servers.

[BCC]

GZIP = staat HTTP compressie aan? http://www.microsoft.com/...98cf9a7d568.mspx?mfr=true

Statics: Worden bestanden en plaatjes vanaf een losse fileserver geserveerd? Wat voor een serversoftware draait hierop. Heeft deze een aparte URL (zoals tweakimg.net)?

Keepalive: Dus het staat nu zo ingesteld dat als er 1 bestandje wordt geopend, er 120s een connectie blijft openstaan? Dan kan de firewall idd wel aardig vollopen. 50cps * 120s = 7000 openstaande connecties.

Maar wat ik eigenlijk probeer duidelijk te maken: Het kan aan 100.000 dingen liggen en je moet eerst echt een duidelijk beeld hebben van de hoeveelheid verkeer (requests), het type data wat ze ophalen (statisch/dynamisch) en het type sessie wat ze hebben (1 enkele of vele series requests) voordat je ook maar iets zinnigs kan zeggen over hoe je het geheel moet oplossen.

Niet in het minste omdat bij elke tweak voor en nadelen heeft die afhankelijk zijn van de bovenstaande dingen. Om even GZIP als voorbeeld te nemen, GZIP kost CPU, maar bespaart bandbreedte en connectie-tijd. Als je server qua CPU weinig belast is, maar qua bandbreedte vol zit, kan dit dus een oplossing zijn. Als je CPU al heel hard bezig is met dynamische content genereren, kan het aanzetten van GZIP er voor zorgen dat je juist weer minder requests per seconde kan afhandelen.

Begin hier eens met lezen: http://www.microsoft.com/...3c-8b2a-520c2961408e.mspx

[ Voor 65% gewijzigd door BCC op 15-01-2009 23:14 . Reden: leesbaarheid vergroting ]

[Cave_Boy]

Foxie_s schreef op donderdag 15 januari 2009 @ 22:22:
[...]


Helaas heb ik niet zoveel bij de hand (tis al laat ) maar volgens de loadbalancer grafieken heb ik nu ongeveer 2000 connecties en een connectie rate van 50 CPS.
Van de firewall heb ik geen gegevens aangezien die in extern beheer is dus weet ik niet hoeveel er daar wordt tegengehouden. Zal morgen die informatie toevoegen.
Een sessie (op de loadbalancer is dit op 120s gezet) en in IIS is keepalive op elke website ingesteld op 120s.

Gzip, statics los en met welke server dan en via een losse URL zegt me niets . De bulk van het verkeer is afkomstig van andere websites die bestandjes aanroepen op onze servers.

Die bulk haalt bestandjes op... Wil je dit of wil je dit eigenlijk niet? Zoniet dan zou ik juist dit proberen te voorkomen zoveel mogelijk door het direct linken te mogelijk te maken. Anders blijf je doorgaan mar snelheidverhogingen en server uitbreiding.

[ACM]

BCC schreef op donderdag 15 januari 2009 @ 23:02:
Keepalive: Dus het staat nu zo ingesteld dat als er 1 bestandje wordt geopend, er 120s een connectie blijft openstaan? Dan kan de firewall idd wel aardig vollopen. 50cps * 120s = 7000 openstaande connecties.

Dat de keep-alive zo lang mag duren zegt nog niet dat alle lijnen ook zolang open blijven staan, desalniettemin kan tegenwoordig de keep-alive doorgaans wel een stuk lager, naar bijvoorbeeld een waarde tussen de 5 en 30 seconde.

Niet in het minste omdat bij elke tweak voor en nadelen heeft die afhankelijk zijn van de bovenstaande dingen. Om even GZIP als voorbeeld te nemen, GZIP kost CPU, maar bespaart bandbreedte en connectie-tijd. Als je server qua CPU weinig belast is, maar qua bandbreedte vol zit, kan dit dus een oplossing zijn. Als je CPU al heel hard bezig is met dynamische content genereren, kan het aanzetten van GZIP er voor zorgen dat je juist weer minder requests per seconde kan afhandelen.

Tegelijkertijd zal in principe de lengte van een response korter worden, en dat zou op de firewall positief kunnen werken.

Foxie_s schreef op donderdag 15 januari 2009 @ 22:22:
De bulk van het verkeer is afkomstig van andere websites die bestandjes aanroepen op onze servers.

Wat bedoel je met deze opmerking? Bedoel je dat andere websites bestanden van jullie servers linken/in hun content integreren?
Als dat niet is wat je wil zijn er wel wat trucken om te voorkomen dat het gebeurt, maar deeplink/hotlink beschermingen kosten weer rekenkracht (wellicht al meer dan domweg de statische files overzenden, doorgaans wel minder dan dynamische content genereren). Andere trucken kunnen varieren van periodiek de namen van files veranderen, wat zeker handig kan werken op het moment dat je slechts enkele files hebt die heel populair zijn.

[Foxie_s]

ACM schreef op vrijdag 16 januari 2009 @ 08:01:
Wat bedoel je met deze opmerking? Bedoel je dat andere websites bestanden van jullie servers linken/in hun content integreren?
Als dat niet is wat je wil zijn er wel wat trucken om te voorkomen dat het gebeurt, maar deeplink/hotlink beschermingen kosten weer rekenkracht (wellicht al meer dan domweg de statische files overzenden, doorgaans wel minder dan dynamische content genereren). Andere trucken kunnen varieren van periodiek de namen van files veranderen, wat zeker handig kan werken op het moment dat je slechts enkele files hebt die heel populair zijn.

Het is inderdaad zo dat het meeste van onze traffic wordt veroorzaakt door andere websites die linken naar onze content. Dit is ook de bedoeling van de setup maar aangezien het voor iedereen vrij is om te doen is het moeilijk om een analyse te maken van de verwachten traffic.

Zodra een "grote" website onze content toont zal elke bezoeker van die website ook even connectie maken met onze server om de feed te downloaden.

[BCC]

Foxie_s schreef op vrijdag 16 januari 2009 @ 13:53:
[...]
Dit is ook de bedoeling van de setup maar aangezien het voor iedereen vrij is om te doen is het moeilijk om een analyse te maken van de verwachten traffic.

Zodra een "grote" website onze content toont zal elke bezoeker van die website ook even connectie maken met onze server om de feed te downloaden.

Je wil kijken waar NU het probleem zit en dat NU oplossen. En over de feed, ik neem aan dat deze flink geacached wordt?

[swtimmer]

Foxie_s schreef op donderdag 15 januari 2009 @ 21:15:
Tevens zijn we er vanuit gegaan dat een verbinding van 10Mb/s zonder overboeking genoeg zou zijn, aangezien er geen langdurige downloads zouden zijn maar kleine RSS feed updates.

Je zou ook kunnen kijken of je de RSS/XML feed niet beter via een less verbose manier kan uitwisselen zoals Json. Dat scheelt enorm aan verkeer (zeker als gzip uitstaat!). Maar hosten die andere mensen een JS script wat met jullie data werkt of hoe moet ik het zien?

[sanzut]

Als het goed is, en als ik het goed begrepen heb gaat het in dit geval over RSS of XML feeds?
Als het over een écht kritisch onderdeel gaat zijn een aantal opties niet mogelijk maar als een minuutje vertraging acceptabel is dan zou je kunnen kijken naar eenof meerdere oplossingen hieronder.

Eventueel 304 headers toepassen. Daarmee geef je de client aan dat de inhoud niet veranderd is, en dat hij zijn gecachte versie toont.

Verder zou je het zo in kunnen richten dat je de content 1x per minuut opslaat als een statisch XML of RSS bestand. Dit bestand wordt dan door de clients aangeroepen. Een statisch bestand sturen gaat natuurlijk sneller als een dynamisch bestand.

Als er véél servers zijn die van je content gebruik maken kan je eventueel proberen dat, at least de grote sites, zelf jou content cashen, dus dat hun server 1 keer per minuut jou file aanroept, en dat ze deze daarna lokaal opslaan. Dit scheelt uiteraard ook veel verkeer.

Puur uit interesse, over welke site/applicatie gaat het?

[Foxie_s]

swtimmer schreef op vrijdag 16 januari 2009 @ 14:27:
Je zou ook kunnen kijken of je de RSS/XML feed niet beter via een less verbose manier kan uitwisselen zoals Json. Dat scheelt enorm aan verkeer (zeker als gzip uitstaat!). Maar hosten die andere mensen een JS script wat met jullie data werkt of hoe moet ik het zien?

nee, wij hosten zowel de feed als het javascript. Mensen plakken een regel code in hun website.

code:

<script type="text/javascript" src="http://onzewebsite.local/script.js"></script>

Deze code roept een javascript aan die vervolgens RSS-feed uitleest (met een tussenstap).

sanzut schreef op vrijdag 16 januari 2009 @ 16:08:
Als het goed is, en als ik het goed begrepen heb gaat het in dit geval over RSS of XML feeds?
Als het over een écht kritisch onderdeel gaat zijn een aantal opties niet mogelijk maar als een minuutje vertraging acceptabel is dan zou je kunnen kijken naar eenof meerdere oplossingen hieronder.

vertraging is mogelijk maar zou tot een minimum moeten herleid worden. We houden op dit moment een maximum vertraging van 1 minuut aan tussen de verschillende webservers.

Eventueel 304 headers toepassen. Daarmee geef je de client aan dat de inhoud niet veranderd is, en dat hij zijn gecachte versie toont.

we werken al met de 304 headers waardoor er geen onnodige data over de lijn gaat. Maar het blijft een connectie naar de server(s).

Verder zou je het zo in kunnen richten dat je de content 1x per minuut opslaat als een statisch XML of RSS bestand. Dit bestand wordt dan door de clients aangeroepen. Een statisch bestand sturen gaat natuurlijk sneller als een dynamisch bestand.

Ook hier hebben wel al gekozen voor statische bestanden.

Als er véél servers zijn die van je content gebruik maken kan je eventueel proberen dat, at least de grote sites, zelf jou content cashen, dus dat hun server 1 keer per minuut jou file aanroept, en dat ze deze daarna lokaal opslaan. Dit scheelt uiteraard ook veel verkeer.

Helaas is het web applicatie zo opgezet dat de mensen gewoon de URL moeten kopieren zonder dat ze ons moeten verwittigen. Dus we weten op dit moment gewoon niet wie op deze wereld het allemaal gebruikt. Om extreme zou bijvoorbeeld een website zoals cnn het gewoon erop hebben staan zonder dat wij het weten. Maar elke gebruiker die de website cnn zou bezoeken maakt wel contact met ons.

Ik heb ondertussen ook een eerste log bestand gekregen van het aantal connecties (elke minuut wordt dit weggeschreven in een log-file) en ik vermoed dat er daar iets heel fout aan het lopen is ... in het kort ziet de log er ongeveer zo uit (laatste getal is het aantal connecties):

code:

2009-01-16 10:16:00 4171
2009-01-16 11:10:00 5355
2009-01-16 12:10:00 6671
2009-01-16 13:10:00 7994
2009-01-16 14:10:00 9408
2009-01-16 15:10:00 10818
2009-01-16 16:10:00 12532
2009-01-16 17:10:00 13939

Het lijkt er bijna op dat er elk uur 1000 connecties bijkomen en blijven "hangen". Maandag ga ik een file hebben over het volledige weekend dus dat zal weer wat meer info geven (hoop ik). In elk geval al bedankt voor de aangedragen optimalisatie tweaks... ze meeste (zoals de keepalive instelling zijn we aan het doorvoeren.) Gzip zijn we aan het bekijken maar is iets waar we wat meer bestuderen vooraleer het toe te passen.

[eth0]

Foxie_s schreef op zaterdag 17 januari 2009 @ 02:18:
[...]


nee, wij hosten zowel de feed als het javascript. Mensen plakken een regel code in hun website.

code:

<script type="text/javascript" src="http://onzewebsite.local/script.js"></script>

Deze code roept een javascript aan die vervolgens RSS-feed uitleest (met een tussenstap).

Dus bij elke hit die sites van die mensen wordt jullie server gehit. Als dat veel bezochte sites zijn, tja. Dus het verkeer is afhangkelijk van die andere sites...

Kan je het script niet laten hosten op die sites zelf? Dat scheelt natuurlijk wel, dan hoef je alleen maar de feed te leveren. Maar dan ben je wel de controle kwijt. Anders loadbalancing...

En wat voor een firewall heb je, een statefull? Misschien is een stateless packet filter beter? Ligt aan de rules die je gebruikt. Dan heb je geen overflow van je tables...

[ Voor 24% gewijzigd door eth0 op 17-01-2009 04:16 ]

[riddles]

Apache?
Begin dan eens met het aanzetten van een server-status. Dan kun je zien wat voor connecties er open staan en waarom.

[Kees]

Als ik het zo lees, dan serveer je javascript en rss feeds; beiden kunnen statisch zijn.

Verder heb ik nog wel wat meer info nodig; wat is de grootte van de rss feed, veranderd deze per request, of is het 1 enkele feed die constant opgevraagt wordt en hoe vaak veranderd de feed, en als hij veranderd, hoe 'maak' je hem? Dynamisch ASP/PHP/Perl met een SQL server of iets anders?

In het meest gunstige geval heb je 1 javascript file en slechts enkele RSS feeds die 1 keer per minuut veranderen. In dat geval zou je het al kunnen serveren met 1 webserver waarop bv Lighttpd draait.

De makkelijkste problemen om op te lossen:
- Zorg voor correcte caching headers
- Zorg voor compressie (kan een factor 5 schelen op de javascript, en er zijn genoeg webservers die een script.js.gz kunnen serveren, dus zonder zelf te comprimeren elke keer)
- Als ik het goed lees vragen ze 1 javascript file op en dan 1 rss feed, je hebt keepalive op 120 seconden staan, geen wonder dat het langzaam is; probeer het eens helemaal uit te zetten of op een timeout van maximaal 5-10 seconden. 120 seconden is overdreven lang en onnodig.
- Hoe kun je 65.000 simultane connecties open hebben staan? Hoe simultaan is dat? vraag eens een volledige lijst op + de tijd hoelang ze al idle staan.
- Hoe defineer je conencties? entries in de hash table?
- Waarom gebruik je uberhaubt IIS? Heb je een keuze daarin? IIS gebruiken voor zulke triviale files is zware overkill, zelfs schieten met een clusterbom op een mug is efficienter.

[Iska]

Wat staat er in die JS? Als je dit op een 1 of andere manier in een PHP/Perl/ASP of welke server-side scripting-language kan verandere krijg je nog steeds wel veel request, maar alleen nog maar van de servers van de websites die je script gebruiken. Maakt veel verschil denk ik zo..

[ACM]

Kees schreef op zaterdag 17 januari 2009 @ 17:47:
- Waarom gebruik je uberhaubt IIS? Heb je een keuze daarin? IIS gebruiken voor zulke triviale files is zware overkill, zelfs schieten met een clusterbom op een mug is efficienter.

't Schijnt dat recente versies van IIS wel redelijk efficient kunnen werken, maar afhankelijk van de situatie is alles wat geen lichtgewicht statische file server is al te zwaar.

Verder vind ik het verhaal van openstaande connecties wel heel bijzonder inderdaad, op Tweakers.net zien we dat soort dingen niet, en we hebben toch aardig wat bezoekers en files die we uitserveren. Dat is dan wel met servers en loadbalancers die Linux draaien, dus dat kan zich anders gedragen in deze situatie.

[Gomez12]

Jasper91 schreef op zaterdag 17 januari 2009 @ 17:54:
Wat staat er in die JS? Als je dit op een 1 of andere manier in een PHP/Perl/ASP of welke server-side scripting-language kan verandere krijg je nog steeds wel veel request, maar alleen nog maar van de servers van de websites die je script gebruiken. Maakt veel verschil denk ik zo..

Tja, zal idd wel verschil maken. In plaats van een statische file te serveren ga je een hoop serverbelasting creeeren.
Dan heb je een probleem met je connecties ( want dat blijft bestaan ) en daarnaast creeer je een probleem met je serverbelasting. Lijkt me niet echt handig

[BCC]

ACM schreef op zaterdag 17 januari 2009 @ 19:27:
[...]

't Schijnt dat recente versies van IIS wel redelijk efficient kunnen werken, maar afhankelijk van de situatie is alles wat geen lichtgewicht statische file server is al te zwaar.

Ik heb laatst wat nginx performance tests gezien. Daar kunnen IIS en apache nog een puntje aan zuigen.

[Foxie_s]

Sorry voor de trage reactie maar het duurde allemaal juist iets langer om de logs te krijgen.

Kees schreef op zaterdag 17 januari 2009 @ 17:47:
Verder heb ik nog wel wat meer info nodig; wat is de grootte van de rss feed, veranderd deze per request, of is het 1 enkele feed die constant opgevraagt wordt en hoe vaak veranderd de feed, en als hij veranderd, hoe 'maak' je hem? Dynamisch ASP/PHP/Perl met een SQL server of iets anders?

De RSS feed is een statische file. Hij veranderd ongeveer 1 keer per maand.

In het meest gunstige geval heb je 1 javascript file en slechts enkele RSS feeds die 1 keer per minuut veranderen. In dat geval zou je het al kunnen serveren met 1 webserver waarop bv Lighttpd draait.

Er is gekozen voor IIS (mede omdat een gedeelte van de applicatie geschreven is in ASP.NET). De RSS feed staat op dezelfde webserver.

De makkelijkste problemen om op te lossen:
- Zorg voor correcte caching headers

Caching gebeurt goed (nagegaan wat er juist over de lijn gaan met WireSharp).

- Zorg voor compressie (kan een factor 5 schelen op de javascript, en er zijn genoeg webservers die een script.js.gz kunnen serveren, dus zonder zelf te comprimeren elke keer)
- Als ik het goed lees vragen ze 1 javascript file op en dan 1 rss feed, je hebt keepalive op 120 seconden staan, geen wonder dat het langzaam is; probeer het eens helemaal uit te zetten of op een timeout van maximaal 5-10 seconden. 120 seconden is overdreven lang en onnodig.

Bovenstaande gaan we zeker bekijken maar eerst wil het het aantal connectie verhaal achterhaald hebben. Het heeft volgens mij weinig zin om alles in 1 keer te veranderen.

- Hoe kun je 65.000 simultane connecties open hebben staan? Hoe simultaan is dat? vraag eens een volledige lijst op + de tijd hoelang ze al idle staan.
- Hoe defineer je conencties? entries in de hash table?

Hier wordt het dus raar. Van onze provider en het bedrijf dat de firewall beheert krijg ik door dat we zoveel connecties open hebben staan. Maar op de webservers en loadbalancer zie ik een stuk minder. Loadbalancer geeft op dit moment een kleine 1000 connecties aan en elke webserver (3 stuks) geeft ook maar 330 TCP connecties aan.

Maar als ik de logfile bekijk die ik van de firewall-mensen gekregen heb zie ik een lijst van 5000 connecties.

code:

tcp      6 423894 ESTABLISHED src=62.xxx.xxx.xxx dst=93.xxx.xxx.xxx sport=49210 dport=80 src=192.168.10.100 dst=62.xxx.xxx.xxx sport=80 dport=49210 [ASSURED] use=1

Zoals ACM al schreef:

ACM schreef op zaterdag 17 januari 2009 @ 19:27:
[...]
Verder vind ik het verhaal van openstaande connecties wel heel bijzonder inderdaad, op Tweakers.net zien we dat soort dingen niet, en we hebben toch aardig wat bezoekers en files die we uitserveren. Dat is dan wel met servers en loadbalancers die Linux draaien, dus dat kan zich anders gedragen in deze situatie.

Ik ben nu aan het zoeken waar die 4000 connecties zijn en waarom ik die nergens terug vind in mijn gegevens. Ik heb een vermoeden dat het ligt aan de loadbalancer maar meer dan een vermoeden is het ook niet ... Dus ik sta open voor ideeën

[Predator]

Als ik alles lees zou ik toch echt het probleem gaan zoeken tussen de 'gehoste' firewall en je loadbalancer.
Als je zo weinig connecties op je webservers ziet kan het probleem niet daarvan komen.

Dan resten er nog 2 dingen:
• Je loadbalancer geeft niet alle connecties weer die open staan of sluit ze slecht af langs de client kant
• De firewall (blijkbaar iptables als ik de log mag geloven) gooit om 1 of andere reden connecties (na de FIN of RST, of SYN zonder gevolg) niet uit de active statetable, of heeft een te hoge TCP idle timeout.

Als je in die loadbalancer de openstaande connecties opvraagt, doe je dat dan via een GUI ?
Is dat een linux based toestel ? Kan je op de command line ? Check anders daar even via een netstat ook of er niet meer connecties open blijven dan dat de GUI manager toont.
Het kan ook zijn dat je loadbalancer de connectie afsluit, maar bv niet altijd correct naar de client kan (en dus ook de FW) afsluit. Hij sluit dan de connectie af, maar als de client kan niet de FIN of RST's krijgt, dan blijven ze daar open.

Kan je niet eens sniffen net voor de loadbalancer ? (ISP FW <-> loadbalancer dus) ?
Dergelijke zaken zouden zichtbaar moeten zijn in een sniff.

Dat die connecties blijven stijgen is ook vrij verdacht (met 1000 / uur).
Zeker ook de tijd. Op een firewall is een TCP idle time-out van een uur al vrij veel.
De default is vaak 1 uur (Cisco en checkpoint bv).
Dus als een connectie blijft verschijnen in die FW met langer dan een uur idle time, dan klopt er iets niet.
Zeker voor inet-traffic. FIN/SYN waittimes zijn daar een fractie van.

Een start zou kunnen zijn dat de FW-crew al zijn timers nakijkt.
TCP idle-timeout, SYN- en FIN wait timers.
Eventueel beginnen met idle-timeout wat te verlagen.

[Kees]

Overigens is 65.000 connecties niet heel erg gek of hoog, op tweakers hebben wij zo'n 31k connecties 'open' staan op het moment; waarvan er ~250 actief zijn en de rest inactief. Het hangt er helemaal af van hoe de firewall/loadbalancer een 'open' connectie ziet.

[Predator]

Kees schreef op dinsdag 20 januari 2009 @ 15:16:
Overigens is 65.000 connecties niet heel erg gek of hoog, op tweakers hebben wij zo'n 31k connecties 'open' staan op het moment; waarvan er ~250 actief zijn en de rest inactief. Het hangt er helemaal af van hoe de firewall/loadbalancer een 'open' connectie ziet.

Over wat een 'open' connectie is valt niet te discussieren. Niet voor een TCP connectie toch.
Elke TCP sessie die zich niet in de SYN/ACK init fase or FIN/ACK afsluitfase bevindt is een open connectie.
Dus het aantal connecties gaat altijd over het aantal open TCP sessies, ongeacht hoeveel er daarvan eigenlijk 'idle' zijn. Het idee 'idle' zijn van een connectie hangt ook van het protocol af.

Maar je bedoelt waarschijnlijk dat er maar 250 connectie niet-idle zijn.
Dat kan ik best geloven aangezien veel webbrowsers vrij veel TCP sessies openen voor het binnenhalen van een webpagina, en soms blijven er daar ook nog een tijdje open om responstijden te verbeteren bij het verder surfen.

[axis]

Foxie_s schreef op donderdag 15 januari 2009 @ 21:15:

Nu heb ik van onze provider doorgekregen dat de verbindingsnelheid niet het enigste probleem is maar het aantal gelijktijdige verbindingen ook te hoog is. Hierdoor loopt de IP tabel van de firewall over. Een zwaardere firewall zou een mogelijke oplossing zijn, maar het aantal IP adressen dat naar 1 IP adres wordt geleid, is volgens hem ook beperkt.

Lijkt me dat je misschien de openstaande connecties in je firewall kunt monitoren (via SNMP bijvoorbeeld), en grafiekt, misschien zie je dan iets bijzonders.

Daarnaast zou je je loadbalancer misschien ook meerdere ip's op de stack kunnen geven, en in je DNS meerdere host records toevoegen. Misschien dat je firewall daar beter mee overweg kan. Je zou bijvoorbeeld je loadbalancer 10 ip's kunnen geven, dan moet je firewall 10x6.500 connecties bijhouden in plaats van 1x65.000. Maarja, dat ligt een beetje aan de loadbalancer. Hoewel ik 65.000 connecties wel heel erg veel vind. Klinkt als een trage firewall die connecties niet goed afsluit.

Als je firewall het dan nog niet trekt, kun je natuurlijk ook 2 firewalls parallel zetten, en met DNS de load verdelen.

Maar het lijkt me sowieso verstandig als je een goede monitoring opzet voor zowel je web servers, firewalls, load balancers, switches etc, bijvoorbeeld met Cacti/SNMP. Meten is weten! Dan krijg je bijvoorbeeld zoiets (per host, etc):



Je zou daarnaast nog kunnen experimenteren met het uitzetten van keep-alives (meer cpu belasting, maar minder open connecties).

Afhankelijk van waar nu precies het probleem ligt (als ik je begrijp staat nog niet onomstotelijk vast waar dat is), zou je natuurlijk ook als test een of meerdere reverse caching proxies ertussen kunnen zetten, zoals Squid. Al is het maar om te testen, en laat je daar 1% van je bezoekers naartoe gaan. Het realtime bekijken van de access.log kan je sowieso al een boel meer inzicht geven in je applicatie, request times, caching headers, etc. Daarnaast houd Squid zich dan bezig met het spoon-feeden van langzame clients, en blijven je IIS machines vrij van teveel connecties. (Veel connecties in IIS zorgt voor veel onnodig geheugengebruik, en kan IIS behoorlijk vertragen heb ik geconcludeerd uit benchmarks.)

Ik heb nu ook voor een paar projecten voor een IIS6 en IIS7 webfarm een reverse proxy gezet, en dat komt de performance erg ten goede bij stresstests met erg zware load. (cluster van 2 machines, met Squid voor de caching/connection handling/ssl ofloading, en HAProxy om de load over de achterliggende web servers te verdelen, en apache om eventuele 503 errors te tonen als alle webservers plat liggen).


Enne, die gehoste firewall, wat is dat dan precies? Een hobby-bob doosje met linux? Hoeft niet erg te zijn, maar wat is daarvan dan de load? Je zou als je daar niet uit komt ook nog altijd een doosje kunnen kopen als een Cisco ASA5505SP (732 EUR, tot 25.000 connecties) of een Cisco ASA5510SP (2.017 EUR, tot 130.000 connecties). Dan weet je iig zeker dat je daar geen problemen meer van hebt.

[vliegjong]

Ik spuug ook eens wat neer .
Gooi er een BlueCoat voor. zware cache bak met evt SSL oflload mogelijkheden.
check www.bluecoat.com

[sanzut]

Je hebt eerder aangegeven niet te kunnen zien van welke site´s de bezoekers komen. Is het dan misschien een optie om bijvoorbeeld de location.href via javascript ergens heen te sturen? Dan zie je de site's vanwaar je feed wordt opgevraagd. Dan kan je vanuit die logs opzoek gaan naar de top-sites die je feed gebruiken, en die aansporen om het script lokaal te gaan hosten.

Neem eventueel anders zelf contact op met de target site's waar je je op richt...

[Verwijderd]

misschien zit ik er helemaal naast, maar misschien help ik je toch op weg...

in je vorige post las ik dat je Windows Server 2003 gebruikt.
je kunt de TCP/IP stack van Windows Server 2003 tunen.
de default settings zijn gebaseerd op intranet toepassingen en heeft standaard 5000 vrije poorten beschikbaar waarvan een gebruikte poort default 4 min 'bezet' blijft.

je kunt dit gedrag tunen door op de webserver het register aan te passen en bij onderstaand artikel staat beschreven hoe je dat doet:

When you try to connect from TCP ports greater than 5000 you receive the error 'WSAENOBUFS (10055)'