O365-re jonnek a levelek, amelyeket egy 3rd party email archivalo gepre (amin a piler fut, ha ez szamit valamit) tovabbitanak. A gond ott van, hogy a jelek szerint a flow control hianyzik(?) az o365 kattintgatos oldalarol, ami azt eredmenyezi, hogy ha hirtelen jon egy nagyobb mennyisegu level, akkor azt nagy lelkesen zuditja is tovabb a piler fele az o365 szerverparkja.
Csakhogy a piler elindit mondjuk 10 worker processzt, ami praktikusan 10 smtp connection-t tud egyidejuleg fogadni. Ezen a 10-en szepen jonnek is be a levelek, de ha az o365-re egy nagyobb mennyiseg zudul rovid ido alatt, akkor a piler fele nyitott/nyitni probalt smtp kapcsolatok egy resze timeout-ra szalad. Ami azt eredmenyezi, hogy az o365 egy ndr-t kuld az adminnak.
A kerdes tehat az, lehet-e egyaltalan valamilyen flow control-t beallitani, azaz, hogy ne akarjon mondjuk 80 connection-t nyitni, hanem pl. 20-ban legyen ez maximalva. Aztan legfeljebb queue-ban tartja a leveleket, amiket eppen nem tud elkuldeni.
Hozzászólások
Szerintem nyissatok rá a support requestet az Office 365 tenant adminban.
Üdv,
Marci
- I'm Microsoft's new virtual support agent. Describe your problem and I'll look for the best solution. You can also ask to talk to a person at any time.
- hello
- Glad to talk to you. Could you describe your problem in detail?
- yes, I could
- Glad to talk to you. Could you describe your problem in detail?
- yes, I could
- Okay, tell me more about your problem and I'll find the right person to assist you.
- I need office 365 support
Aztan inkabb a talk to person opciot valasztottam, hatha egy biorobottal konnyebben zold agra vergodok...
--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)
Öröm lehet Téged ügyfélszolgálni.
Üdv,
Marci
UI
Figyelem! Az ön által elolvasni kívánt tartalom olyan elemeket tartalmaz, amelyek Mttv. által rögzített besorolás szerinti V. vagy VI. kategóriába tartoznak, és a kiskorúakra káros hatással lehetnek.
-What's your pleasure?
-F*ckin', ofcoz.
-Mire gondol konrétan?
-Konkrétan a b*szásra.
Jezusom.
+1, elmorzsoltam egy könnycseppet :(
Tulajdonképpen már csak egy kínzó kérdésem maradt. Mi akadálya volt, hogy az Office 365 tenant adminban nyissad meg a kérelmet, ahogy javasoltam? Ott ugyanis egy magyar nyelvű képernyő fogadhatott volna...
Üdv,
Marci
Szereti a nehezebb utat választani... :)
Lett megoldás? Mi lett az?
Üdv,
Marci
- "Csakhogy a piler elindit mondjuk 10 worker processzt, ami praktikusan 10 smtp connection-t tud egyidejuleg fogadni." "timeout-ra szalad." Ez mi a fasz? accept + fork? 90-es evek?
- elozohoz tartozoan, ha lenne support 10 nel tobb connectionre, de megsem akarod elfogadni akkor o365 nem tamogatja a 4xx hibakodot, ha megis vissza akarod dobalni leveleket ideiglenesen?
- meg miert nem a 3rd party gyujti a queuet, ha majd tamogatja 10nel tobb connectiont (lol)?
Ez mi a fasz? accept + fork? 90-es evek?
majdnem: preforkol, aztan a child processzek hivjak meg az accept()-et.
4xx hibakodot, ha megis vissza akarod dobalni leveleket ideiglenesen?
ez jo otlet.
meg miert nem a 3rd party gyujti a queuet
mire gondolsz?
--
Te!
Annyira gyulolod a BlackPanthert!
En meg ezert gyullolek! NIncs ra szo!
Le se szarlak! Erted budos goreny?! (abalole, a 20062. user)
"majdnem: preforkol, aztan a child processzek hivjak meg az accept()-et."
Amit irtal elejen hogy timeoutol abbol arra kovetkeztetek, hogy 10 acceptel majd dolgozik es nem acceptel megint amig dolgozik.
Egyreszt tobb accept is fura preforkolt szalakban, tehat vagy van global lockod igy szerializalva hajtodik vegre es pont ugyan olyan vagy lassabb, mintha 1 szal lenne acceptre. Vagy nincs es akkor meg kapod failedeket acceptre. De pont ugyan annyi vagy kevesebb socketet tudsz acceptelni mint 1 szalon. Vagy esetleg minden process kulon porton figyel? Bar utobbi meg furabb lenne.
De a lenyeg, hogy meg kell hatarozni mi a lassu. Valoszinu nem a halozati resz lesz ebben az esetben, ha 10 nel mar most para van. Tehat eleg egy szal ami csinalja halozatot (epoll/poll).
Mivel mostani gcckben stabilnak mondhato std::atomic, igy mar sima posix threadek is jok workereknek. Tehat egy lockless queueba betolod feladatokat es random szamu thread pedig kiolvassa es feldolgozza majd visszakuldi vagy eltarolja az eredmenyt. Es igy is rakhatsz limitet connectionokre, de azt mar te allitod.
Amennyiben megis ugy dontesz, hogy szuperdurva ezermilliolevelpersec es mar cska halozat a szuk keresztmetszet. Akkor pedig szokasos main process listen es accept majd clientfd cmsgkent worker processekre. Aztan 3.8 kernel folott meg so_reuseport es X szamu kulonbozo fuggetlen worker processben tudsz ugyan azon porton listenelni, majd az eredmenyeket vissza tudod kuldeni egy szalnak, ha aggregalni kellene oket.
"meg miert nem a 3rd party gyujti a queuet"
Itt arra gondoltam, hogy miert nem piler gyujti oket?
Valahogy igy:
[kulso levelezo] -> [piler smtp] -> [buffer/queue] (memoria es limitalva mennyi level lehet benne es ha tul sok akkor irja diskre vagy ha mar disken sem fer vagy elerte azt a limitet is akkor 4xx hibakod) -> *feldolgozo szalak* -> [aggregalas ha kell ilyen] -> kiiras
nem kulon porton vannak a processzek, hanem a main vegzi el a bind es listen hivasokat, majd forkol 10 db workert, es azok accept-elnek. Jelenleg ugy mukodik, hogy a child processzek smtp-n atveszik a levelet, majd fel is dolgozzak, majd a vegen visszaadjak a queue azonositot (ami a piler azonosito is egyben), majd ujra accept, stb.
10-nel igazabol azert volt para, mert az 10 egyideju session-t jelent (a jelenlegi modellel). De lehetne tobb is, csak akkor a gep terhelese is nagyobb lesz. (Emberunk gepe az amazonnal van, nem tudom, mennyire overbook-oljak a cpu-t es tarsait).
Tegnap nezegettem a postscreen forrasat, ami elvegzi az acceptet, majd unix domain socketen keresztul atadja a descriptort az smtpd processzeknek (valahogy*). Amugy ott is egy smtpd processz 1 klienst szolgal ki. Lehet, hogy efele megyek el: kulon valasztom a halozatkezeleset (1 master processz + n db child, amelyek osszesen n db klienssel tudnak egyszerre beszelgetni), ill. kulon processzek dolgozzak majd fel a queue konyvtarba rakott file-okat/leveleket. Meg ki kell talalni, hogy kozolje az smtp oldal a feldolgozo oldallal, hogy itt egy uj level...
Btw. ha 50-100 parhuzamos smtp session-nel tobbet nem akarok kiszolgalni, akkor kell nekem poll? (epoll-ra 1. korben inkabb nem mennek, mert az Linux-only)
*Ezek szerint egy bizonyos unix domain socket-et tobb processz is tud figyelni/olvasni?
--
Te!
Annyira gyulolod a BlackPanthert!
En meg ezert gyullolek! NIncs ra szo!
Le se szarlak! Erted budos goreny?! (abalole, a 20062. user)
"10-nel igazabol azert volt para, mert az 10 egyideju session-t jelent (a jelenlegi modellel). De lehetne tobb is, csak akkor a gep terhelese is nagyobb lesz. (Emberunk gepe az amazonnal van, nem tudom, mennyire overbook-oljak a cpu-t es tarsait)."
Ettol en meg a lehetoseget megadnam, hogy o allithassa configbol mondjuk. Tehat nem ugy limitalom, hogy ugy irom meg programot, hogy ne mukodjon tobbel mert timeout vagy egyeb hiba miatt.
"Btw. ha 50-100 parhuzamos smtp session-nel tobbet nem akarok kiszolgalni, akkor kell nekem poll? (epoll-ra 1. korben inkabb nem mennek, mert az Linux-only)"
Ilyen kevesre poll jobb is lehet mint epoll. De amugy libeventet behuzod, az pedig tamogatja neked kqueue,epoll,poll,select stb. Es itt nem lesz gep terhelese nagyobb, mert mondjuk 1000 szalon fogadod el ugyan azt a mennyisegu levelet, amit 10en. Vegen ugyan annyi lesz.
---
Amugy ha tudom, hogy garantaltan tovabb akarom adni client fd t child processnek, akkor is listen mellett acceptelnek, es socketpair + cmsg t hasznalnek client fd atadasara. De az is biztos, hogy nem engednek olyan esetet, ahol a levelfeldolgozo workerek telitettsege miatt nem menne accept vagy blockolna async iot hosszabb ideig barmi modon. Azaz biztosan nem raknam halozat melle 1 szalba nagy levelek parseolasat vagy virusirtasat vagy egyeb cpuintenziv cuccot.
Es hasznalnek disken queuet is arra az esetre, ha memoriaba nem fer. + nem hasznalnek tobb workerthreadet/processt mint a cpuk szama+1 abban az esetben ha cpuintenziv feladatot hajt vegre, tehat mind 100%on porog feldolgozas kozben.
o allithassa configbol mondjuk.
ez megvan, igy mentunk fel 40-re, ami elegnek tunt.
De amugy libeventet behuzod,
igy lett. Egy processz fogadja a leveleket, es teszi le 1-1 file-ba. Hasit, mint a zallat :-) Majd meg a starttls implementalasa lesz meg izgalmas libevent-tel. Ha az is megvan, akkor egy massziv terheles teszt, meg protokoll teszteles. Utana johet a letett levelek feldolgozasa. Meg kitatalalom, hogyan. De ezek szerint (1 cpu eseten) 2 db worker processz fog feldolgozni. Lehet, hogy nem szoszolok azzal, hogy a 2 worker ne akarja ugyanazt a file-t feldolgozni, hanem ahany worker, annyi alkonyvtar lesz a queue konyvtarban, es mindegyik worker csak a sajat konyvtaraban keresi a leveleket.
Kivancsi leszek az eredmenyekre!
update: sajnos nem megy, hogy egy mar connected socket-re ragyogyitsam a tls-t, es igy a starttls-nek annyi.
--
Te!
Annyira gyulolod a BlackPanthert!
En meg ezert gyullolek! NIncs ra szo!
Le se szarlak! Erted budos goreny?! (abalole, a 20062. user)