Bună, oameni greșiți de server,
Imaginează-ți o companie generică „Software as a Service” care oferă un serviciu care rulează pe AWS (hei, noi suntem). Nu este implicată nicio știință rachetă, o aplicație web standard își face treaba ca de obicei și o aplicație pentru smartphone pentru utilizatorul final. Aşa cum sunt clienţii din Europa, desigur, regiunea AWS eu-central-1 conține totul pentru mai mulți chiriași.
Acum Sales reușește să câștige un client din Australia - toate bune până acum, deoarece aplicația web poate gestiona deja diferite fusuri orare, valute și localități. Dar: Australia cât de departe poți ajunge de Europa (cel puțin pe pământ), așa că acum este implicat destul de mult timp dus-întors. La cerere, vedem aproximativ 300ms - 400ms în plus pe direcție (EDIT: acest lucru este greșit când vorbim despre RTT, așa cum se subliniază în felicitări, vedem 2x400ms = 800ms în plus pentru primul HTTPS cerere).
Pentru aplicația web menționată, care este folosită de client în scopuri de management, este perfect.HTML-ul redat apare puțin mai târziu, dar datorită CDN-urilor (CloudFront), activele nu reprezintă o problemă.
Dar aplicația pentru smartphone-ul utilizatorului final, care face cereri JSON mai mici, dar mai multe, este afectată. Acolo se simte la marginea „OK-ish”, dar definitiv deloc rapid.
Acum intrebarea este: cum să îmbunătățim timpul din perspectiva utilizatorului final?
Ne-am gândit deja la câteva opțiuni aici:
Clonează software-ul complet și găzduiește-l și în AWS ap-southeast-2
Avantaj: performanță uimitoare, ușor de configurat, CI/CD ar permite implementarea aceluiași cod simultan în UE și AU.
Dezavantaje: trebuie să întreținem și să plătim pentru două seturi de infrastructură identice, datele nu pot fi partajate cu ușurință, o mulțime de duplicare în toate termenii.
Mutați numai instanțe de calcul în AWS ap-southeast-2
Nu, nu va funcționa ca bază de date sau interogările redis ar fi afectate și mai mult de timpul dus-întors.
Aveți o replică numai pentru citire în AWS ap-southeast-2 și scrieți în eu-central-1
Mai bine ca opțiunea 2, dar adaugă multă complexitate în cod, plus numărul de scrieri nu este atât de puține de obicei.
Porniți un echilibrator de încărcare în AWS ap-southeast-2 și conectați la egal VPC-urile
Idee: utilizatorii se conectează la punctul final AU, iar traficul trece printr-o conexiune robustă către instanțele UE. Cu toate acestea, acest lucru, evident, nu ar reduce distanța și nu suntem siguri de potențiala îmbunătățire (dacă există?)
S-a confruntat cineva cu o problemă similară și este dispus să împărtășească câteva informații?
Actualizare: se pare că doar prima solicitare HTTPS pare să fie foarte lentă.
În timp ce am căutat în opțiunile AWS Load Balancer, am observat și asta AWS Global Accelerator ar putea ajuta, așa că am făcut câteva teste.
Din sistemul local (în UE):
curl -w "dns_resolution: %{time_namelookup}, tcp_established: %{time_connect}, ssl_handshake_done: %{time_appconnect}, TTFB: %{time_starttransfer}\n" -o /dev/null -s "https://saas.example .com/ping" "https://saas.example.com/ping"
dns_resolution: 0,019074, tcp_established: 0,041330, ssl_handshake_done: 0,081763, TTFB: 0,103270
rezoluție_dns: 0,000071, tcp_established: 0,000075, ssl_handshake_done: 0,000075, TTFB: 0,017285
Din AU (instanță EC2):
curl -w "dns_resolution: %{time_namelookup}, tcp_established: %{time_connect}, ssl_handshake_done: %{time_appconnect}, TTFB: %{time_starttransfer}\n" -o /dev/null -s "https://saas.example .com/ping" "https://saas.example.com/ping"
rezoluție_dns: 0,004180, tcp_established: 0,288959, ssl_handshake_done: 0,867298, TTFB: 1,161823
rezoluție_dns: 0,000030, tcp_established: 0,000032, ssl_handshake_done: 0,000033, TTFB: 0,296621
De la AU la AWS Global Accelerator (instanță EC2):
curl -w "dns_resolution: %{time_namelookup}, tcp_established: %{time_connect}, ssl_handshake_done: %{time_appconnect}, TTFB: %{time_starttransfer}\n" -o /dev/null -s "https://saas-with -global-accelerator.example.com/ping" "https://saas-with-global-accelerator.example.com/ping"
dns_resolution: 0,004176, tcp_established: 0,004913, ssl_handshake_done: 0,869347, TTFB: 1,163484
rezoluție_dns: 0,000025, tcp_established: 0,000027, ssl_handshake_done: 0,000028, TTFB: 0,294524
Pe scurt: se pare că strângerea de mână TLS cauzează cea mai mare latență inițială. Dacă poate fi reutilizat, totuși, timpul suplimentar pentru AU către UE pare într-adevăr „doar” ~277 ms (0,294524s - 0,017285s) pentru Time To First Byte.
Salutari!
