Forum » Pomoč in nasveti » AMQP optimizacija
AMQP optimizacija
ViperR ::
Imam vprašanje glede optimizacije pošiljanja zahtevkov na AMQP strežnik v zelo konkurenčnem okolju.
Predpostavimo naslednji scenarij:
AMQP strežnik odpre “gate” točno ob 12:00:00.000+01:00.
Prvi zahtevek, ki ga strežnik sprejme po odprtju gate-a, dobi nagrado (recimo 1 milijon €).
Vsi ostali zahtevki, ki pridejo kasneje, ne dobijo nič.
Konkurenca je velika (recimo 100+ udeležencev), zato vsi pošiljajo zahtevke praktično istočasno. Zaradi tega ima strežnik pogosto velik response lag (200 ms ali več).
Moje glavno vprašanje je:
S kakšnim pristopom bi imeli največjo verjetnost, da je naš zahtevek prvi sprejet na strežniku?
Dodatno me zanima še:
Ali je bolje poslati več zahtevkov zelo hitro zapored (burst) malo pred odprtjem. 12:00:00.000 - latenca?
Ali je pomembnejše, kdaj naš zahtevek prispe na AMQP strežnik, ali pa timestamp v odgovoru (server-response), ki ga strežnik vrne in vsebuje epoch čas obdelave zahteve?
Še nekaj dodatnih informacij o sistemu:
Imamo en račun, s katerim se lahko prijavimo na AMQP strežnik.
Odpremo lahko neomejeno število private channelov.
Imamo tudi neomejeno število računalnikov, s katerih lahko pošiljamo zahtevke.
Strežnik ima soft throttling – če pošljemo preveč zahtevkov zapored v krajšem intervalu (cca 10+), se response time močno poveča.
Če ima kdo izkušnje z low-latency AMQP sistemi ali podobnimi “race” scenariji, bi bil zelo hvaležen za nasvete.
Predpostavimo naslednji scenarij:
AMQP strežnik odpre “gate” točno ob 12:00:00.000+01:00.
Prvi zahtevek, ki ga strežnik sprejme po odprtju gate-a, dobi nagrado (recimo 1 milijon €).
Vsi ostali zahtevki, ki pridejo kasneje, ne dobijo nič.
Konkurenca je velika (recimo 100+ udeležencev), zato vsi pošiljajo zahtevke praktično istočasno. Zaradi tega ima strežnik pogosto velik response lag (200 ms ali več).
Moje glavno vprašanje je:
S kakšnim pristopom bi imeli največjo verjetnost, da je naš zahtevek prvi sprejet na strežniku?
Dodatno me zanima še:
Ali je bolje poslati več zahtevkov zelo hitro zapored (burst) malo pred odprtjem. 12:00:00.000 - latenca?
Ali je pomembnejše, kdaj naš zahtevek prispe na AMQP strežnik, ali pa timestamp v odgovoru (server-response), ki ga strežnik vrne in vsebuje epoch čas obdelave zahteve?
Še nekaj dodatnih informacij o sistemu:
Imamo en račun, s katerim se lahko prijavimo na AMQP strežnik.
Odpremo lahko neomejeno število private channelov.
Imamo tudi neomejeno število računalnikov, s katerih lahko pošiljamo zahtevke.
Strežnik ima soft throttling – če pošljemo preveč zahtevkov zapored v krajšem intervalu (cca 10+), se response time močno poveča.
Če ima kdo izkušnje z low-latency AMQP sistemi ali podobnimi “race” scenariji, bi bil zelo hvaležen za nasvete.
ViperR ::
Server colocation / crossconnect ni možen. Imamo zakupljen prostor v Frankfurtu, tako da recimo, da smo locirani v isti zgradbi. Velika verjetnost, da so tudi ostali. Še vedno, recimo da imajo vsi participanti enake pogoje.
vke4XC ::
To je zdaj igra ugibanja potem in odgovor je samo šloganje. Če občasno, lahko eksperimentirate s 'prehitki gat', da še ne aktivirate rate limitinga - enkrat bo mogoče uspelo. Če mora nagrada biti vsak dan, potem enako kot do sedaj - očitno brez.
ViperR ::
To je zdaj igra ugibanja potem in odgovor je samo šloganje. Če občasno, lahko eksperimentirate s 'prehitki gat', da še ne aktivirate rate limitinga - enkrat bo mogoče uspelo. Če mora nagrada biti vsak dan, potem enako kot do sedaj - očitno brez.
Ugibanje v kakem smislu? Če imamo vsi konkurenti enake pogoje (ista geolokacija), kakšen pristop je najbolj optimalen, da imam na dolgi rok največ možnosti? Recimo, da je vsak dan na voljo nagrada. Rad bi imel največji winrate, oz da bi želel vsaj kak dan imeti "srečo".
Trenutno imamo logiko burst 10 requestov, 28ms pred odprtjem gate-a, 0.1ms med requesti.
Response time (server tiemstamp v headerju) je po navadi +/- 15-30ms od našega targeta. Če pošljemo single request smo zelo precizni +/- 3ms v 90%.
V času ko se odpre gate (ko vsi pošiljajo requeste), pa dobimo response šele 200-600ms kasneje. Torej vprašanje, ali je optimalno potem poslati request-e, že veliko pred odprjem gate-a (če bomo prehitri, bo sprocesiran request prezgodaj, torej bo zavrnjen)? Oz ravno prav, da jih bo server sprocesiral toliko kasneje, da bo ravno odprt gate, ali mogoče poslati samo 1 request z zelo veliko preciznostjo? Ali mogoče poslati 1000 requestov in upati, da se eden od requestov sprocesira točno ob odprtju.. S katerim pristopom bo največji winrate?
Kako točno deluje AMQP strežnik.. Ali je server-timestamp v responsu edini pravi čas katerega moram gledati, ali je važno kdaj moj request zadane server, čeprav ostane v queue in je sprocesiran šele kasneje)?
Zgodovina sprememb…
- spremenil: ViperR ()
HotBurek ::
Pa imate sploh kak primer, ko je server sprocesiral request, ki je bil poslan pred odprtjem gate-a?
Ker če ne, potem pred tem nima smisla pošiljat.
Ter tole: "Imamo tudi neomejeno število računalnikov..."
Če je to res, potem naredi več istih primervo, kjer slajdaš štart po 1ms naprej:
server1: 10 burst requestov 28ms pred odprtjem gate-a
server2: 10 burst requestov 27ms pred odprtjem gate-a
server3: 10 burst requestov 26ms pred odprtjem gate-a
server4: 10 burst requestov 25ms pred odprtjem gate-a
itn...
Ker če ne, potem pred tem nima smisla pošiljat.
Ter tole: "Imamo tudi neomejeno število računalnikov..."
Če je to res, potem naredi več istih primervo, kjer slajdaš štart po 1ms naprej:
server1: 10 burst requestov 28ms pred odprtjem gate-a
server2: 10 burst requestov 27ms pred odprtjem gate-a
server3: 10 burst requestov 26ms pred odprtjem gate-a
server4: 10 burst requestov 25ms pred odprtjem gate-a
itn...
root@debian:/# iptraf-ng
fatal: This program requires a screen size of at least 80 columns by 24 lines
Please resize your window
fatal: This program requires a screen size of at least 80 columns by 24 lines
Please resize your window
Zgodovina sprememb…
- spremenilo: HotBurek ()
vke4XC ::
Burek, ti kar prevzemi - predlagano sicer lahko aktivira rate limiting, četudi 'gate' še niso odprte.
Ugibanje je v smislu, da forumaši ne poznamo omejitev, ciljev, uspešnosti/ponovljivosti.
Zato je tako malo odgovorov in ni nepričakovano.
Ugibanje je v smislu, da forumaši ne poznamo omejitev, ciljev, uspešnosti/ponovljivosti.
Zato je tako malo odgovorov in ni nepričakovano.
c3p0 ::
Pametni bi requeste sankcioniral z rate limitingom (bolj si poreden, slabše se ti sistem odziva), ali pa vse requeste pred točno uro blokiral z DROP na fw, da ni povratnega info.
HotBurek ::
Glede na to, da omenja lokacijo Frankfurt in da so s svojim serverjem na isti lokaciji, ter nagrada miljon evrov če si prvi... Frankfurtska borza?
root@debian:/# iptraf-ng
fatal: This program requires a screen size of at least 80 columns by 24 lines
Please resize your window
fatal: This program requires a screen size of at least 80 columns by 24 lines
Please resize your window
Vredno ogleda ...
| Tema | Ogledi | Zadnje sporočilo | |
|---|---|---|---|
| Tema | Ogledi | Zadnje sporočilo | |
| » | MQ z bazoOddelek: Programiranje | 6215 (4966) | c3p0 |
| » | Nasveti glede API-jaOddelek: Programiranje | 1391 (931) | Arey |
| » | Optimizacija API-jaOddelek: Programiranje | 2309 (1542) | AndrejS |
| » | Kako narediti request z "\" v URL-juOddelek: Programiranje | 2538 (1813) | Horejšio |
| » | Avtomatično prepoznati POST spremenljivkeOddelek: Programiranje | 1799 (1592) | AnonimkeOP |