HTTP server se zastaví po 16 tisících requestů na 20 vteřin rubrika: Programování: Jiné
10
jiri.knesl
Naprogramoval jsem naprosto stejnou službu v Clojure, D a Go (naschvál velmi odlišné jazyky i platformy).
Jde o jednoduchou aplikaci, která sbírá požadavky v POSTu, jednou za vteřinu je agreguje a zapíše do databáze.
Když aplikace benchmarkuju, u všech 3 se cca po 16 tisících requestů aplikace na 20 vteřin zastaví a nepřijímá requesty.
Zkoušel jsem dtruss, tam není nic vidět. Zkoušel jsem sám řídit garbage collector, tím to taky není. Aplikace se zastaví na příjmu HTTP požadavků.
Musí to být něco v systému.
Zkoušel jsem to na 2 počítačích (oba aktuální OS X) a chování identické.
Napadá vás, čím to může být?
Bohužel si nemůžu dovolit, aby aplikace zastavila na déle, než půl vteřiny.
10
jiri.knesl
Hodně pomohly odpovědi z Twitteru https://twitter.com/jiriknesl/status/512713560397320192
Problém je v tzv. ephemeral ports.
Komentáře
-
vojtech.kurka
:
Kdysi jsem to resil pri hodne velkym provozu na MySQL a na HTTP reverse proxy.
Na interni siti muzes nastavit recycle - ty spojeni v TIME_WAIT stavu se budou zahazovat. Nemuzes to ale pouzit na serveru, ktery primo komunikuje s HTTP klienty na internetu (typicky na load balanceru), protoze to zpusobuje problemy s nekterymi klienty za NATem.
Pokud vim, firmy jako treba Google to interne resi vlastni upravenou implementaci TCP, pripadne vlastnim internim nastavenim. Nekdo pouziva vice IP adres na jednom stroji a mezi ne to balancuje. Zaklad je nastavit ten rozsah portu vetsi nez default. Ja jsem typicky pouzival 10K - 65K.
Jestli prijdes na lepsi reseni, dej mi vedet :)
—
19.9.2014
-
vojtech.kurka
:
Peknej clanek: http://vincent.bernat.im/en/blog/2014-tcp-time-wait-state-linux.html
—
20.11.2014
Pro zobrazení všech 5 odpovědí se prosím přihlaste:
Nebo se přihlaste jménem a heslem:
Komentáře