[alg] kan een server dit aan?

[codemann]

Ik zou uit de database van mijn sms daemon de nieuwe berichten moeten parsen en afhankelijk van de inhoud moet er dan iets gedaan worden, bijvoorbeeld een email sturen.

Ik zou in de database van de daemon regelmatig (om de 10sec ongeveer) kunnen controleren op nieuwe binnenkomende sms'en. Dit met bijvoorbeeld een vbscript met windows scripting host en scheduler.
Maar ik kan mijn daemon ook aanpassen zodat als er een nieuwe sms binnenkomt dat er dan een asp pagina op een andere server wordt aangeroepen, die dan de nieuwe sms verwerkt. Mijn enige vraag is of een server dit altijd zal aankunnen? Ik kan mij inbeelden dat als er héél veel sms'en tegelijkertijd worden gestuurd en elke keer deze asp pagina wordt aangeroepen dat dan de server waarop deze asp pagina staat de requests niet verwerkt krijgt of dat er misschien fouten gaan voorkomen omdat het te snel op elkaar volgt.
Indien dit is ga ik voor mijn eerste methode gaan (scheduler). Maar anders is het aanpassen van de daemon de beste oplossing lijkt me.

Iemand die toevallig ervaring heeft met zo'n groot aantal requests? Of iemand die me van deze twijfel kan verlossen? Alvast bedankt!

[thomaske]

Daar is niets over te zeggen zonder technische details van
• configuratie van de server
• snelheid / 'zwaarte' van het script

Je kan natuurlijk Benchmarken hoeveel requests jouw server aankan, dan weet je het meteen.

En is het niet mogelijk om in je daemon een soort van buffer in te bouwen, die ervoor zorgt dat de server niet overbelast raakt ?

[ Voor 49% gewijzigd door thomaske op 15-04-2004 13:34 ]

[Soultaker]

Je verhaal mist een inleiding. Wat achtergrondinformatie zou handig zijn; hoeveel berichtjes verwacht je op drukke momenten per minuut? 10, 100, 10.000?

Zelf zou ik in verband met de betrouwbaarheid een laag invoegen tussen het ontvangen van berichten en het verwerken ervan. Je hebt blijkbaar een programma dat SMS berichten ontvangt en parset; dat programma kan ze dan in een database zetten. Veel databases hebben een apart 'queue' databasetype voor dit doel. Tegelijkertijd draai je een programma dat niets anders doet dan continue berichten uit de queue halen en ze verwerken (emails vesturen bijvoorbeeld).

Beide programma's hoeven zo steeds maar met 1 bericht tegelijk te werken en hiermee voorkom je dat je problemen krijgt doordat je teveel parallelle processen hebt draaien. Als het systeem tijdelijk (te) zwaar belast wordt dan groeit het aantal berichten in de wachtrij, maar verder heeft de server geen last van overbelasting en kun je berichten op volle snelheid blijven ontvangen. Uiteraard moet die overbelasting niet structureel zijn, maar ik denk eerlijk gezegd dat dat geen zal zijn.

Deze constructie is vooral nuttig als de verwerking van het bericht relatief kostbaar is. Als het alleen om het versturen van een mailtje gaat, kun je met een geschikte mailserver (iets als qmail, die razendsnel berichten kan injecteren in de mailqueue) wel alles in één stap doen en jezelf een hoop ellende besparen met databases.

[ Voor 14% gewijzigd door Soultaker op 15-04-2004 13:36 ]

[codemann]

thomaske schreef op 15 april 2004 @ 13:32:
Daar is niets over te zeggen zonder technische details van
• configuratie van de server
• snelheid / 'zwaarte' van het script

server: HP DL380 - Xeon 2.4Ghz - 1GB RAM
script: inkomende sms (= een string) parsen en in eerste instantie alleen een sms terugsturen; een sms terugsturen betekent naar de sms-server een INSERT statement sturen

deze server zit samen met de sms-server achter een aparte switch, het is dus interne trafiek; ik maak me ook enkel zorgen of het mogelijk is dat er zo veel requests tegelijkertijd kunnen komen dat de communicatie tussen deze 2 servers verkeerd kan gaan lopen?

[codemann]

Je verhaal mist een inleiding. Wat achtergrondinformatie zou handig zijn; hoeveel berichtjes verwacht je op drukke momenten per minuut? 10, 100, 10.000?

Worst case scenario... Je weet nooit wat je te wachten staat, het moet alles aankunnen, mag nooit fout gaan

Zelf zou ik in verband met de betrouwbaarheid een laag invoegen tussen het ontvangen van berichten en het verwerken ervan. Je hebt blijkbaar een programma dat SMS berichten ontvangt en parset; dat programma kan ze dan in een database zetten. Veel databases hebben een apart 'queue' databasetype voor dit doel. Tegelijkertijd draai je een programma dat niets anders doet dan continue berichten uit de queue halen en ze verwerken (emails vesturen bijvoorbeeld).

Beide programma's hoeven zo steeds maar met 1 bericht tegelijk te werken en hiermee voorkom je dat je problemen krijgt doordat je teveel parallelle processen hebt draaien. Als het systeem tijdelijk (te) zwaar belast wordt dan groeit het aantal berichten in de wachtrij, maar verder heeft de server geen last van overbelasting en kun je berichten op volle snelheid blijven ontvangen. Uiteraard moet die overbelasting niet structureel zijn, maar ik denk eerlijk gezegd dat dat geen zal zijn.

Deze constructie is vooral nuttig als de verwerking van het bericht relatief kostbaar is. Als het alleen om het versturen van een mailtje gaat, kun je met een geschikte mailserver (iets als qmail, die razendsnel berichten kan injecteren in de mailqueue) wel alles in één stap doen en jezelf een hoop ellende besparen met databases.

Ok, dit ga ik eens bekijken, bedankt voor je tip al!

[curry684]

codemann schreef op 15 april 2004 @ 13:38:
[...]

Worst case scenario... Je weet nooit wat je te wachten staat, het moet alles aankunnen, mag nooit fout gaan

Met een worst-case van 10 miljard berichtjes per seconde is het antwoord op je vraag simpelweg: nee.

Je zult een realistische schatting moeten maken van verwachte traffic, die met 2 of 3 vermenigvuldigen en daarop moeten instellen. Oftewel: emuleer middels een scriptje oid die hoeveelheid load en kijk hoe een en ander zich gedraagt.

[Alarmnummer]

Soultaker schreef op 15 april 2004 @ 13:34:
Je verhaal mist een inleiding. Wat achtergrondinformatie zou handig zijn; hoeveel berichtjes verwacht je op drukke momenten per minuut? 10, 100, 10.000?

Zelf zou ik in verband met de betrouwbaarheid een laag invoegen tussen het ontvangen van berichten en het verwerken ervan. Je hebt blijkbaar een programma dat SMS berichten ontvangt en parset; dat programma kan ze dan in een database zetten. Veel databases hebben een apart 'queue' databasetype voor dit doel. Tegelijkertijd draai je een programma dat niets anders doet dan continue berichten uit de queue halen en ze verwerken (emails vesturen bijvoorbeeld).

Beide programma's hoeven zo steeds maar met 1 bericht tegelijk te werken en hiermee voorkom je dat je problemen krijgt doordat je teveel parallelle processen hebt draaien. Als het systeem tijdelijk (te) zwaar belast wordt dan groeit het aantal berichten in de wachtrij, maar verder heeft de server geen last van overbelasting en kun je berichten op volle snelheid blijven ontvangen. Uiteraard moet die overbelasting niet structureel zijn, maar ik denk eerlijk gezegd dat dat geen zal zijn.

Deze oplossing is ook wel bekend onder de naam : Reactor, waarbij de database is vervangen door een Queue en je mbv een semafoor een afhandelthread alles aan de achterkant laat lezen en verwerken. Het voordeel is dat je bijna niet meer hoeft te letten op concurrency control. Maar het nadeel is dat alle aanroep dus sequentieel plaatsvinden en dat een zware bewerken (denk niet dat dat hier van toepassing is) de verwerkingen van de latere berichten behoorlijk kan vertragen.

Deze constructie is vooral nuttig als de verwerking van het bericht relatief kostbaar is. Als het alleen om het versturen van een mailtje gaat, kun je met een geschikte mailserver (iets als qmail, die razendsnel berichten kan injecteren in de mailqueue) wel alles in één stap doen en jezelf een hoop ellende besparen met databases.

Je moet juist erg uitkijken met grote berekeningen doordat het de verwerking van andere berichten behoorlijk kan vertragen. Alleen als je een post-and-forget situatie hebt, dan maakt het idd niet uit of die jobs een tijd lang op zich laten wachten.

Als je trouwens meerdere 'trage' onderdelen hebt zoals mailen, dan zou je er aan kunnen denken om de reactor hier ook op toe te passen zodat het systeem meerdere taken naast elkaar kan doen (en niet blijft haperen op lange pauzes zoals je misschien bij het mailen kan aantreffen)

[ Voor 35% gewijzigd door Alarmnummer op 15-04-2004 14:02 ]

[Soultaker]

Ik wil nog even benadrukken dat het injecteren in een mail queue meestal geen 'trage' operatie is. Het daadwerkelijk versturen van de mail is dat wel, maar meestal handelt een afzonderlijk proces dat af. Feitelijk is in die situatie al sprake van twee gescheiden processen met een queue ertussen.

[codemann]

Even wat zitten overleggen met mijn collega... Wat vinden jullie hier van :

Ik heb niet onmiddellijk controle over de mysql database die er op de server draait en dit is een opgeleverd project, dus ik ga als het mogelijk is hier niet te veel aan laten veranderen. Aangezien het cross-server is en ik nog flexibiliteit voor latere toepassingen wil houden heb ik dit in gedachte : ik laat de sms-server een pagina op de sms-server zelf oproepen met als id de id van het juist in de database weggeschreven nieuwe bericht. Deze gaat als een soort queue dienen. In het kort: als er geen berichten zijn dan roept hij een pagina op op de andere server (de server waar de toepassing op draait) en vanaf dan tot het moment dat hij een done krijgt stopt hij alle nieuwe sms'en in een queue (een simpel tekstbestandje). Als hij dan een done van de andere server krijgt gaat hij die queue doorsturen en weer wachten op een done. En zo verder...

Op deze manier vermijd ik dat ik vanaf de daemon cross server moet gaan werken (als ik dat zou doen zou ik voor elke nieuwe toepassing ook een verandering van de daemon moeten aanvragen). Ook is het wegschrijven naar een tekstbestand lijkt me veel minder zwaar dan op een andere server een pagina aan te roepen die een string moet gaan opvragen/verwerken en een email sturen. En als ik later nieuwe toepassingen wil maken dan moet ik het asp/php script gewoon aanpassen en moet er niks veranderd worden aan de daemon.

Wat denken jullie hier van?

[Alarmnummer]

Soultaker schreef op 15 april 2004 @ 14:25:
Ik wil nog even benadrukken dat het injecteren in een mail queue meestal geen 'trage' operatie is. Het daadwerkelijk versturen van de mail is dat wel, maar meestal handelt een afzonderlijk proces dat af. Feitelijk is in die situatie al sprake van twee gescheiden processen met een queue ertussen.

Volgens mij lopen we elkaar dingen te vertellen die we al lang weten

[MSalters]

Ik krijg overigens wel het gevoel dat er iemand las heeft van het hamer-spijker syndroom. Wat doet ASP in dit hele verhaal? Windows Scripting Host? Meerdere servers? Databases?

Een SMS komt van een SMS modem of een SMS centrale, dat is dus via een RS-232 of IP binnen op je server, en gaat over een van de twee kanalen terug. Ik begrijp dat je dit afschermt met je daadwerkelijke "SMS-server". Mijn eerste gedachte is dat die machine I/O bound zal zijn op z'n SMS kanalen, dus dat je gewoon alle logica op die machine erbij kunt zetten. Meer dan 100 SMSjes per seconde gaat je backend toch niet versturen, en dat geeft je dus grofweg 24 miljoen klokcycli per SMS.

Als je de logica per se naar een andere machine wil verplaatsen, gebruik dan een named pipe (ASP impliceert Windows) en gebruikt dat als je queue mechanisme. Writes van de SMS server naar je applicatie server zijn dan je inkomende SMSjes, writes de andere kant op de uitgaande. Niks scheduler, je doet gewoon een blocking read tot je de SMS binnen hebt.

code:

while( not exited )
{
  Blocking Read (pipe, inSMS )
  outSMS = default.reply
  ouSMS.destination = inSMS.source
  SendStandardReply ( pipe, outSMS )
}

en in niet-pseudo code is het waarschijnlijk ook die 7 regels.