[C++] High-performance TCP server class/framework?

[Olaf van der Spek]

Weet iemand of er een open source class/framework is dat als basis voor een TCP server gebruikt kan worden?
Ik heb nu een paar servers op basis van select(), maar ik heb meer performance en meer dan 1024 connecties nodig.
Support voor epoll (Linux) is een vereiste, support voor kqueue (BSD) en IO completion (Windows) zou mooi zijn.

[Zoijar]

ACE misschien? http://www.cs.wustl.edu/~schmidt/ACE.html Geen idee eigenlijk, maar zou kunnen.

[Olaf van der Spek]

Wow, dat is pas een framework zeg. Misschien iets teveel van het goede, maar ik zal er zeker eens naar kijken.

[PommeFritz]

Welke taal?
Voor Python is er b.v. Twisted of Medusa.

[Zoijar]

PommeFritz schreef op 26 oktober 2004 @ 20:05:
Welke taal?
Voor Python is er b.v. Twisted of Medusa.

Ik denk C++

[Olaf van der Spek]

PommeFritz schreef op 26 oktober 2004 @ 20:05:
Welke taal?
Voor Python is er b.v. Twisted of Medusa.

High-performance en Python in één topic?

[MSalters]

Om een of andere reden denk ik dat high-performance TCP best wel eense I/O bound zou kunnen zijn, in plaats van CPU-bound.

[Olaf van der Spek]

IO als in disk of network IO?
De ene server is een BitTorrent tracker waarvan de complete state in geloof ik 32 mb past. De andere server is een IRC-achtige lobby server voor een aantal games.

Dus er komt niet zo heel veel disk IO aan te pas.

[ Voor 79% gewijzigd door Olaf van der Spek op 26-10-2004 23:09 ]

[PommeFritz]

OlafvdSpek schreef op 26 oktober 2004 @ 20:32:High-performance en Python in één topic?

Ja inderdaad, zeker als het gaat om netwerk applicaties.
Onderschat de potentie van een asynchroon I/O framework niet.

[Olaf van der Spek]

PommeFritz schreef op 26 oktober 2004 @ 23:44:
Ja inderdaad, zeker als het gaat om netwerk applicaties.
Onderschat de potentie van een asynchroon I/O framework niet.

Wat zijn de voorbeelden van snelle Python servers?

[PommeFritz]

Wat zijn de voorbeelden van snelle Python servers?

Wat bedoel je nou precies? Dat gaf ik net al aan: Twisted, Medusa, Asyncore.

[igmar]

PommeFritz schreef op 26 oktober 2004 @ 23:44:
Onderschat de potentie van een asynchroon I/O framework niet.

Echt async kan met recente linux kernels alleen met file IO : op sockets krijg je gewoon het oude gedrag. In de praktijk kom je met epoll() en een non-blocking ontwerp al een heel eind, als de IO ook nog async zou wezen zou het helemaal mooi wezen. Dat laatste is nog even wachten dus

[GeniusDex]

Het beste framework schrijf je zelf Kijk voor de gein 's naar de socket engines die bahamut gebruikt. Zijn er 5 van (devpoll, epoll, kqueue, poll, en select) met allemaal hun eigen voor- en nadelen (ook al zijn er idd beteren). Source dir kun je vinden op http://coders.dal.net/index.cgi/bahamut-release/src/ (webcvs link). Ook moet je zelf zoeken naar de voor- en nadelen van die socket engines voor wat jij wil doen, en ook om meer documentatie over het gebruik te vinden, maar dat is vrij makkelijk te vinden op zich.

[PommeFritz]

Hier staat ook nog veel interessante informatie: The C10k problem

[Olaf van der Spek]

PommeFritz schreef op 27 oktober 2004 @ 11:05:
Wat bedoel je nou precies? Dat gaf ik net al aan: Twisted, Medusa, Asyncore.

Dat zijn toch frameworks en geen volledige servers?
En zijn daar benchmarks van?

PommeFritz schreef op 27 oktober 2004 @ 15:01:
Hier staat ook nog veel interessante informatie: The C10k problem

Dat is inderdaad een mooie pagina. Maar die had ik al gelezen.

[PommeFritz]

Using a heavily customized variant of asyncore, I have written a client that can handle 500 simultaneous connections (default file handle limit with Python is 512) on a modern (1+ghz) processor. It is actually limited by bandwidth and latency on our 100mbit connection, as theprotocol is fairly chatty.

We have benchmarked it (each command results in a delay of .25/random.random() seconds, timeouts set at 30 seconds), and it comes out to roughly 4.8 million of these connections per day on a single processor (we are unsure if it scales running multiple processes on a multiple processor machine, as 99% of the processor use is system-level select.select() calls).

We are actually concerned with accidentally DOSing remote servers that have less efficient server implementations.

Tevens draaien vrij veel sites op Zope (www.zope.com) wat voor zover ik weet ook gebaseerd is op 1 van de genoemde frameworks. Verder nog:

online scrabble game : http://seps.flibuste.net with more than 650.000
hits/day I used twisted to can use the jabber and telnet protocol.

[Olaf van der Spek]

> and it comes out to roughly 4.8 million of these connections per day

Dat is 56 requests/s. Ik dacht meer aan iets van 600 - 2500 requests/s.

> Using a heavily customized variant of asyncore, I have written a client that can handle 500 simultaneous connections (default file handle limit with Python is 512) on a modern (1+ghz) processor.

500 is ook niet veel en ik betwijfel dus of 2000 - 8000 connecties mogelijk is.

[PommeFritz]

Ja, jemig, het hangt er natuurlijk ook maar zeer vanaf wat er allemaal gedaan moet worden in 1 request. Als je niet meer info geeft over je benodigde performance level dan kan je blijven gokken. En benchmarks zuigen hoe dan ook.
Overigens kon die machine uit die quote niet meer request per seconde doen om dat z'n netwerk bandbreedte al 100% benut werd. Dus als je niet met een Gigabit of T-1 of whatever aan komt zetten dan heeft het geen zin om een snellere server in te zetten. Enz enz

[Olaf van der Spek]

Het gaat om de socket handling code, niet om de response generatie code.
Als benchmark van socket handling code voor een HTTP server worden vaak static responses van 1 - 1000 bytes gebruikt. Dan is bandbreedte niet zo snel de beperkende factor.
In de first post heb ik overigens al vermeldt dat er meer dan 1024 connecties ondersteund moeten worden.