[VPN/SMB] Lage prestatie puur door latency?

[Da Weef]

Het bedrijf waar ik werk maakt o.a. gebruik van externe opslag via VPN. De prestaties hierop zijn niet geweldig, zeker niet bij handelingen waarbij veel communicatie over en weer komt kijken zoals bij het 'live' bewerken van bestanden op de server (up/downloaden is dus geen probleem). Hierover hebben we ons beklag gedaan. De respons van onze provider was dat de oplossing die we gekozen hebben, een pure fileserver, niet voldoet. Dus uiteraard krijgen we nu een offerte voorgeschoteld voor een dedicated (virtuele) server.

Echter het probleem blijkt zich veel minder voor te doen op externe locaties (andere verbinding dus). Controle van de verbinding laat zien een dergelijke externe verbinding naar de server pingt op ca. 10 ms en onze verbinding pingt op ca. 18ms. Deze latency van 18ms zit volgens traceroute bijna geheel in de (SDSL) verbinding naar de provider.

Onze voorlopige conclusie is dat het probleem ligt in de latency aangezien SMB erg gevoelig is hiervoor en dat een virtuele server hier niet bij gaat helpen. Correct?

[Question Mark]

Da Weef schreef op woensdag 03 december 2008 @ 10:49:
De respons van onze provider was dat de oplossing die we gekozen hebben, een pure fileserver, niet voldoet. Dus uiteraard krijgen we nu een offerte voorgeschoteld voor een dedicated (virtuele) server.

Vraag je huidige provider gewoons eens om dit te onderbouwen (het liefst met meetgegevens).

Vertel ook eens om wat voor soort verbinding het gaat (up/downloadsnelheid) en de huidige belasting van deze lijn. Hoe groot zijn overigens de bestanden die jullie bewerken?

[Da Weef]

Standaard 2048/2048 SDSL lijn, waarbij de grootte van de bestanden over het algemeen varieert van kale word-documentjes van enkele kB tot bestanden van enkele MB. Grotere bestanden komen wel voor, maar die worden zeker niet geopend vanaf de server.

EDIT: Wat betreft die onderbouwing... In eerste instantie werd ons verteld dat de fileserver een te hoge load had en dat het verholpen zou zijn met een upgrade van hun servers. Na de upgrade echter nauwelijks verbetering, waarop een dedicated server als alternatief werd aangeboden. Metingen zijn hierbij niet te pas gekomen heb ik het idee.

[ Voor 40% gewijzigd door Da Weef op 03-12-2008 15:27 ]

[Bl@ckbird]

Je moet eerst even meten wat de latency is en waar deze door wordt veroorzaakt.
Dit kan je doen met bijvoorbeeld Wireshark.

Wil je een zwaar gedetailleerd rapport hebben, dan kan je kijken naar bijvoorbeeld een Packetshaper met alleen monitoring licentie. ( Network / Server / Transaction delay zijn dan handig. ) Uiteindelijk doel is aan tonen dat de problemen aan het netwerk, of aan de server liggen.

Ligt het aan het netwerk, dan kun je met de latency waarden en de TCP receive window size,
de max. throughput van je verbinding berekenen.

Wil je dit optimaliseren dan zijn er de opties:
- Verbinding met een lagere latency. (Wat waarschijnlijk lastig wordt.)

- Spelen met de TCP window settings. ( Probeer ook eens UDP packets te zenden. Deze hebben minder last van latency op de lijn; Het beïnvloed in ieder geval de throughput niet.)

- Windows file shares / CIFS verkeer is erg chatty. (Wat geoptimaliseerd moet worden voor WAN verbindingen.) Dit kun je optimaliseren met bijvoorbeeld Cisco WAAS. Bluecoat en Riverbed hebben hier ook producten voor.
( Maar daar ben ik niet zo bekent mee. )

Zie ook dit topic.

[Da Weef]

Dank voor je reactie. Ik zal even kijken of ik wat wijzer wordt van Wireshark.

Verder is WAAS denk ik niet echt een optie voor ons. Voor dat prijskaartje kunnen we ook gelijk glasvezel hierheen trekken

[Bl@ckbird]

Das waar. Maar bij glasvezel zijn ook hogere kosten die maandelijks terug komen.
Bovendien hou je het latency probleem. ( Zeker op fysiek langere lijnen.) Of je dan een 10/100/1000 lijn hebt liggen, maakt dat dan niet zoveel uit. Je gebruikt TCP, dus kun je de pijp niet vullen. Glasvezel is alleen nuttig als dit een lagere latency op de lijn oplevert.

Edit:
Meerdere TCP sessies zijn natuurlijk geen probleem, maar per sessie
zit je dus aan de berekende theoretische max. vast.

[ Voor 17% gewijzigd door Bl@ckbird op 03-12-2008 18:52 ]

[vliegjong]

probleem met CIFS verkeer is dat de datapakketten stuk voor stuk (4 KB) geacked moeten worden door de CIFS client. al deze paketten hebben je X ms latency.
dus om iets te noemen.
10 MB aan data zijn 2500 datapakketten.
vervolgens heb je 2500 acks nodig.
Dus in totaal zo een 5000 paketten.
Latency van 15 ms dus 5000*15 MS is 75000 MS.
oftwel ruim een minuut.
Je pijp erbij opgeteld (2 Mb/PS) 40 seconden.

Dus je kan je pijp wel vergroten waardoor je 40 seconden minder worden maar je probleem zit in die ruime minuut. Die verklein je niet met een grotere pijp...

Just my 2 cts