înregistrare Logare
Puncte:2
avatar Server

Ce poate cauza întârzierea/întârzierea solicitării TCP / HTTP

drapel in
Király István

Avem un dispozitiv care trimite cereri POST sau mesaje TCP la intervale fixe, cu o sarcină utilă JSON, prin internet către serverul nostru care rulează o aplicație nod, în altă locație.

Sarcina utilă JSON are un marcaj de timp și alte valori.Comparăm acel timestamp cu timestamp-ul serverului pentru a calcula diferența de timp, pe care o numim lag.

Intervalul este de 100 ms. Ceea ce experimentăm, este că inițial, decalajul este sub 200 ms. Lăsăm sistemul să funcționeze câteva zile și observăm că lag-ul crește, după 2-3 zile este de 2000 - 3000ms, și crește în continuare .. după 6 zile în jur de 6000ms.

Odată ce repornim procesul de server, decalajul revine la normal, așa că presupun că expeditorul este OK. Acest lucru se întâmplă atât cu implementarea cererilor POST, cât și cu implementarea mesajelor TCP.

Are cineva idee de ce se poate întâmpla acest lucru sau cum să restrângem problema?

410
0 + 0
tcp
drapel sh
Ben
După cum indică AlexD, ceasurile serverului și clientului pot fi diferite. Pentru a verifica cronometrele, cel mai bine este să luați orele de început/sfârșit pe aceeași mașină.
2
Răspunde
drapel jp
Brian
Ați putea încerca să declanșați manual / sincronizarea mesajului în ziua 1 față de ziua 3 și să comparați performanța? L-ați rula manual, așa că ați dori să ignorați marcajele de timp/înregistrarea în favoarea vizionarii vizuale a performanței. Acest lucru ar ajuta la reducerea dacă problema se datorează sincronizării (dacă rularea manuală este rapidă) față de întârzierea reală (dacă rularea manuală este lentă)?
0
Răspunde
VL-80 avatar
drapel cn
VL-80
Dacă este posibil, configurați o pereche de testare dispozitiv-server într-un mediu controlat, aproape unul de celălalt și vedeți dacă problema persistă. Vă va permite să eliminați aspectul de rețea al problemei și ar trebui să vă ajute să restrângeți problema dacă bănuiți că rutarea prin Internet contribuie la problemă.
0
Răspunde
Ben Voigt avatar
drapel pl
Ben Voigt
De asemenea, ar trebui să măsurați timpul dus-întors, deoarece aceasta necesită două măsurători de la o singură sursă de ceas, orice nepotrivire/eroare/deformare a ceasului nu poate fi confundată cu întârziere/latență.
0
Răspunde
drapel in
Király István
Clientul este un dispozitiv care are propriul sistem de operare. Am încercat să emulez dispozitivul, dar nu am reușit să reproduc problema. Durata călătoriei dus-întors este destul de mică, de obicei sub 20 ms. Dat fiind că reproducerea durează zile, procesul de găsire a acestuia este relativ lent.
0
Răspunde
Puncte:6
avatar Server
drapel jp
AlexD

Aveți ceasuri sincronizate atât pe server, cât și pe expeditor? 1 secundă pe zi nu este o deplasare neobișnuită a ceasului.

0 + 0
drapel cn
rtaft
„Odată ce repornim procesul serverului, decalajul revine la normal” sugerează altfel.
0
Răspunde
drapel jp
AlexD
@rtaft este posibil ca aceștia să folosească un ceas imprecis (`setInterval`?) în cadrul procesului lor de serviciu, care variază în timp. Sau repornesc procesul repornind serverul care face `ntpdate` la pornire, dar nu rulează serviciul `ntpd`.
2
Răspunde
drapel jp
Brian
@AlexD: Nu ar trebui să se datoreze unui interval imprecis, deoarece trimit marcajul de timp al serverului în sarcina utilă. Deriva de interval ar modifica, de asemenea, marca temporală inclusă. Cu toate acestea, deviația ceasului este o posibilitate foarte reală, mai ales dacă OP utilizează un server virtual/cloud mai degrabă decât o mașină dedicată.
0
Răspunde
drapel jp
AlexD
@Brian, nu știm cum își calculează marcajele de timp. Ei pot obține ora sistemului o dată la început și apoi pot adăuga intervale.
0
Răspunde
drapel in
Király István
Obținem data prin javascript `new Date()` pe server. Ceasul este puțin probabil, dar o voi ține cont.
0
Răspunde
Puncte:3
avatar Server
drapel cn
shearn89

Acest lucru ar indica ceea ce se numește o scurgere de resurse. Ceva din aplicația dvs. încetinește procesarea în timp, pe măsură ce se acumulează o coadă, o memorie sau o altă resursă.

Aș recomanda să adăugați instrumente la codul dvs. NodeJS pentru a urmări orice cozi interne, memoria alocată, căutări în bazele de date etc. Înregistrați toate lucrurile, astfel încât să puteți începe să identificați unde se află blocajul.

Dacă rulați în cloud, există instrumente bune pentru a ajuta codul instrumentului, cum ar fi AWS X-Ray.

0 + 0
drapel in
Király István
Mulțumiri. Îmi voi verifica din nou codul.
0
Răspunde
drapel romania
SEF 777
întrebarea această in alte limbi:

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.