Archief - [PROG] performantie client <-> server applicatie

Ik moet voor een klant een applicatie schrijven die uit 2 delen bestaat.
Enerzijds is er het clientgedeelte wat de gebruikers zullen gebruiken en anderzijds is er een server waar er zal op geconecteerd zal worden.

Er wordt een gebruikersaantal van tussen de 50000 en 100000 verwacht.
Nu vroeg ik me af hoe je zo iets performant aanpakt?

Momenteel heb ik een multithreaded server geschreven die voor elke connectie een thread start. Nu vroeg ik me af, of dit wel performant blijft als je met tienduizenden gebruikers tegelijk inlogd want dan zit je met evenveel threads...

De server zal welliswaar een dedicated machine worden (xeon 3Ghz ofzo) maar weet niet of dit voldoende is. Iemand die daar reeds ervaring mee heeft of die weet of dit allemaal geen probleem is?

Connection pooling? (of is uw thread ook een soort pooling? ).
En gebruikersaantal 50000 en 100000 ... wat ook niet onbelangrijk is, zijn het aantal piekgebruikers (of zijn ze dat? ) op hetzelfde moment (concurrent users). Want op basis daarvan kunt ge de grootte van uw pool bepalen.

piekmomenten zal het toch 10000+ kunnen zijn denk ik. Allé, verwachten ze maar ik denk dat het minder zal zijn maar je weet nooit.

IS het mogelijk om zelf een connectionpooling systeem te schrijven? Ik weet dat het bestaat voor DB connecties maar lukt het ook voor sockets?

Euhm.... je gaat een systeem schrijven dat 10.000-en gebruikers moet afhandelen maar hebt geen flauw benul van hoe je een correcte client-server applicatie schrijft? (sorry voor de botheid, maar zo komt het wel over)

Je wil ab-so-luut geen thread per connectie aanmaken! Want:
- dat is niet performant (continue threads maken/deleten is vrij CPU-intensief)
- dat is onveilig (je kan makkelijk de server flooden en laten crashen door oneindig veel connecties te maken)

Wat je zou moeten kunnen is:
- standaard x aantal threads maken die slapen en die je "wakker" maakt als je een task hebt (bvb 16 threads)
- een connection listener maken die jobs aanneemt en verdeelt over threads.

Weet je ook wat die server precies moet afhandelen per connectie? Ik kan me voorstellen dat 10.000 requests per seconde nogal zwaar zijn, zelfs voor een 3GHz Xeon oid. Ik hoop iig dat je een aparte DB server en bijhorende backup server ter beschikking krijgt? (want data van zoveel users wil je ECHT niet verliezen)

ps: m'n zelfgemaakte httpd server werkt ook wel op die manier met threads, maar die applicatie is nooit bedoeld geweest om echt te gaan gebruiken in de praktijk.

het is nog maar analysefase hé. Ik ben nog enkele opties aan het onderzoeken, vandaar.
Ik wil eerst zekerheid bieden dat ik het performant kan aanbieden, vandaar dit onderzoek.

Moet ik dan bijvoorbeeld 16 threads aanmaken en dan elke keer dat er een nieuwe connectie binnenkomt, één van die 16 de communicatie met de socket laten opvangen zodat het gelijk verdeeld geraakt of hoe gaat dat in zijn werk met x-aantal threads?

kijk anders hier eens : http://java.sun.com/developer/Books/javaprogramming/threads/chap13.pdf

als het een serieuze applicatie wordt voor zoveel gebruikers is het misschien ook logisch om specifieke middleware te gaan gebruiken. Ik neem aan dat je niet alle concerns zoals thread pooling, connection pooling, synchronisatie, transacties, security, etc zelf wil gaan implementeren van scratch. Je kan dan bijvoorbeeld gebruik gaan maken van J2EE technologien zoals Enterprise Java Beans of iets dergelijks.

ik zou het niet in java moeten schrijven maar in dot net...
toch bedankt voor de info

mja, het principe blijft exact hetzelfde he

Als het een webserver achtig systeem is (connecteren, snel data doorsturen en afbreken), kan je dat worker-sleeper thread gedoe wel mooi toepassen natuurlijk. Maar als je een keep-alive connectie wilt, is het misschien beter om eens te kijken hoe IRC-servers het aanpakken. De source van IRC-servers is meestal vrij te downloaden (Asuka van Quakenet, die van Undernet, UnrealIRCd,...). Succes!

Over wat voor dataverwerking gaat het hier? Hier zijn alvast wat voorbeelden van IRC clients en hun mogelijkheden:

Een professionele IRC applicatie zoals "conference room" kan max met 1000 connecties overweg. http://www.webmaster.com/

http://www.vulnscan.org/UnrealIrcd/faq/#46 zegt dit:

I've done several tests with 10K (yes, 10000) clients on Linux 2.4* and it went fine. But to handle this amount of clients you need a good box like with a ghz proc, and more important: with enough (free) memory... at least 512Mb, and preferably 1Gb+ (not only for unreal, but also for socket buffers, etc).

I'm aware of a few "live nets" that in fact hold ~3000 users on 1 server. Why I'm only aware of a few? Well, as said.. most networks just use multiple servers.

Klik om te vergroten...

http://www.inspircd.org/wiki/General_FAQ zegt:

How much memory does InspIRCd use? How does this compare to other IRCd software?

On our test platform, a three server network with 11500 bots over 52 channels takes just over 33mb of RAM. During very heavy connects (e.g. many thousands), it consumes anywhere between 2% and 90% CPU, which drops back to 0% after the connections are done. Our test PC is a 750mhz Pentium-3 with 350mb of RAM and 80gb of disk space, running FreeBSD 5.4. 10000 bots were connected remotely and 1500 locally.

Klik om te vergroten...

... dat valt dus best mee.

Ik zou zeggen: reken uit hoeveel data je moet verwerken, maak een testopstelling en check uit hoeveel het kost aan CPU. Daarna kan je de testopstelling uitbreiden met een netwerkconnectie en kijken hoe performant je de software kan krijgen met het verwerken van de data met de pakketgrootte die je verwacht.

In .NET zitten remoting stuff genoeg da ge kunt gebruiken breek uwe kop nie over threading en dergelijke as ge al zo'n vragen moet stellen... multi threading is een van de moeilijkste dingen in programmeren.

het simpelste is gewoon webservices gebruiken . perfect scalable. Kan uwe server het nie meer aan zette gewoon ne node bij in uwe cluster en tis opgelost. en 1 machien???? probeer eerst met virtual servers wa load da gaat geven e.d.