HTTP Persistent Timeout - waarde?

[Verwijderd]

Hi all,

Ik ben bezig een webinterface te ontwikkelen voor een laser-module. De webserver draait op een arm7, die naast de webserver nog enkele andere taken voor zijn rekening neemt.

Nu blijkt een open tcp connectie erg veel cpu-tijd op te eisen. Een oplossing die ik gevonden heb is het verkleinen van de http-persistent-timeout, die default op 60 seconden staat. Nu lijkt dit een effectieve oplossing. Ik zie netjes dat de open verbindingen sneller gesloten worden en de cpu-load duidelijk zakt.

Mijn vraag is nu: Wat is de invloed van de persistent timeout? Kan ik deze daadwerklijk zo laag mogelijk (bijvoorbeeld 1 seconde) instellen, of geeft dit in de een of andere situatie problemen? Op dit moment, aan een vrij simpel netwerk treden er verder geen problemen op, maar ik kan verder geen specifieke informatie vinden over de risico's van een relatief lage persistent timeout.

Thanks in advance!

Edit: Verkeerde subforum waarschijnlijk, sorry...

[ Voor 3% gewijzigd door Verwijderd op 20-01-2010 14:43 ]

[Remus]

Ik zie eigenlijk niet helemaal in waarom een open socket veel CPU tijd zou gebruiken, tenzij er op een onhandige manier aan busy waiting wordt gedaan bij het wachten op nieuwe data. Overigens zou de HTTP server ook gewoon een Connection: close header mee kunnen geven.

[gertvdijk]

Een openstaande TCP-connectie is relatief 'duur' in CPU-tijd inderdaad, maar dat is erg relatief. Op een quadcore bak loop je nauwelijks tegen dergelijke problemen aan, maar op wat low-power embedded hardware kan ik me voorstellen dat je daarin wat wil optimaliseren inderdaad. Nou kan ik me voorstellen dat er twee factoren meespelen in de 'load' van een openstaande connectie: de connectie zelf (tabel, tijd bijhouden) en het proces dat erachter hangt. Kan je eens wat vertellen over de gebruikte software? OS en webserver is wel handig.

[Verwijderd]

Er draait NET+OS versie 7.4. De webserver is een ingebouwde applicatie (waarschijnlijk door Digi - de ontwikkelaar zelf).

Ik kan me goed voorstellen dat een onhandige manier van programmeren de root van dit evil is. Dat probleem hadden we ook al bij de spi api. Omdat er een quick (en dus eventueel dirty) oplossing gevraagd is, lijkt het verkleinen van de http-persistent-timeout me vrij redelijk. In ieder geval in tegenstelling tot het doorspluizen van de hele (slecht gedocumenteerde) webservercode.

Ik kan alleen niet echt een beeld vormen van de risico's van een kleine timeout waarde en de voordelen van een grote timeout waarde. Of omgekeerd natuurlijk. Vandaar mijn vraag, of ik in bepaalde gevallen tegen problemen op loop met een uiterst kleine persistent-timeout.

[gertvdijk]

Verwijderd schreef op woensdag 20 januari 2010 @ 16:20:
Ik kan alleen niet echt een beeld vormen van de risico's van een kleine timeout waarde en de voordelen van een grote timeout waarde. Of omgekeerd natuurlijk. Vandaar mijn vraag, of ik in bepaalde gevallen tegen problemen op loop met een uiterst kleine persistent-timeout.

Googlen kan iedereen. Maar ik zal even redeneren vanuit mijn perspectief. Bij normaal gebruik van een webinterface of website zal de gebruiker zo nu en dan doorklikken en dus regelmatig opnieuw een connectie willen met de webserver. Daarom is het efficiënter om een proces (en tcp-connectie) een tijdje open te laten staan zodat er snel geserveerd kan worden. Die timeout wordt gecommuniceerd met de browser zodat die weet of ie een nieuwe connectie moet openen of de oude kan hergebruiken. Als je telkens het proces zou afschieten en de connectie zou verbreken moet elke keer weer een proces geforkt worden en een nieuwe connectie worden geopend. Daarom is een timeout van 60 seconde waarschijnlijk in normaal gebruik een verstandige default, maar natuurlijk sterk afhankelijk van je situatie. Als het instellen van 1s als timeout t.o.v. 60s met maar 1 browser/gebruiker/pc ervan gebruikmakend veel effect heeft op de load in positieve zin (lagere load) is het gewoon slecht programmeerwerk in de webserver of kernel/netwerkstack.

Ben je gebonden aan dat OS? Je zou kunnen overwegen op termijn over te schakelen naar iets wat veel meer wordt toegepast op embedded systemen: Linux.

[ Voor 5% gewijzigd door gertvdijk op 20-01-2010 16:30 ]

[Verwijderd]

Thanks, ik heb je verhaal in ieder geval begrepen. Ik ga er vandaag nog eens mee aan de slag.

Het probleem in deze situatie is dat ik halverwege het project pas bij dit bedrijf in dienst ben gegaan. Naar mate de functionaliteiten van het product toenemen wordt meer en meer duidelijk dat er helaas niet de optimale keuzes gemaakt zijn wat betreft hardware en OS. Ik zou ook de linux flexibiliteit erg op prijs stellen in dit geval, maar dat zit er dus helaas niet meer in. In ieder geval bedankt voor je reacties!