Volgens mij zijn er tegenwoordig wetten die braaten en dergelijke verbieden.

Is het spammen van een database verboden? Ik dacht alleen de ddos die tegelijk plaatsvindt, maar dont pin me down.

Ik weet het niet... ergens lijkt me dat, zolang het niet een geautomatiseerd netwerk is, ontworpen om websites neer te halen, dat je kunt spreken van een handmatige stress test van de web services. En databases volspammen, tsja, als mensen vragen om input kunnen ze die krijgen...

Nu heb je natuurlijk tegenwoordig veel meer captcha's dan vroeger, en die maken dit soort spul een stuk lastiger. Maar goed, wie zegt dat het slecht is voor een webserver om eens flink getest te worden? Google Chrome heeft in de developer tools, onder Network, een tijdlijn die weergeeft hoe lang het duurt om iets te laden. Het wordt dan wel heel makkelijk om te zien dat het grootste .png bestand op een bepaalde website bijvoorbeeld 100 kB is en 3 seconden duurt om te laden. Ik noem maar wat.

Verder heb ik het lokaal getest, met een simpel webservertje (SimpleServer:WWW van AnalogX) en die gaat in 3 seconden uit de lucht. Maar dat is zonder fysieke netwerkverbinding, rechtstreeks van socket tot socket, met 40 MBps. Toch aardig om te weten dat dit de limiet van je server is, iedere webhoster behoort dat te weten over zijn servers nietwaar?

Wanneer komt die app in de App Store?

Is voor WINDOOS, het was niet mijn bedoeling om mensen te misleiden... ik ga hem op Sourceforge zetten zodra het kan, de interface een beetje herstructureren en de code wat opschonen. Je kent het wel.

Het blijft hoe dan ook een denial-of-service attack, en dat is tegenwoordig strafbaar.

/Als je dit trouwems met 1000 threads hebt gedaan en het was geen CSP-taal zoals Erlang verdien je het om keihard geslagen te worden. 1000 non-blocking sockets met één select() loop is ruim dan voldoende.

We hadden een nieuw project, de praatolizer, maar dat backfirede en liep helemaal uit de klauwen. Het werd uiteindelijk uit de 'U zei' gehaald.

Wat Monade zegt. Threads misbruiken als scheduler is een slechte gewoonte.
Een single-threaded select() met nonblocking sockets kan iedere huiskamerload/feed aan. De enige blocking die er overblijft is dan pagefaults en disk-IO. Het bevrijdt je bovendien van de verplichting om overal mutexes omheen te zetten.
Maar: dit soort programmaatjes zijn altijd handig om bij de hand te hebben als basismateriaal voor stresstesten enzo.

En on-topic: braaten was leuk. Maar het is voorbij. Want verboden, want dDOS-attack.
Het aanbod van braatbare slachtoffers (SPAMHOEREN) lijkt ook te zijn afgenomen. Behalve dan wat oost-europese bruiden enzo.

@Monade: weet ik, er zijn betere manieren om dit te doen, ik was helemaal niet van plan zelf direct naar sockets te gaan schrijven of wat dan ook. Daar heb ik een DNS server projectje voor liggen ergens.

Je hebt gelijk dat de threads overbodig, te zwaar en zinloos zijn voor waar ik ze hier voor gebruik en ik zou dan ook de programmeur van iedere serieus bedoelde applicatie die dit werkelijk doet om de oren slaan. Aan de andere kant kan ik deze code gebruiken om mijn eigen wget-versie te maken bijvoorbeeld. HTTrack is leuk maar soms gewoon net niet wat ik zoek.

Dus. Hoe dan ook, het was een experiment en ik zou nooit serieus overwegen het ergens voor productie code toe te passen.

Mijn opzet is heel simpel: Ik gebruik system.net en system.threading in het .NET 4 framework omdat het een productieve manier is om werkende code te schrijven. En dat lukte, dus "SUCCES"! Een beter begrip van het HTTP protocol is prachtig, ik test regelmatig SMTP servers en HTTP servers via telnet. Het is dus een brute-force opzet geworden. Één WebClient() object per thread, een paar public strings met urls erin, en dan per thread synchroon het bestand downloaden. Verder niks.

@Monade: Ik moet opbiechten dat ik totaal geen ervaring heb met CSP. Is Erlang een goede taal om hier meer over te leren? Of heb je een betere suggestie voor iemand die verder wel met meer algemene productietalen overweg kan?

@Monade: je bedoeld waarschijnlijk een CPS-style language? Welke je neemt (@Merv) maakt nieso veel uit. Als je je denkraam eenmaal omgewerkt hebt naar functioneel/CPS dan ben je om :-)
/worteljurk

Je kunt ook gewoon 1000 threads met 1 socket/thread doen. Helemaal geen locks nodig in dat geval en al helemaal geen select. Als je poll/select gebruikt heb je bij voorbaat de performance-race al verloren.

Dat heb ik dus gedaan, 1 socket per thread. De WebClient class geeft je een simpele interface om een HTTP verb uit te voeren, zowel synchroon als asynchroon. Ik had net zo goed kunnen uitzoeken hoe ik die asynchrone zou kunnen aanspreken, dat lijkt me nog wel de moeite waard om te doen. Het is voor mij, in dit geval, onzin om zelf die klasse te schrijven om dat voor mij te doen...

De enige communicatie die de threads doen, is wanneer ze naar een list schrijven hoeveel downloads er gedaan zijn per thread, en een list met exceptions er opgetreden zijn. Om te kijken wat de server aan het doen is. Er wordt bijna niks gelockt.

Het geheugengebruik is wel bizar hoog, ergens las ik dat het om ongeveer 1 MB per thread gaat. Waarom is dat eigenlijk? Wat kan er nou zoveel geheugen in beslag nemen? Ik begrijp dat iedere thread zijn eigen geheugenruimte heeft maar zoveel is er niet nodig voor een WebClient object en wat variabelen.

@merv: stack?

OMG, aliens hebben dit topic ingenomen!

Ik ben zeer ingenomen met mijn alien.

Één WebClient() object per thread, een paar public strings met urls erin, en dan per thread synchroon het bestand downloaden.
De problematiek speelt zich achter de schermen af. Een thread krijgt typisch 1 tot 4 MiB toegewezen om privé-variabelen op te slaan (stack), elke socket heeft zowel een in- als een uitbuffer van 8 - 64 kiB, etc., en voor je het weet praten we over serieuze hoeveelheden geheugen. Verder zitten er aan de rokende serverkant 1000 sockets op je te wachten, en misschien ook wel 1000 threads of processen.

En dat alleen maar om 1000 keer "This side is top" te plempen.

Ik moet opbiechten dat ik totaal geen ervaring heb met CSP. Is Erlang een goede taal om hier meer over te leren?
Ik heb me vergist, ik was weer eens te slordig. Ik had het over Communicating Sequential Processes, maar Erlang gebruikt het alternatieve Actor model om concurrentie te modelleren. Actor model is hip.

Maar goed, ik kan je de taal sterk aanraden. Het is open source, robuust, heeft veel documentatie, het draait op Windows en Unices, je kunt er gelijk bruikbare dingen in maken, en tenslotte het heeft een leesbaar boek. Samengevat een ideale taal en omgeving om een betere software developer mee te worden. En je kunt er ook werk in vinden bij serieuze bedrijven.

/Alien

Alien was vroeger een lekker wijf!

Oh nee, Monade, dat zie je verkeerd... ik heb het over een endless loop (totdat de public shared Stop-boolean op True gaat, dat is). Daarbij hergebruik ik ieder WebClient object en de lokale variabelen. Dus per thread, als je het dan zo wil doen, is het best efficiënt. Ik zat eraan te denken om de download af te breken en niks binnen te halen maar dan test je maar een deel van je server.

Voor de grap laat ik ze allemaal tegelijk starten zodra de threads zich gereed gemeld hebben - bijna instant natuurlijk, maar ik laat ze wachten op een startsein omdat het kan.

Een toegevoegd probleem is de router, die gaat natuurlijk ook over z'n nek van zoveel TCP verbindingen. UDP is daar meer geschikt voor, maar HTTP draait nu eenmaal niet over UDP.

@Merv: hoeveel netwerk-interfaces heeft je machine?
Besef je dat er van die 1000 threads er 995 niks doen; geblockt zitten op input, daarbij elk 1MB aan geheugen vasthoudend ?

@merv: als je 't goed wilt doen, huur je een stuk of -tig EC2-instances die je met een dom scriptje een request laat uitvoeren. Als je 't echt goed wilt doen dan zoek je op hoe je contact kunt leggen met een botnet (of zelf je eigen botnet schrijft).

Oh, je bedoelde díe CSP. Nee dan ben ik with you, zeg maar.
Erlang steent. Echt. Functioneel (...) en je kunt er nog wat mee ook!

@Merv: HTTP kan prima over UDP - het is meer dat de webserverts dat niet accepteren. Natuurlijk wordt het er zo betrouwbaar van; je gaat ongetwijfeld (veel) dingen kwijtraken enz enz - maar dat ligt absoluut niet aan HTTP.

@wildplasser: Klopt, het verschil is te zien als je het aantal threads opvoert, op een gegeven moment gebeurt er dan niks extra meer. Om dat uit te zoeken heb ik het aantal threads variabel gemaakt. Hoe dan ook, in principe krijg je 65535 sockets (ofzo, in de praktijk natuurlijk niet) die allemaal een eigen verbinding met de HTTP server kunnen houden. En dankzij TCP blijven die open voor een tijdje. Maargoed, of dat nu echt werkt of niet, dat is de vraag. De meeste web servers hebben een limiet op het aantal gelijktijdige verbindingen.

@marjolein: Snap ik, je wil geen halve HTML pagina en als je refresht alleen de tweede helft, ofzo. Daar heeft niemand wat aan. Ik ga Erlang eens bekijken, dat kent toch meer praktische toepassingen dan Brainfuck...

I'll see your Brainfuck and raise you a hello world in 'whitespace':

Say hello.














































































































I'd rather ...

Ook. Ook? Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook.
Ook. Ook. Ook. Ook. Ook! Ook? Ook? Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook.
Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook? Ook! Ook! Ook? Ook! Ook? Ook.
Ook! Ook. Ook. Ook? Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook.
Ook. Ook. Ook! Ook? Ook? Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook?
Ook! Ook! Ook? Ook! Ook? Ook. Ook. Ook. Ook! Ook. Ook. Ook. Ook. Ook. Ook. Ook.
Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook! Ook. Ook! Ook. Ook. Ook. Ook. Ook.
Ook. Ook. Ook! Ook. Ook. Ook? Ook. Ook? Ook. Ook? Ook. Ook. Ook. Ook. Ook. Ook.
Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook! Ook? Ook? Ook. Ook. Ook.
Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook? Ook! Ook! Ook? Ook! Ook? Ook. Ook! Ook.
Ook. Ook? Ook. Ook? Ook. Ook? Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook.
Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook! Ook? Ook? Ook. Ook. Ook.
Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook.
Ook. Ook? Ook! Ook! Ook? Ook! Ook? Ook. Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook.
Ook? Ook. Ook? Ook. Ook? Ook. Ook? Ook. Ook! Ook. Ook. Ook. Ook. Ook. Ook. Ook.
Ook! Ook. Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook.
Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook! Ook!
Ook! Ook. Ook. Ook? Ook. Ook? Ook. Ook. Ook! Ook.

Het openhouden van connecties wordt ook niet echt op prijs gesteld, tenzij je ze hergebruikt. Ze iedere keer sluiten en heropenen is nog veel erger, daar is uiteindelijk connection: keep_open en setsockopt (SO_REUSEADDR) voor bedoeld. Die laatste is trouwens in strikte zin een protocol-violatie.

Maar om te stress-testen is dit wel een geschikte vorm van mishandeling, ja.

Het is een prachtige discussie, wat is beter, wie weet meer en waarover. Mijn vroegere baas kon daar eindeloos over praten. Mijn motto: "use the best tool for the job". Als je een hamer nodig hebt om een spijker in de muur te slaan, en je hebt alleen een baksteen, prima. Maar als je een heel huis bouwt, wordt het tijd een hamer te gaan kopen.

En zo ook met programmeren, Ook! en Whitespace zijn mind benders, niets meer dan sudokus met een output. Wel een goeie oefening, in de "kijken of het lukt" zin.

FTP gebruikt ook keep-alive commandos, daar is het wel zinvol omdat je niet uitgelogd wil worden halverwege een sessie.

Tuurlijk, het hele leven is een oefening. Voor het volgende leven.

Ik vind UDP voor HTTP-dinges helemaal niet zo gek eigenlijk. Vooral de combinatie jumbo-packets en AJAX. Als bijvoorbeeld omeBlues mij een refresh stuurt van de "U zei", dan past dat vast wel in een UDP-packet. Scheelt een hoop ping-pong.

FTP is anders, omdat het twee kanalen openhoudt: een voor data en een voor commandoos. Die keep-alive is protocol-gewijs niet nodig, de datapijp kan gewoon doorspuiten nadat de commandopijp al een timeout heeft meegemaakt.

Net of ik The Librarian zie programmeren!

@SO_REUSEADDR ... volgens mij zit je daar helemaal mis mee WildP. SO_REUSEADDR is bedoeld voor server sokkits - dat je meerdere luisteraars (accept(3)) op hetzelfde poortnummer kunt hebben. Wie dan de incoming connectie krijgt is dan maar de vraag. Kan tot 'interessante' resultaten leiden. SO_REUSEADDR heeft - in principe - volgens mij echt geen reet met open & sluiten van connecties te maken.

Als je REUSEADDR op client sokkits gebruikt zitten ze alleen in de weg als je bind(3) aan een port waar ook al een server op zit te luisteren - dan gooi je alles in de war. Niet aan te bevelen.

[uit m;n hoofd] Volgens mij was het hele idee achter REUSEADDR dat een socket zelfs na close een tijdje (20min) een OS-netwerkslot bezet houdt. Er zou immers nog een verdwaald segment binnen kunnen druppelen. REUSEADDR zorgt ervoor dat het netwerkslot hergebruikt mag worden door een andere nieuwe connectie. De nagekomen packets zullen met grote waarschijnlijkheid verkeerde seqnrs hebben.

[uit m'n hoofd; ik ga nu met Comer in de tuin zitten; er is nog net genoeg licht om het na te zoeken ...]

bijna goed. Ik kon het niet vinden in Comer, en Stevens is ook zeer summier (maar ik heb een oude druk, geloof ik)

Netjes. En dat is dus hoe een HTTP server de verschillende clients uit elkaar kan houden op dezelfde poort 80/443: de 5 tuple is steeds uniek.

Strikt genomen is het dus een uitzondering die alleen geldt als de sokkit in TIME_WAIT state is; dan hoeven {proto, local_adres, local_port} niet uniek te zijn. De 5-tuple moet nog steeds uniek zijn.

Dit was dus IIRC de reden dat HTTP 1.2 en connection: keep_open ingevoerd werden.

Juist, maar dat is ook de enige manier. Er is geen andere manier van addressering via TCP/IP. En als de status niet TIME_WAIT is, dan is het iets waar wat mee gedaan moet worden, data of commando's versturen/ontvangen enzo.

keep_open is vast fijn voor web-applicaties die zwaar op AJAX leunen

Ik heb me daar nooit erg in verdiept in her verleden, maar nmap/netstat geeft dat prachtig weer, wat je poorten aan het doen zijn. Ideaal! Nu heb ik daar kwa debuggen van mijn monster-client weinig aan, maar aan de server kant is dat erg zinvolle informatie.

Ik meen me te herinneren dat het ook de basis vormde van een DOS-attack (christmas-tree?) had ook iets met predictable sequence numbers te maken. Mijn kennis is erg vaag; zulk soort dingen zoek ik op op het moment dat ze langskomen, daarna vergeet ik het en herinner me alleen nog dat ik het ooit opgezocht heb...

@Merv: netstat -a geeft ook de socket state, IIRC.

Dat bedoelde ik, nmap is de unixversie nietwaar? En zo gaat dat toch, de ene keer help je Ketsbräu maken en de andere keer is het tijd om een packet sniffer uit de kast te trekken, omdat een applicatie niet wil updaten. Specialization is for insects, ja toch?

TCP state-diagram in Comer (staat ook wel ergens op de internets, medunkt) is trouwens uiterst verhelderend.
Kwa packet sniffer: ik heb ooit een TCP-relay gefabriekt (locale listen sokkit, doet actieve open(s) naar eigenlijke remote socket) EN LOGT ALLES. (iets soortgelijks schijnt ook met netcat te kunnen)
Toen wist ik nog niet dat packetsniffers bestonden, of ze waren er nog niet. Toch een uiterst leerzame exercitie, dat jongleren met een handvol netwerk-connecties.

[En het was vanavond zo’n mooi weer buiten…]
@Merv,
Dus per thread, als je het dan zo wil doen, is het best efficiënt.
De kernel alloceert die 1 MiB adresruimte per thread, en misschien vanwege performanceredenen ook daadwerkelijke geheugenpagina’s. Je zit dus het virtual memory systeem aardig te belasten. Met een beetje pech raak je op een 32-bit systeem zelfs aan je maximale geheugenruimte (31-bit of 32-bit). De netwerk sockets krijgen hun bufferruimte uit een pool in de kerneladresruimte, dus die ben je sowieso kwijt. 1000 client threads op 1 webserver is dus never nooit niet efficiënt.

Klopt, het verschil is te zien als je het aantal threads opvoert, op een gegeven moment gebeurt er dan niks extra meer.
Die threads komen gewoon niet meer aan de beurt of de benodigde resources (sockets en file handles) raken voortijdig op.

@Wildplasser,
De socket timeout heeft inderdaad niets met SO_REUSEADDR te maken. Zie W.R. Stevens "Unix Network Programming Vol 1" Ch 7.5 p 194-197 voor een buitengewoon heldere uitleg.

@marjolein,
Als je poll/select gebruikt heb je bij voorbaat de performance-race al verloren
We hadden het meer over de client niet uit de lucht blazen, maar je verplaatst het wake-up probleem alleen maar. Ik heb het niet getest, maar ik verwacht dat een userland thread-wakeup duurder is dan select collision in kernel mode.

/Gaat weer verder met zijn Grolsch

@monade: ik heb dus alleen de oude (een delige) versie van wrs.

mbt Marjolein's rant versus select/poll ben ik het wel met je eens denk ik.
De problemen bij select/poll zijn dat je eerst een heel grote FD_SET moet bevolken (en steeds kopieeren), en dat de kernel hem bij iedere select() syscall moet kopieren naar een soortgelijke struktuur in kernelland. Dat vergt enkele lineaire passes door een N=1000 array. Op zich niet zo erg; het wordt pas erg als select() iedere keer returnt voor een readable filedescriptor. Dan kom je uit op twee syscalls (waarvan een heel duur) voor iedere te lezen buffer.
Er zijn wel trucjes (meer dan een fd_set, de actieve fds apart houden), maar het blijft behelpen.
Poll() is aan de userspace-kant iets vriendelijker, maar aan de binnenkant gebeurt er feitelijk precies hetzelfde.

Ik heb ooit een keer met SIGIO gespeeld, maar dat impliceert dat je alles moet mutexen en continu met sigprocmask aan het flipperen bent. Malloc() in een signalhandler is bijvoorbeeld niet zo'n goed idee, zodat je moet prealloceren. En die pool moet ook weer gemutexed worden, etc. Wel een leuke sport, dat dan weer wel.

ik heb dus alleen de oude (een delige) versie van wrs.
Dát is oud. Mijn exemplaar is van 19/11/1998. Mijn god, alweer 13 jaar geleden! Retecool bestond toen nog niet eens.

Ik ben sinds 2005 niet meer echt met dit soort dingen bezig, maar volgens mij is C10K nog steeds de beste bron voor basis informatie over high-performance socket programming.

En @Merv, ik zou eens kijken naar thttpd for Windows. Fantastisch hufterproof webserver voor statische pagina’s.

1990. Er staan zelfs nog old-style functie-argument dingessen in! Mijn APUE is uit 1992 en heeft al ANSI/c89 prototypes.
c10K is inderdaad the way to go, als je de limieten wilt opzoeken.

Een van de grootste beperkingen van select/poll (onder Loonix dat is) is het feit dat als je die systemcall ingaat je in het gunstigste geval 10ms later pas weer aan de beurt bent.

De loonix scheduler loop op 100Hz (=10ms)(*) en als je een blocking select/poll met timeout doet word het aanroepende proces in de wachtrij gezet en op z'n vroegst 10ms later verherevalueerd of er iets te runnen valt. Zelfs als een timeout van 1ms hebt ingesteld.
Vaker komt het voor dat je pas na twee timeslots (20ms later dus) weer aan de beurt komt.

(*) ja dat is wel aan te passen maar dan krijg je weer te veel contextswitches en gaat daar je performance down the drain.

Ik dacht dat het om throughput ging, gaat het om latency. Pfft, vrouwen...

Volgens mij is dat minstens een timeslot wachten strikt genomen niet waar, kzal het straks op m'n werk even nazoeken in de src. Dat bij return-from-syscall de scheduler kan toeslaan is duidelijk.

als je een blocking select/poll met timeout doet word het aanroepende proces in de wachtrij gezet en op z'n vroegst [1/schedfreq] later verherevalueerd of er iets te runnen valt
Dat klopt, maar dat wachten is niet zo erg omdat select() blocked totdat er iets te schrijven of te lezen valt. Zolang kun je toch niets doen met die connecties. Zoals @Wildplasser zegt, beïnvloedt dit voornamelijk de latency, en niet direct de daadwerkelijke throughput.

Een userland threadswitch is vele malen sneller (orden van ns op Solaris en FreeBSD), maar ik zou zo niet weten wat er met de scheduling van een proces gebeurt als één van zijn threads lang blocked in een system call. (Ik heb het materiaal wel liggen, maar ik ga dit nu niet uitzoeken als je het niet erg vindt.)

/man 8 alien

Zijn de Unix varianten niet pre-emptive dan? Een user process wordt toch gewoon afgekapt en weer opgeraapt als het tijd is? In tussentijd zou je dus ergens een buffer aan het vullen zijn, ergens in de netwerkhardware...

In de praktijk nauwelijks.
Het meeste schedulen vindt plaats net voor de return_from_systemcall. Dat is het goedkoopste: de machine zit toch in ring0, en moet toch terug naar userspace; het enige wat ie hoeft te doen is returnen naar een *ander* userprocess; wel met de juiste context. Systemcalls komen zodanig vaak voor (duizenden per seconde) dat de preemption alleen maar optreedt voor processen die alleen maar rekenen en geen systemcalls plegen.

Hoe dan ook, het is maar net wat je wil testen. Zelf dacht ik eraan om bijvoorbeeld gewoon zoveel HTTP requests als mogelijk te doen, en die dan af te kappen - nadat de server was begonnen antwoord te geven gewoon afbreken. De server heeft dan al het werk al gedaan (php geparsed, databases gequeried) - uiteraard bypassen we de cache voor zover mogelijk.

Voor maximale bandbreedte is het makkelijk genoeg: vind een paar grote bestanden met de developer tools in je browser, en dan flink downloaden. Zit je zo aan de maximale snelheid voor dat systeem. Zo kwam ik tot ongeveer 20 of meer MBps voor de SimpleServer:WWW, ik weet dat het een onstabiele server is en dat kon ik nu dus mooi bewijzen.

Je zou ook een hybrid kunnen bouwen waar verschillende taken tegelijk worden uitgevoerd.

Ik dacht dat het een keiharde regel was, een gegarandeerde context switch. Interessant. Natuurlijk zijn realtime operating systems daar compleet anders mee, daar heb ik helaas nooit mee gewerkt. Of geldt MS-DOS als een realtime OS?

…bovendien gebruik je de select() system call in jouw geval om erachter te komen dát er een netwerk buffer is gevuld, en die lees je vervolgens uit (door de inhoud het al dan niet slim te kopiëren naar userland).

De context-switch is op zich wel gegarandeerd, maar het is niet-deterministisch. MSD-DOS is niet real-time; het kan niet eens fatsoenlijk de tijd bijhouden.

Ik kan me nog herinneren dat mijn Gravis Ultrasound geluidskaart moeilijkheden gaf als-ie op de verkeerde interrupt stond. 7 was soms beter dan 5 of andersom... wat een drama was dat.

ik weet dat het een onstabiele server is en dat kon ik nu dus mooi bewijzen.

Het zou mij niets verbazen als een ongetunede apache ook onderuit gaat bij 1000 requests in een piek. Kijk maar naar al die sites die 'geslashdotted' zijn.

Het zou mij niets verbazen als een ongetunede apache ook onderuit gaat bij 1000 requests in een piek.
Neu. Apache krijgt bij een piek geen vrije poorten meer vanwege de lingering close, zoals eerder gemeld door @Wildplasser, maar hij valt niet om. De PoeHP en database dingeses kunnen misschien omvallen, maar dat heb ik nooit getest.

Sure?

Afgezien daarvan, ik heb met apache onder windows al het genot mee mogen maken van een apache die crasht op een foutje in httpd.conf.

Als je het stukkie doorleest zie je dat het apacheproces wordt afgeschoten omdat het over de proceslimieten heengaat. Dat is geen crashen. Crashen is als een programma zichzelf de vernieling in helpt.

/En je kunt apache zeker laten crashen, zeker de 2.x generatie, toen de linuxmannetjes zich met het ontwerpen(FSLVO) en programmeren begonnen te bemoeien.

“…bovendien gebruik je de select() system call in jouw geval om erachter te komen dát er een netwerk buffer is gevuld, en die lees je vervolgens uit ...”

Dat levert dus een gevaar op, dat continue op de loer ligt: systemcalls zijn relatief duur (1K tot 10K clocks) dankzij alle cache en TLB invalidatie (nog te zwijgen over locks en barriers), en er is dus het risico dat een select() met een fd_set van een paar duizend maar een readable (of writable) fd oplevert. Dat is dan een heel duur blok wat je gelezen hebt.

Ik heb trouwens geen bewijs kunnen vinden voor Marjolein's latency-claim. Volgens mijn korte inspectie doen select()s internals precies een sweep over de fd's en worden alle fds gerapporteerd die (op dat moment) leesbaar/schrijfbaar zijn. (If any; anders wordt er gewacht)
De return is dan onmiddelijk, en dus niet op de metronoomslag.
Hij is wel op de metronoomslag indien er timeout plaatsvindt. (de timing is trouwens in linux veranderd, rond 2.6.30 ofzo)
Hij is niet op de metronoomslag als er een signal optreedt.

Dat is geen crashen.

Definitiegezeur.

@marjolein’s Latency zijn de extra wachttijden die aan het daadwerkelijke datatransport worden toegevoegd als gevolg van een contextswitch:

t = 0: kan naar geen enkele fd schrijven: yield.
[contextswitch naar n andere processen]
t = n*10 ms: kan schrijven naar fd’s: doe dit.
Latency = delay over het kanaal + n * 10 ms.

On dit te testen moet je aan de ontvangende kant spelen met delayed ACKS en dergelijke.

Definitiegezeur.
Nee, want door alles maar crashen te noemen maak je het concept zinloos. Een crash is een ontwerp- of een programmeerfout. Procesterminatie vanwege limietoverschrijding is een administratieve beslissing.

/Waarom weet ik dat allemaal nog?

Los van de definitie: het lijkt erop dat de apache in gronks linkje zichzelf ophangt door resource-schaarste. Misschien zelfs filedescriptors. Ik heb geen verstand van windows (ze houden nogal van pre-allocatie in Redmond) , het lijkt me b.v. onvertandig om meer connecties te configureren dan je aan filedescriptors hebt. Memory is ook zoiets, maar nog veel erger.
Max_requests_per_worker (of hoe die ook heet) is een gore hack, maar wel redelijk effectief tegen lekkage.

Hoe zit dat trouwens bij multiprocessor en hyperthreading systemen? De CPUs lopen tegenwoordig niet meer precies gelijk omdat dat niet meer bij te houden valt met die gigahertzen. Dat heeft men toen wel een tijdje geprobeerd nog met de Pentium Pro, dacht ik. Je kunt meerdere threads op verschillende cores draaien, en dat hoeven geen echte processen te zijn, toch?

Op zich kan ik het wel volgen dat als CPU core 2 een thread uitvoert die wil schrijven naar een gelockt object vanwege een thread op core 1, dat het niet gaat en moet wachten op de volgende switch. De kernel zorgt er dan voor dat dit allemaal een beetje in de pas blijft lopen, nietwaar? Op die manier verspil je wel veel tijd natuurlijk, je bent beter af als je verschillende processen hebt met elk meer geheugen om hun eigen zaakjes beter te kunnen afhandelen. Minder vaak schrijven naar gezamelijke objecten.

Monade heeft wel gelijk mbt crashen: terminatie is gewoon "by design", daar valt niet over te twisten. Slecht applicatiedesign -> crash, is ook by (bad) design, maar niet zo bedoeld. Geen geplande feature.

@monade: ik heb geprobeerd een proof-of-concept programmaatje te schrijven voor Marjolein's latency-dinges. Opzet: een cascade van sockets naar poort 7 (echo), allemaal in dezelfde select() dinges. Bucket-brigade.
Doel: kopieer stdin naar stdout met maximale latency ;-)

Hoe zit dat trouwens bij multiprocessor en hyperthreading systemen?
Huilen met de pet op. Gemaakt om mij te pesten.

Vandaar dat ik je een taal als Erlang aanraadt om mee te spelen.

Multi-processor werkt voor het grootste gedeelte prima in de kernel.
User processen mogen zelf weten wat ze aanrotzooien, meestal wordt dat een beetje door de taal of de "omgeving" gefaciliteerd.

Honingraadt. Hehe. Maar zonder gein: ik heb er serieus over gedacht eens wat met CUDA te rotzooien, dan kun je zoveel threads aan het werk zetten dat het puur een mind bender wordt. Op zich een aardig idee om eens uit te zoeken, maar ik weet niet hoeveel tijd ik daar eigenlijk in wil gaan stoppen... Er is natuurlijk ook nog zoiets als het concept van "daglicht" en "buiten".

Maar Erlang klinkt als iets dat de moeite waard is om gewoon even te proeven, het concept te begrijpen. Lijkt me best interessant.

Wat wildplasser zegt. Ik maak uit dat linkje niet op of apache actief afgeschoten wordt of dat apache klapt omdat-ie ergens geen geheugen meer kan alloceren. Gezien 't feit dat apaches kunnen crashen op configfiles zonder ook maar een enkele hint te geven zou ik niet bij voorbaat durven zeggen dat het laatste niet het geval is.

OTOH, waarom dat gemiereneuk? De test van merv was 'of je webserver na x seconden uit de lucht is'. Een setup met wat extra logica die automagisch je apache restart kan net zo goed een simpleserver herstarten.

Het is voor een niet triviale applicatie (webserver met heel veel modules en dependencies, DMBS) ook niet makkelijk om goed met iedere foutconditie om te gaan. Hangen zou altijd te vermijden moeten zijn, in het uiterste geval is "fail-fast" de enige optie. Bij een DBMS kost dat een (relatief dure) recovery, bij een webserver is iedereen alleen maar zijn sessie kwijt. (bij een DBMS ook, uiteraard)

@gemierenneuk: dat soort discussies doet me altijd denken aan http://xkcd.com/761/. Prachtig.

@merv: threads zijn geen panacee. Er zijn constellaties denkbaar waarbij een (of meer) mutex werkt als "funneling" hotspot, en er in feite een convoy (van N=1) plaatsvindt. N-1 threads staan dan te wachten. Ontwerpen is een kunst.

Als Merv's enige doel is om een webserver te stressen, dan hoeft ie niet veel grote paginaas op te halen. Beter is om gelijk na het eerste gelezen blok de connectie al te termineren. Dan mag de webservert de boel opruimen.

[MIjn god, dit is 6 jaar geleden en buiten is het 20 graden!]
ik heb geprobeerd een proof-of-concept programmaatje te schrijven voor Marjolein’s latency-dinges.
Je moet aan de ontvangende kant spelen met ACKS en window sizes. Daar bestaan vast en zeker nog steeds testtooltjes voor.

waarom dat gemiereneuk?
Omdat je de juiste oorzaak wil weten. Zoals ik al schreef kun je met het grootste gemak een service uit zijn resources laten lopen, bijvoorbeeld geen beschikbare netwerkpoorten of onvoldoende werkgeheugen. Daar kan een service op crashen omdat daar geen rekening mee is gehouden, of van zichzelf terugschalen (graceful recovery) of zichzelf termineren, of door het os worden getermineerd. Drie verschillende redenen.

Ik haat met grote haat Windows en MacOSX omdat zij fault discovery buitengewoon moeilijk maken.
"Er ging iets mis." "Joh!"

Ja! die TCP window-discovery-dinges. Daar ga ik morgen mee spelen!
(als het mag van de baas)
Gracefull discovery is gewoon moeilijk. De OOM-killer is not fair!

Bij een deadlock-detected in DBMS kan je nog een cost-based afweging maken (de transactie die al de meeste resources heeft gebruikt mag blijven leven, of de jongste moet dood) Maar er zijn altijd uitzonderingen.

Threads zijn zeker geen panacee, daar heb je natuurlijk helemaal gelijk in. Maar ze zijn wel noodzakelijk als je goeie responsive GUIs wil schrijven, en in mijn ogen is een slecht reagerende GUI zo ongeveer het ergste wat een ontwerper kan doen met zijn software.

Een collega van mij had er jaren geleden de grootste moeite mee, en zelf heb ik er nooit genoeg tijd voor genomen om te kijken hoe de communicatie werkt, locking van objecten, dat soort zaken. Van dit experiment heb ik geleerd waar sommige limieten zitten, wat praktisch is, en "en passant" heb ik een applicatie waar ik wellicht ooit nog wat mee kan. En daar ben ik best tevreden mee.

en nu de link naar de sln ;)

Ja... heb m'n partitie verkloot met de Paragon Alignment Tool eergisteren (Intel SSD) en nu krijg ik "A disk error has occurred. Press CTRL+ALT+DELETE to restart." Daar ben ik nu alweer twee dagen zoet mee. Ben dus gewoon tijd aan het rekken hier in het forum...

Ik heb wel een volledige backup en 1:1 image op een laptop HDD, die gek genoeg wel boot - maar daar kan ik niet mee leven. Eerst die SSD weer aan de gang! Na uren met CloneZilla, GParted en UBCD wordt het een beetje flauw zo langzamerhand. De MBR is in orde, maar niemand schijnt me te kunnen vertellen waar deze foutmelding precies optreedt - waarschijnlijk het BIOS want Linux gebruikers hebben hier soms ook mee te maken. We zullen zien.

@Merv Als je dan toch niet kan proggen, is het misschien leuk om eens wat op Reed Copsey s site rond te neuzen. Erg leerzaam. (tenminste voor mij ;)

Ja daar begon ik in eerste instantie mee, met Tasks, en toen kwam ik er achter dat dat niet deed wat ik wilde. Voor normale GUI taken is het ideaal natuurlijk! Dan ken je Parallel.For() zeker ook.

CUDA, Supercomputing for the Masses is wat ik eerst wilde gaan proberen.

Inmiddels heb ik Marjolein's claim dat select() n*HZ verbruikt ontzenuwd.

De tijd verstookt inside select() is 10 tot 30 us, dit bij een fd_set size van 50, bij returnvalue>0, dus zonder timeout of error. Af en toe ietsje hoger (~100us, waarschijnlijk door een spinlock) en Zeer zelden 10 of 20 ms, kennelijk door een concurrerend proces in de runqueue.

This myth is debunked.

De src van de POC staat hierr.

Dat klinkt redelijk, ik weet dat context switches duur zijn maar in de milliseconden lijkt me onredelijk - bij 10 ms en 100 threads zou je thread dan minder dan 1 keer per seconde aan de beurt komen.

/vergeten te schrijven
Ik heb mijn systeem weer bootende - de partitie wilde echt niet meer starten, geen fixboot of fixmbr die daar wat aan kon doen. Heb toen XP SP3 maar gewoon vers geïnstalleerd. Vanavond kan ik dus teh codes online plempen voor hullie! Begrijp wel dat ik schrijf in VB.NET, dus het is niet sexy om te zien.

Oh en de Marjolein-buster-POC staat inmiddels hiero. Ik was denk ik weer eens het finish-knoppie vergeten te beroeren.

Hierr, Marjolein.

Erik en Arjan Snippe waren zowat de slechtste studenten van hun jaar @WP.

Een tweeling? Dus wel redundant uitgevoerd!

@echoputtentest van WP: interessante test.

Helaas lijkt'ie waarschijnlijk helemaal niet op de situatie waarin ik die waarneming gedaan heb. Ik denk dat de situaties dermate ongelijk zijn dat ik met geen mogelijkheid kan zeggen wie er nu representatief is.

In mijn geval was dat sowies met een Linux 2.4 kernel, multithreaded applicatie en werkelijk netwerkverkeer (remote host ipv via het loopback device).

Remote vs local hangt voor de tijd die besteed wordt inside select() niet uit. (de round-trip-tijd echo telt hier niet mee)
Hier op mijn HubertStation-2 is ie nog sneller, trouwens: 1 tot maximaal 6 us, voor resp ca 10 tot bijna 100 fds returned.
1us is 1000 clocks bij een 1GHz clock, en dat is dus echt afgrijselijk snel voor een systemcall.

[ HS-2 is 3.2 GHz, geloof ik, maar meestal is dat 4*800 MHz, waarbij die vier de pijplijn-factor is, en de 800 de echte clocktick. Boerenbedrog aka "muziekvermogen". ]
Kan goed zijn dat 2.4 slomer was, of langer dan strikt noodzakelijk in de systemcall bleef.

s/hangt voor/maakt voor/

echoputcascadepoepen is trouwens alleen maar een hack om een hele trits sockets te openen en er aktieve fd_sets mee te bevolken. Ik betwijfel of een miltithreaded variant significant sneller zal zijn, het aantal systemcalls is gelijk, en waarschijnlijk zullen de in-kernel mutexes het gedrag omvormen tot bijna-singlethreaded.

Pfft ooit dacht ik dat het hier compleet inteelt was, maar daar voor worden er teveel tekens getypt! De oude garde was nooit zo lang (en droog) van stof. Waar is iedereen???