Site-ul web răspunde foarte lent utilizând baza de date de la distanță

Vreau ca două aceleași site-uri web să partajeze o bază de date. Un server este în Asia, găzduind un site web și baza de date. Un alt server se află în SUA, găzduind același web prin baza de date de la distanță. Cu toate acestea, web-ul din SUA răspunde foarte lent, dar când se mută baza de date pe serverul local (serverul SUA), web-ul răspunde rapid. Cum se accelerează conexiunea dintre serverul din SUA și baza de date din Asia?

Folosesc Centos7+Nginx+MySQL.

Cum se accelerează conexiunea dintre serverul din SUA și baza de date din Asia?

Probabil că nu poți. SUA-Asia este o distanță lungă și este implicată o latență. Mai simplu spus: lumina are o viteză finită.

Probabil ar trebui să căutați alternative la interogarea unei baze de date la distanță, cum ar fi stocarea în cache a activelor în mai multe locații, folosind un CDN sau utilizarea unei scheme de replicare a bazei de date, astfel încât să puteți avea copii locale ale datelor.

Aplicația dvs. web face mai multe interogări separate la baza de date? O interogare depinde de interogarea anterioară sau există interogări independente care ar putea fi ambele în zbor în paralel pentru a suprapune latența lor?

Dacă acesta din urmă, asigurați-vă că se întâmplă de fapt în orice limbaj de programare pe care l-ați folosit, nu serializați în mod inutil interogările.

Dacă acest lucru nu este suficient sau imposibil, va trebui să reduceți cumva latența dus-întors între serverul web și baza de date, fie prin replicarea bazei de date, astfel încât să puteți avea o copie locală, memorând în cache unele părți „fierbinți” ale acesteia care nu schimbați des sau diverse alte lucruri, cum ar fi stocarea în cache a ieșirii finale a serverului web sau alte lucruri pe care un CDN le poate face (vezi răspunsul vidarlo).

Nu poți îmbunătăți viteza luminii. _{{necesită citare}}

În loc să interogați la nivel intercontinental, ar putea fi necesar să vă uitați la orice replicare oferită de MySQL. Ai nevoie de un server web și un server de baze de date în Asia și duplicat în fiecare locație (SUA, UE, Africa, ME etc.). Când un server web scrie, DB local este actualizat imediat, iar acea actualizare este apoi împinsă către serverele DB de la distanță de către MySQL intern.

Positive:

• Sesiunile utilizatorilor ar putea trece de la un site la altul, iar înregistrările bazei de date ar fi consistente.
• Trebuie doar să faceți o copie de rezervă a unui server de bază de date pentru a obține lotul.
• Poate adăuga redundanță și toleranță la defecțiuni având un site primar, iar dacă acesta scade, trece la un site la distanță.
• Poate extinde serverele web pe orizontală la fiecare site pentru a permite întreținerea timpului de nefuncționare, cum ar fi actualizări/reporniri
• Puteți chiar să aveți un server DB de rezervă local pe fiecare site, permițând din nou redundanța fără a fi nevoie să treceți peste

Negative:

• Complexitate adăugată
• Costul crescut al mai multor resurse

În cele din urmă, aceasta este o problemă de proiectare a infrastructurii și nu chiar o chestiune de server web.

Designul obișnuit al unui site web susținut de baze de date utilizează puține (sau mult mai multe, cum ar fi 50 sau 100) interogări de baze de date pentru a genera o singură pagină web ca răspuns la o solicitare a browserului.

Fiecare dintre aceste interogări, una după alta, necesită un timp dus-întors între serverul web și serverul bazei de date. Acest lucru se poate adăuga rapid.

În schimb, conexiunea dintre browserul web și site-ul web se stabilește după o călătorie de două ori dus-întors între browser și server, iar apoi datele sunt aproape transmise către browser la fel de repede pe cât permite conexiunea.

Vezi diferenta? 2 călătorii dus-întors utilizator-server vs multiple (probabil zeci) de călătorii dus-întors server-server. Conexiunea dintre servere poate fi mai rapidă, dar nu în mare măsură.

Acesta este motivul pentru care configurația dvs. este în general inutilă.

Ce se poate face, atunci?

1. Utilizați un singur server web lângă baza de date. Vremurile în care aveau servere distribuite geografic era importantă pentru a îmbunătăți experiența utilizatorului au trecut de mult pentru ceva mai puțin decât un centru global de comerț electronic sau un centru de știri.

Experiența utilizatorului de astăzi este dominată de proprietățile de conectare ale utilizatorului în primul rând și abia depinde de locația serverului web.

Da, există momente în care o conexiune principală globală este întreruptă și conexiunile dintre, de ex. China și Europa devin o adevărată durere, dar dacă se întâmplă un astfel de eveniment nefericit, conexiunea dintre serverul tău web și serverul tău db va fi la fel de afectată. Și acest lucru este de fapt mai rău decât încetinirea conexiunii dintre serverul dvs. web și utilizatorii dvs., vedeți mai sus.

Există trucuri CDN care vă pot îmbunătăți timpul de răspuns chiar și cu un singur server, arătând ca și cum aveți mai multe servere în locații diferite. Principalii furnizori de CDN precum Cloudflare sau Akamai au instrumente foarte puternice.

2. Utilizați replicarea bazei de date și mențineți o bază de date lângă ambele servere web. Acest lucru poate necesita o regândire profundă a designului aplicației, precum și un set de abilități mult mai larg și/sau licențe DB mai scumpe.

3. Verificați proprietățile conexiunii la baza de date la ambele capete (server db și server web).

• Jurnalizarea extinsă, autentificarea complexă și dn-urile inverse pe partea serverului db pot întârzia destul de mult rezultatele fiecărei interogări db.
• Utilizarea conexiunilor db persistente pe partea serverului web poate reduce interogarea db dus-întors de 2-5 ori.

4. Reproiectați-vă aplicația pentru a utiliza mai puține interogări db pe pagină. Acest lucru, pe de altă parte, poate duce la interogările care devin mai complexe, mai lente și mai greu de întreținut. Kilometrajul dvs. poate varia.

distanța nu face baza de date mai lentă, ci doar crește latența.

atenuările pentru latență includ

• rulează mai multe interogări în paralel
• reducerea numărului de interogări necesare
• stocarea în cache a rezultatelor la nivel local
• păstrarea locală a unei copii numai în citire a bazei de date

Unele straturi de wrapper SQL, cum ar fi, fac un număr mare de interogări suplimentare pentru a determina structura bazei de date, este posibil să trebuiască să reproiectați pentru a utiliza SQL nativ.

Acolo unde este posibil, utilizați îmbinări în loc de bucle de interogare. dacă este necesar, este posibil să faceți actualizări și inserări pe mai multe rânduri, dar nu știu cea mai bună sintaxă pe care să o folosesc pentru asta în mysql.

Alții au notat deja opțiunile de replicare sau stocare în cache pentru a vă oferi o copie locală a datelor, reducerea numărului de interogări, sau la utilizați întotdeauna serverul web lângă serverul bazei de date. Acestea sunt opțiuni bune pe care ar trebui să le luați în considerare, dar nu singurele opțiuni.

O altă alternativă este să proxy interogarea. Cu un proxy, puteți configura un server web din SUA pentru a retransmite către un server web asiatic local în baza de date. Apache cu siguranță pot face asta și cred asta Nginx pot de asemenea (dar sunt mult mai puțin familiarizat cu configurația Nginx). Acest lucru va rezolva problemele cu călătoriile dus-întors repetate între serverul web și baza de date care sunt lente, cu prețul adăugării comunicației proxy peste aceasta. Dar comunicarea proxy poate fi o singură pereche cerere/răspuns, care va fi în general mai rapidă.

Puteți face acest lucru dacă replicarea, stocarea în cache sau reducerea interogărilor este prea dificilă dintr-un motiv oarecare. Configurarea proxy-ului este relativ simplă și nu necesită să vă schimbați logica aplicației (cum o fac stocarea în cache și reducerea interogărilor). De asemenea, aș găsi că este mai probabil să fie eficient decât simpla reducere a interogărilor. Deoarece un proxy se reduce în esență la o singură interogare la distanță, în timp ce este probabil să aveți în continuare mai multe interogări la baza de date.

Proxy-ul evită, de asemenea, să fie nevoie de replica în ambele direcții. Dacă ambele servere web locale (SUA) și la distanță (Asiatic) efectuează operațiuni de scriere, poate fi mai ușor ca toate operațiunile de scriere să fie efectuate direct pe serverul de bază de date autorizat. Acest lucru evită problema editărilor conflictuale pe care fiecare încearcă să se suprascrie reciproc la distanță. Dar acum ne-am întors potențial să facem mai multe solicitări dus-întors la baze de date la distanță (deși mai puține). Cu proxy, vi se garantează o singură cerere/răspuns pe încărcare de pagină.

Oferă, de asemenea, unele avantaje legate de utilizarea întotdeauna directă a serverului web la distanță (asiatic). Dacă o parte din conținut este dinamic și îl proxy numai pe acel conținut, serverul local (SUA) poate furniza tot conținutul static. Desigur, ar putea fi mai bine cu un CDN pentru conținutul static și acces direct client la serverul web din Asia.