[java/alg] sockets openen, duur?

[Alarmnummer]

Heeft iemand een idee hoe duur (qua wachttijd) het is om een socket te openen?

[Jigs]

Alarmnummer schreef op donderdag 18 november 2004 @ 16:30:
Heeft iemand een idee hoe duur (qua wachttijd) het is om een socket te openen?

Hoe lang in wachttijd? Volgens mij duurt dat niet zo lang!

[Alarmnummer]

Jigs schreef op donderdag 18 november 2004 @ 16:35:
[...]


Hoe lang in wachttijd? Volgens mij duurt dat niet zo lang!

We moeten namelijk grote hoeveelheden connecties aangaan met grote hoeveelheden servers (smtp servers). De vraag is of het handig is om de sockets te gaan hergebruiken en ze dus niet iedere keer opnieuw aan te maken.

[simon]

Ontlast je de server niet veel meer om socket connecties geopened te houden? Dat hoor je ook altijd met php

[Sjaaky]

Het enige dat je wilt besparen is dus de sockfd = socket(AF_INET, SOCK_STREAM, 0); call? Want hierna doe je een connect() en een geconnect socket kan je niet hergebruiken naar een andere smtp-server (tenzij je hem weer disconnect?).
Connection-pooling wordt zover ik weet alleen gebruikt als beide partijen vantevoren vast staan (bijv. webapp <-> databaseserver).
Bovendien lijkt mij de tijd die het kost om de hostname te resolven en te connecten met de smtp-server zo veel groter dan het aanmaken van het socket dat het niet loont om dit te optimaliseren.

[Alarmnummer]

Sjaaky schreef op donderdag 18 november 2004 @ 16:48:
Het enige dat je wilt besparen is dus de sockfd = socket(AF_INET, SOCK_STREAM, 0); call? Want hierna doe je een connect() en een geconnect socket kan je niet hergebruiken naar een andere smtp-server (tenzij je hem weer disconnect?).

De bedoeling is om meerdere mails naar 1 smtp server in 1 batch over 1 socket te gaan verzenden. Nadat die batch klaar is, kan de socket weer getrashed worden. Het is verder niet de bedoeling dat die sockets voor een lange tijd herbruikt worden want je zit met de MX-records van mailservers dat je niet altijd gebruik maakt van de beste server en na die batch wil je het weer opnieuw proberen.

DUs om een lang verhaal kort te maken.. ik wil dus meerdere smtp kletspartijen (batch)gaan delen over 1 en dezelfde socket en daarna mag de socket getrashed worden.

Bovendien lijkt mij de tijd die het kost om de hostname te resolven en te connecten met de smtp-server zo veel groter dan het aanmaken van het socket dat het niet loont om dit te optimaliseren.

DIe worden al gecached. Netzoals de MX records. (En worden weer geremoved als geen enkele MX records deugde om een connectie mee te maken)

[Sjaaky]

Een smtp server accepteert meerdere mails in 1 connectie. In exim is dat standaard gelimiteerd op 1000 mails per connectie. Bovendien lijkt mij het maken van een socket veel korter qua tijd dan het maken van een connectie. Je kan uiteraard proberen je socket te behouden, maar je weet wat ze zeggen over voortijdige optimalisaties.

[Alarmnummer]

Sjaaky schreef op donderdag 18 november 2004 @ 17:15:
Een smtp server accepteert meerdere mails in 1 connectie. In exim is dat standaard gelimiteerd op 1000 mails per connectie. Bovendien lijkt mij het maken van een socket veel korter qua tijd dan het maken van een connectie.

De socket is bij mij de basis van de connectie (daarop worden de in en out stream gemaakt). Dus ik moet die socket niet vroegtijdig kwijtraken.

Je kan uiteraard proberen je socket te behouden, maar je weet wat ze zeggen over voortijdige optimalisaties.

Ja iets met boze wortels.

[Kwistnix]

SocketChannels (newio) zijn met het oog op performance toch sowieso een beter keuze dan de "oude" Sockets?

[Infinitive]

Als je veelvuldig mails wilt versturen via dezelfde mailserver dan is het inderdaad verstandig om daarvoor dezelfde connectie te gebruiken. Dit is gewoon in smtp vastgelegd en de voordelen zijn:

• bespaar de overhead van het opzetten van een tcp connectie (handshake)
• bespaar aan de kant van de smtp server de overhead van het helo commando (reverse dns lookup)
• bespaar threads/processen aan de kant van de smtp server. Er zijn diverse mailfiters die per connectie bijvoorbeeld ook nog eens een threadje of procesje opstarten. De implementatie van de sendmail milter api creëert voor elke connectie met sendmail een aparte thread (tenminste, dat was de impelmentatie van 2 jaar geleden).

Er staat in ieder geval vast dat het hergebruik nooit toch slechtere performance kan leiden. Hoeveel voordeel het met zich mee brengt kan ik niet zeggen. Als je een boel kleine emailtjes stuurt zou ik een significant voordeel verwachten omdat je een hele berg aan overhead niet hebt. De enige echte manier om het te weten is om een fatsoendelijke benchmark te houden, maar als je dat gedaan hebt, heb je de implementatie ook al en heeft het dus weinig zin om die implementatie niet aan te houden... vooral omdat het de code niet veel ingewikkelder zou moeten maken.

[ Voor 15% gewijzigd door Infinitive op 18-11-2004 17:59 ]

[Alarmnummer]

Infinitive schreef op donderdag 18 november 2004 @ 17:54:
De enige echte manier om het te weten is om een fatsoendelijke benchmark te houden, maar als je dat gedaan hebt, heb je de implementatie ook al en heeft het dus weinig zin om die implementatie niet aan te houden... vooral omdat het de code niet veel ingewikkelder zou moeten maken.

Dat kan heel eenvoudig door de max-batchsize in te stellen. Stel je die op 1 in.. dan zal bij ieder mailtje een nieuwe connectie worden gemaakt. Stel je hem op 20 in, dan zal na maximaal 20 mailtjes (voor een domein) een nieuwe connectie worden gemaakt. Dus we kunnen het gelukkig wel testen.

[Infinitive]

Waarom je vraag dan
_{Of heb je het stiekum al gemeten met als antwoord dat het in jouw geval helemaal geen bal uitmaakt en wil je eens zien hoe hard iedereen weer uit z'n nek zit te lullen}

Ik bedenk me nu op eens dat ik je vraag ook op een andere manier kan interpreteren. Je zou ook kunnen bedoelen dat je in plaats van een vaste mailserver, connect naar een mailserver behorende bij het domein van de geaddresseerde.

Het lijkt me echter sterk dat je zoiets zou doen. Een eigen dedicated mailserver is veel geschikter voor iets dergelijks, omdat je daarmee een stabiele en snelle verbinding hebt en het beestje zelf het afleverproces en bijbehorende fouten in dit proces afhandelt.

[ Voor 16% gewijzigd door Infinitive op 18-11-2004 18:44 ]

[klinz]

Inderdaad, ook hier geldt: meten is weten :-) Allicht dat in batch verzenden sneller is.

[Verwijderd]

Infinitive schreef op donderdag 18 november 2004 @ 18:32:
Het lijkt me echter sterk dat je zoiets zou doen. Een eigen dedicated mailserver is veel geschikter voor iets dergelijks, omdat je daarmee een stabiele en snelle verbinding hebt en het beestje zelf het afleverproces en bijbehorende fouten in dit proces afhandelt.

Aangezien hij met MX records zit te spelen kun je ervan uitgaan dat de mail rechtsstreeks bij de ontvanger wordt afgeleverd. Daar zijn verschillende redenen voor te bedenken zoals een directe foutmelding bij connectieproblemen, niet bestaande accounts, snelheid enz. Ik heb een tijdje terug een programma geschreven voor een bedrijf met een grote mailinglist. Mailen via de exchange server zorgde voor grote problemen: traag, belangrijker mail werd achteraan de queue geplaatst, ontzettend grote sendmailboxen die weer verwijderd moesten worden enz enz. Door direct te gaan mailen naar de ontvangers werd de exchange server ontlast en werden er meer relevante statistieken zichtbaar.

[Alarmnummer]

Verwijderd schreef op vrijdag 19 november 2004 @ 18:15:
[...]
Aangezien hij met MX records zit te spelen kun je ervan uitgaan dat de mail rechtsstreeks bij de ontvanger wordt afgeleverd. Daar zijn verschillende redenen voor te bedenken zoals een directe foutmelding bij connectieproblemen, niet bestaande accounts, snelheid enz. Ik heb een tijdje terug een programma geschreven voor een bedrijf met een grote mailinglist. Mailen via de exchange server zorgde voor grote problemen: traag, belangrijker mail werd achteraan de queue geplaatst, ontzettend grote sendmailboxen die weer verwijderd moesten worden enz enz. Door direct te gaan mailen naar de ontvangers werd de exchange server ontlast en werden er meer relevante statistieken zichtbaar.

We zijn idd bezig met een mail applicatie en het versturen van grote batches met mail. Als je werkt via een relay server heb je idd te weinig controle en helemaal te weinig feedback en die informatie is wel nodig.

De basis is nu helemaal afgerond en volgende week gaan we testen met batches met mail. Kijken hoeveel mails een smtp server in 1 batch accepteerd en kijken wat de performance ervan is.

[Creepy]

Mag ik vragen waarom je niet gebruik maakt van bestaande mail software?
Wij gebruiken hier qmail om flinke batches mail te verzenden.
In eerste instantie gebruiken we qmail-remote om de mail te verzend, en als dat faalt gaat de mail de queue in met qmail-inject zodat qmail het reschedulen van mails verder zelf afhandelt.

Qmail maakt overigens voor elke mail een nieuwe sockets aan. Geen idee wat je voor snelheden wilt halen maar wij halen hier >50.000 per uur waarbij de mails uit de database worden gepersonaliseerd en de mails worden getrackt (wie opent wat, wie klikt er door op welke link..)

[Alarmnummer]

Creepy schreef op vrijdag 19 november 2004 @ 19:31:
Mag ik vragen waarom je niet gebruik maakt van bestaande mail software?

1) voor javamail moet je een smtp relay server gebruiken -> brengt extra complexiteit met zich mee (oa beheer)
2) geen feedback. De smtp-relay server slikt het meeste wel, maar het is erg lastig om feedback te krijgen (doorploegen van logfiles is niet echt je van het). Daarom is de beslissing genomen om dan zelf de mails maar te versturen en nu kunnen we alle aspecten controleren.

[Sjaaky]

Je kent james? Ik heb er geen ervaring mee, maar java en open source. Klinkt redelijk uitbreidbaar, customisable en programmeerbaar.

[Alarmnummer]

Sjaaky schreef op vrijdag 19 november 2004 @ 21:21:
Je kent james? Ik heb er geen ervaring mee, maar java en open source. Klinkt redelijk uitbreidbaar, customisable en programmeerbaar.

Yep.. en ik heb nog een paar dingen bekeken.. oa NET commons van Jakarta. In principe is het versturen van de mail helemaal niet zo gecompliceerd. Mijn hele SmtpConnection class (waar dus alles in zit) is echt vrij klein.

[Creepy]

Door middel van een klein stukje C code hebben we Qmail gekoppeld aan java. De mail die javamail genereerd gegeven we door aan de C code die qmail aanstuurt. (daarvoor was qmail op de localhost de smtp server die javamail aansprak)

Daarnaast lezen we de logs van qmail uit, plus is het return path zo gezet dat de reply mails bij de oorspronkelijke afzender komen (whatever de persoon heeft ingevoerd als reply adres) en de bounce mails bij onszelf terecht komen. Zo weten we precies wat er mis gaat en wat er bounced.

Ik denk overigens dat het beheer (en de veiligheid) van qmail overzichtelijker is dan een zelf geschreven oplossing. Qmail heeft zich al in de praktijk bewezen. Met het feedback heb je wel een punt, maar daar hebben we inderdaad een stuk voor dat dus de bounce mails + logfiles doorspit.

[Alarmnummer]

Creepy schreef op zaterdag 20 november 2004 @ 23:35:
Daarnaast lezen we de logs van qmail uit, plus is het return path zo gezet dat de reply mails bij de oorspronkelijke afzender komen (whatever de persoon heeft ingevoerd als reply adres) en de bounce mails bij onszelf terecht komen. Zo weten we precies wat er mis gaat en wat er bounced.

Niet helemaal want er zijn genoeg smtp servers die een mail accepteren maar het (bij bv een niet bestaand adres) gewoon dumpen. Je krijgt dus eigelijk heel weinig info terug.. Maar wat er terug komt willen we nog zoveel mogelijk bekijken.

Ik denk overigens dat het beheer (en de veiligheid) van qmail overzichtelijker is dan een zelf geschreven oplossing.

Het versturen van de Mail zelf is geen publiek beschikbare service dus er valt domweg niets te hacken (of ze moeten de applicatie zelf hacken). Dus ik betwijfel over het veiliger kan.

Verder brengt een externe SMTP server weer allerlei complexiteit met zich mee mbt onderhoud. Dat hebben we nu ook niet.

Qmail heeft zich al in de praktijk bewezen. Met het feedback heb je wel een punt, maar daar hebben we inderdaad een stuk voor dat dus de bounce mails + logfiles doorspit.

Wat voor hoeveelheden versturen jullie?

[ Voor 5% gewijzigd door Alarmnummer op 20-11-2004 23:57 ]