linux - Find flaskehals i TCP-forbindelse

Indlæg af Hanne Mølgaard Plasc

Problem



Jeg arbejder på et projekt, der har en udgiver og en abonnent, der er tilsluttet via en almindelig TCP-stikforbindelse. Udgiveren genererer meddelelser med en vis hastighed, sender dem over stikket, så behandler abonnenten meddelelserne. Ingen meddelelseskø, bare ren TCP-stikforbindelse.


Problemet er, at stikket 'skrive' -metoden i udgiveren synes at tage lang tid, når det kaldes, og det reducerer den hastighed, hvorpå udgiveren kan sende data.


Jeg har lavet lidt læsning på stikkontakter og kan tænke på to scenarier, der kan forårsage dette:



  1. Netværket er ikke hurtigt nok til at håndtere afsendelse af meddelelsesfrekvens. I dette tilfælde mener jeg, at soklen udgående buffer på udgiveren skal udfyldes.

  2. Forbrugeren tager langsomt behandlingen af ​​meddelelserne, og derfor forventer jeg forbrugerens indgående buffer at være fuld. Dette ville (som jeg forstår det) medføre, at stikket skrive metode til at blokere.



Jeg lærer stadig om socket programmering, og jeg er ikke sikker på, om min analyse ovenfor giver mening. Hvis det er tilfældet, hvad kan det være en god måde at bestemme, hvilket scenario det er? En ting at bemærke er, at forbrugeren er på en Linux-maskine, men udgiveren er en Windows-maskine. Enhver hjælp ville blive værdsat!

Bedste reference


Du kan måle, hvor lang tid modtageren bruger i read() eller recv() -metoden, eller hvad det kalder at læse fra netværket.


Hvis det er meget lille, er der altid data, der er banket op, så det er modtagerens skyld, at det er langsomt at læse.


Hvis tiden der er blokeret i læsningen er signifikant, er det netværks skyld for at være langsom.