Ağ gecikmesi: 100Mbit ve 1Gbit


11

Geçerli bir 100Mbit bağlantısı olan bir web sunucum var ve sağlayıcım 1Gbit'e yükseltme sunuyor. Bunun verim anlamına geldiğini anlıyorum, ancak paketler büyüdükçe, daha hızlı iletilebilirler, bu nedenle yanıt süresinde (örneğin ping) hafif bir azalma beklenir. Bunu hiç kimse karşılaştırdı mı?

30 bayt yük ile örnek (100mbit - 100mbit sunucu):

> ping server -i0.05 -c200 -s30
[...]
200 packets transmitted, 200 received, 0% packet loss, time 9948ms
rtt min/avg/max/mdev = 0.093/0.164/0.960/0.093 ms

300 bayt yükte (MTU'nun altında) örnek (100mbit - 100mbit sunucu):

> ping server -i0.05 -c200 -s300
[...]
200 packets transmitted, 200 received, 0% packet loss, time 10037ms
rtt min/avg/max/mdev = 0.235/0.395/0.841/0.078 ms

Yani 30'dan 300'e kadar ort. gecikme 0,164'ten 0,395'e kadar yükselir - Bunun 1gibt'den 1gbit bağlantıya kadar daha yavaş bir artış olmasını beklerdim. Hatta bağlantı, tüm paketi alana kadar ilk bekleyen bir anahtarla 100mbit'ten 1gbit'e kadar daha hızlı olmasını beklerdim.

Güncelleme: Lütfen cevapların yorumlarını dikkatlice okuyun! Bağlantı doygun değil ve bu hız artışının insanlar için bir istek için önemli olacağını düşünmüyorum, ancak bu, toplanan birçok istekle ilgili (Redis, Database, vb.)

@LatinSuD tarafından verilen yanıtla ilgili :

> ping server -i0.05 -c200 -s1400
200 packets transmitted, 200 received, 0% packet loss, time 9958ms
rtt min/avg/max/mdev = 0.662/0.866/1.557/0.110 ms

Ayrıca yeni gbit ethernet kartları ve kabloları ile farklı kodlama (10b / 12b?) Vardır, böylece 100Mbit'e karşı 10x (doygunken) üzerinde% 25 daha fazla performans olabilir mi?
huseyin tugrul buyukisik

Yanıtlar:


15

Gecikmenin kayda değer bir şekilde düşmesinin tek yolu, mevcut 100Mbit bağlantısının doygun olması. Doymamışsa, büyük olasılıkla herhangi bir değişiklik fark etmeyeceksiniz.

Ayrıca, 1Gbit bağlantısının daha büyük paketleri destekleyebileceği varsayımınız yanlıştır. Maksimum paket boyutu, paketin aldığı yol üzerindeki çeşitli cihazların MTU'su tarafından belirlenir - sunucunuzdaki NIC ile başlayarak müşterinizin bilgisayarının MTU'suna kadar. Dahili LAN uygulamalarında (yoldaki tüm aygıtlar üzerinde kontrolünüz olduğunda), bazen MTU'yu artırmak mümkündür, ancak bu durumda, varsayılan MTU 1500 ile sıkışmış olursunuz. böylece parçalanmış olurlar, böylece performans düşer.


2
"Takdir edilebilir" burada anahtar kelime. Aynı donanım ve düşük ağ yükü olan ancak farklı ethernet hızlarına sahip iki sunucuyu kontrol ettim. Ortalama ping süresi (yerel, aynı alt ağdaki ping kaynağı ile) 0.21 milisaniyeden 0.17 milisaniyeye düştü. Aynı sunucuları evden pingleyerek her biri 53 milisaniye sürdü. Tedarikçinizin kontrolünün ötesinde bunu değerli bir yükseltme yapmak için çok fazla faktör vardır.
Mike Renfro

1
+1 Teknik olarak bir fark vardır, ancak belirli bir uygulama gecikmeye karşı inanılmaz derecede hassas olmadıkça tamamen fark edilemez.
Chris S

Test için teşekkürler! 0.21'den 0.17'ye kadar% 20'lik bir gelişme, bu harika. Ben evden (50 ms) ping endişe değilim ama istek sağlayıcıda kalır zaman. Tüm işlem (CPU) ve sürücü-olmayan IO'ları (RAM / Önbellek / vb.) Maksimuma ayarladık, bu yüzden şimdi sunucular arasındaki ağ hızının toplam gecikmeye toplamda ne kadar kattığını soruyorum. Örneğin, bir web sunucusu isteği için ~ 20 Redis-Request yapıyoruz. @MikeRenfro: Aynı testi daha yüksek bir yük boyutu ile yapabilir misiniz? Normal ping 30 bayt, ort. 250 civarında redis. Farkın büyümesini beklerdim.
Andreas Richter

2
@Andreas; Bence bu yorumların anlamını tamamen kaçırdınız. Bu 40 nanosaniyelik bir gelişme. Tamamen insanlar için algılanamayan bir miktar . Ve bu kümülatif bir sayı değil, her isteğin 40 nanosaniye daha uzun sürmesi gibi değil; bu sadece birincisi çok daha hızlı olacak, bu yüzden ikincisi her iki şekilde de hemen arkasında olacak.
Chris S

1
@ChrisS: Algılanabilirlik ile ilgili soru değildi - birisinin bunu test etmesi ve Mike'ın yapması bir soruydu. Aynı zamanda 40 nano-saniye değil, mikro-saniye , bu yüzden nokta 1000 faktörü eksik. İnanın bana, ne yaptığımı biliyorum ...% 20 ek maliyetleri haklı çıkarmak için yeterli olacaktır.
Andreas Richter

12

EVET gbit'in gecikmesi daha düşüktür, çünkü:

  • aynı sayıda bayt daha hızlı bir şekilde aktarılabilir

AMA iyileştirme yalnızca paketlerin belirli bir boyuta sahip olması durumunda takdir edilebilir:

  • 56 bayt paket => neredeyse daha hızlı aktarım yok
  • 1000 bayt paket =>% 20 daha hızlı aktarım
  • 20000 bayt paket (ler) =>% 80 daha hızlı aktarım

Dolayısıyla , gecikmeye karşı çok hassas bir uygulamanız varsa (4ms ve 0.8ms, 20kb için gidiş-dönüş) ve daha büyük paketlerin aktarılmasını gerektiriyorsa, 100mbit'ten gbit'e geçiş yapmak, kullandığınız halde gecikme azalması sağlayabilir ortalama 100mbit / s'den daha az (= bağlantı kalıcı olarak doygun değil).

Sunucu (100mbit) -> Anahtar (gbit) -> Sunucu (100mbit):

size: 56 :: rtt min/avg/max/mdev = 0.124/0.176/0.627/0.052 ms
size: 100 :: rtt min/avg/max/mdev = 0.131/0.380/1.165/0.073 ms
size: 300 :: rtt min/avg/max/mdev = 0.311/0.463/2.387/0.115 ms
size: 800 :: rtt min/avg/max/mdev = 0.511/0.665/1.012/0.055 ms
size: 1000 :: rtt min/avg/max/mdev = 0.560/0.747/1.393/0.058 ms
size: 1200 :: rtt min/avg/max/mdev = 0.640/0.830/2.478/0.104 ms
size: 1492 :: rtt min/avg/max/mdev = 0.717/0.782/1.514/0.055 ms
size: 1800 :: rtt min/avg/max/mdev = 0.831/0.953/1.363/0.055 ms
size: 5000 :: rtt min/avg/max/mdev = 1.352/1.458/2.269/0.073 ms
size: 20000 :: rtt min/avg/max/mdev = 3.856/3.974/5.058/0.123 ms

Sunucu (gbit) -> Anahtar (gbit) -> Sunucu (gbit):

size: 56 :: rtt min/avg/max/mdev = 0.073/0.144/0.267/0.038 ms
size: 100 :: rtt min/avg/max/mdev = 0.129/0.501/0.630/0.074 ms
size: 300 :: rtt min/avg/max/mdev = 0.185/0.514/0.650/0.072 ms
size: 800 :: rtt min/avg/max/mdev = 0.201/0.583/0.792/0.079 ms
size: 1000 :: rtt min/avg/max/mdev = 0.204/0.609/0.748/0.078 ms
size: 1200 :: rtt min/avg/max/mdev = 0.220/0.621/0.746/0.080 ms
size: 1492 :: rtt min/avg/max/mdev = 0.256/0.343/0.487/0.043 ms
size: 1800 :: rtt min/avg/max/mdev = 0.311/0.672/0.815/0.079 ms
size: 5000 :: rtt min/avg/max/mdev = 0.347/0.556/0.803/0.048 ms
size: 20000 :: rtt min/avg/max/mdev = 0.620/0.813/1.222/0.122 ms

= ortalama olarak birden fazla sunucu üzerinde 20kb ping için% 80 gecikme azaltma

(Bağlantılardan yalnızca biri gbit ise, 20kb ping için hala% 5 gecikme süresine sahip olursunuz.)


1
Çoğu ağ donanımının depolanması ve iletilmesi ile birlikte bir paket aktarılmadan önce bir anahtar / yönlendirici tarafından tam olarak alınmalıdır. Daha hızlı bağlantılar bu süreyi azaltır, bu da gecikmeyi azaltır (bağlantı birkaç paralel bağlantıdan hız almadığı sürece).
Brian

1
Açıklama nedeniyle, bu cevap sayfadaki en iyisidir. Diğerleri, uzun bir mesafe / çok sayıda anahtar boyunca ağ performansı - özel bir durum olduğunu varsayarak bu gerçeği açıklamak istiyor gibi görünüyor. Özellikle OP'nin endişesi (web sunucusu) düşünüldüğünde, bu dikkate alınması önemlidir, ancak bu cevap aynı zamanda anahtar hızının tek bir sıçramada ne kadar fark yaratabileceğini gösterir.
Tyler

3

Bant genişliği gecikmesi ve "hız" konusunda temel bir yanlış anlama olduğunu düşünüyorum. Hız, bant genişliği ve gecikmenin bir fonksiyonudur. Örneğin, gelmesi 3 gün süren ülke çapında gönderilen DVD'lerdeki verilerin gönderilmesini düşünün. Bunu internet üzerinden veri gönderme ile karşılaştırın. İnternetin gecikme süresi çok daha düşüktür, ancak gönderiye bağlantının "hızını" eşleştirmek için saniyede 9,6 MB almanız gerekir ( bu kaynaktan referans örnek ).

Durumunuzda daha yüksek bant genişliğine yükseltme, daha fazla eşzamanlı kullanıcıya hizmet vermenize izin verir, ancak herhangi bir kullanıcının gecikmesini artırmaz.


Bu yanlış - ping'i mevcut MTU'nun altındaki farklı yük ile karşılaştırın: ping sunucusu -i0.05 -c200 -s30 ve ping sunucusu -i0.05 -c200 -s300 ... Ya da örneğin: 1mio DVD'li kamyon daha yavaş sürer, çünkü 1 DVD'li olandan daha ağırdır.
Andreas Richter

2
@andreas ping zamanı tüm hikaye değildir - bu yüzden MTU'dan daha düşük paketlerin tam MTU'daki paketlerden daha hızlı ulaştığı argümanını ele alalım. farklılık, 1 paketin 2 paketin gelmesi ile aynı sürede tam mtu'da sahip olduğu tüm verilere sahip değilsiniz. Gecikme, tüm verilerin ulaşması için geçen zamandır. kamyon benzetmesine geri dönmek için, 1 Cd'li bir kamyonun 500 cds taşıyan kamyonun yarısında gelmesine rağmen, veriyi teslim etmek için yine de 500 kamyon seferi yapar (750 güne karşı 3).
Jim B

@JimB: evet, bahsettiğim gibi sorum yük boyutu hakkında değil, hız hakkında: tam kamyon gümrük tarafından taranması için 10 saat gerekiyor, küçük olan sadece 1 saat. 100mbit / s, ayrıca 100 bitlik bir paketin teorik minimum 0.000954ms ve 1000bitlik bir paketin teorik minimum 0,00954ms'ye ihtiyacı olduğu anlamına gelir. Tabii işlem süresi / vb. ağ kartı / anahtar / vb. tüm gecikmenin daha yüksek bir yığınını yapın, ancak bunların 1 gbit anahtarda daha hızlı olmasını da beklerim.
Andreas Richter

@andreas -% 20 aynı alt sorunuzun irrlevant olduğunu
Jim B

1
@andreas, milisaniyenin altında bir ping'in% 20'si hala bir milisaniyenin altında bir pingdir. Milisaniyenin altında bir pingin% 150'si bile, testinizde olduğu gibi, gerçek dünyada önemli olmayacaktır. Verilerinizin 0.0002 saniye yerine 0.0003 saniye içinde oraya ulaşıp ulaşmadığı önemli bir uygulamanız var mı?
Shane Madden

2

Dünyaya bir iğne deliğinden bakıyorsunuz. Farklı hızlarda gecikme farklarının geçerli bir testi, çapraz bağlantı kablosuyla bağlı iki özdeş NIC arasında olacaktır. 10mb, 100mb ve 1000mb NIC'lerin eşleşme hızlarını ayarlayın. Bu, farklı hızlarda gecikmede neredeyse hiçbir fark olmadığını gösterecektir. Tüm paketler, kullanılan maksimum bant genişliğine bakılmaksızın aynı kablo hızında gider. Kaydetme ve ileri önbellekleme ile anahtarlar eklediğinizde her şey değişir. Bir anahtar üzerinden test gecikmesi, anahtara yalnızca iki bağlantı ile yapılmalıdır. Başka herhangi bir trafik testinizin gecikmesini etkileyebilir. O zaman bile, anahtar günlükleri devirebilir, paket tipi sayaçları ayarlayabilir, dahili saati güncelleyebilir, vb. Her şey gecikmeyi etkileyebilir.

Evet, donanım değişiklikleri, farklı NIC, farklı anahtar, farklı sürücü nedeniyle 100mb'den 1gb'ye geçiş daha hızlı (düşük gecikme) olabilir. Ben sürücü farklılıkları ping gecikme diğer değişikliklere göre daha büyük değişiklikler gördüm; bant genişliği, anahtarlar, boşaltma NIC'leri, vb.

Anahtar, tekli iletim testleri için depodan ve ileriye doğru önemli ölçüde daha hızlı geçiş ile bir sonraki en büyük değişiklik olacaktır. Bununla birlikte, iyi tasarlanmış bir mağaza ve ileri anahtar, yüksek yük altında genel performansta geçiş anahtarını geçebilir. Gigabit'in ilk günlerinde ucuz gigabit anahtarlardan daha düşük gecikme süresine sahip 10mb yüksek performanslı arka panel anahtarları gördüm.

Ping testleri, interneti kullanırken performans analizi için pratik olarak önemsizdir. Test anında ulaşımda neler olduğu hakkında bir basketbol sahası fikri almak için hızlı testlerdir. Üretim performansı testi sadece bir ping'ten çok daha karmaşıktır. Yüksek performanslı anahtarlar bilgisayarlardır ve yüksek yük altında farklı davranırlar - gecikmede değişiklik.

Daha yavaş bir NIC'ye veya daha düşük bir hıza ayarlanmış bir NIC'ye sahip olmak, anahtar önbelleğini kullanarak girişi sunucuya daraltarak eşzamanlı patlamalara sahip bir sunucuya gerçekten yardımcı olabilir. Tek bir yeniden iletim gecikme süresindeki herhangi bir azalmayı reddedebilir. Genellikle orta ve yüksek yük trafik seviyeleri önemlidir, tekil ping testleri değil. Örneğin, eski yavaş Sun Ultrasparc (tek bir ping için daha yüksek gecikme süresi),% 70 100mb bant genişliği yükünün altında dev sunucusu olarak kullanılan yeni ucuz gigabit masaüstünden daha iyi performans gösterir. Masaüstü daha hızlı gb NIC, daha hızlı bağlantı gb-gb, daha hızlı bellek, daha fazla bellek, daha hızlı disk ve daha hızlı işlemciye sahiptir, ancak ayarlanmış sunucu sınıfı donanım / yazılım kadar iyi performans göstermez. Bu, gb-gb çalıştıran geçerli ayarlı bir sunucunun eski donanımdan daha hızlı olmadığı, hatta daha büyük iş yüklerini kaldırabileceği anlamına gelmez. "Sorusu daha karmaşıktır."

Sağlayıcınızın 100mb ve 1gb bağlantıları için farklı anahtarlar kullanıp kullanmadığını öğrenin. Aynı anahtar arka panelini kullanırsam, yalnızca trafik seviyeleri düşük bant genişliğini aşarsa artış için ödeme yaparsınız. Aksi takdirde kısa sürede diğer birçok kullanıcının gigabit'e geçeceğini ve eski anahtarda kalan birkaç kullanıcının artık daha yüksek performansa sahip olduğunu görebilirsiniz - anahtardaki yüksek yükler sırasında (yalnızca sunucularınıza değil, genel anahtar yükü) ).

Elmalar ve portakallar örneği: Yerel ISS, birlikte verilen hizmetler, DSL ve telefon için yeni bir anahtar sağladı. Başlangıçta kullanıcılar performansta bir artış gördü. Sistem aşırı satıldı. Artık eski anahtarda kalan kullanıcılar daha yüksek tutarlı performansa sahipler. Gece geç saatlerde, yeni sistemdeki kullanıcılar daha hızlıdır. Akşam yüksek yük altında eski anahtar istemcileri yeni aşırı yük sisteminden açıkça daha iyi performans gösterir.

Düşük gecikme süresi her zaman daha hızlı teslimatla ilişkili değildir. Tek bir sayfa sunmak için 20 istekte MySQl'den bahsediyorsunuz. Bu trafik, sayfa istekleriyle aynı NIC'de olmamalıdır. Tüm dahili trafiği dahili bir ağa taşımak, giden NIC'deki çarpışmaları ve toplam paket sayısını azaltır ve tek bir paketin .04ms gecikme kazancından daha büyük kazançlar sağlar. Sayfa yükleme gecikmesini azaltmak için sayfa başına istek sayısını azaltın. Sayfa yükleme sürelerini azaltmak için sayfaları, html, css, javascript, resimleri sıkıştırın. Bu üç değişiklik, .04 ms'lik bir gecikme azalması elde etmek için kullanılmayan bant genişliği için ödeme yapmaktan daha büyük toplam kazançlar sağlayacaktır. Ping'in 24 saat boyunca çalışması ve gerçek gecikme değişikliğini görmek için ortalaması alınmalıdır. Akıllı anahtarlar artık küçük başlangıç ​​bant genişliği artışları ve büyük aktarımların daraltılmasıyla uyarlanabilir RTSP tipi azaltma yapıyor. Sayfa boyutlarınıza (grafik, büyük html / css / javascript) bağlı olarak, başlangıç ​​bağlantı gecikmelerini / bant genişliğini büyük bir sayfadan veya tam sayfa aktarımlarından çok daha düşük / yüksek görebilirsiniz. Sayfanızın bir kısmı yayınlanıyorsa, sayfa ile yayın arasında önemli ölçüde farklı performans görebilirsiniz.


Tüm büyük girdiler için teşekkür ederiz: 1.) Aynı anahtar, 2.) Dahili / harici sesler için ikinci bir NIC resonable ve denemeye değer - örneğin MySQL / vb. hepsi iki yönlüdür, bu yüzden çarpışmalar "sadece" yarıya düşürülür, 3) Gerçek dünya testi sadece Nic-Nic'e tercih edilir, Mike bunu bir alt ağ ile yaptı ve beklediğiniz şeyi elde etti. donanım: "56 bayt =% 19 iyileştirme, 200 bayt =% 27, 1000 bayt =% 59! Bu yüzden paket ne kadar büyük olursa o kadar önemli olur. Gigabit yalnızca 0,17 ms'den (56 bayt) 0,23 ms'ye (1000 bayt) yükseldi. ) =>% 35, 100 Mbit ise 0.21'den 0.56'ya yükseldi =>% 166 ".
Andreas Richter

1

Diyelim ki 300 baytlık paketler (eğer kullanırsanız -s 300başlıklar nedeniyle daha büyük olur).

300 bytes = 2400 bits
2400 bits / 100Mbit/sec = 0.024ms

0.024 ms, yaklaşık olarak çerçeveyi göndermek için gereken gerçek süredir (ortam erişim süresini veya başlıkları saymaz).

Bir ping-pong dizisinde bu sürenin (0.048 ms) iki katı, artı işletim sisteminin sorguyu işlemesi için geçen süre gerekir.

Bu benim için gecikmenin çeşitli genel gider faktörlerinin% 90'ından kaynaklandığı anlamına gelir. Gb ile çok fazla fark görüp görmeyeceğinizden emin değilim. Muhtemelen 1 ms'den daha az bir fark, bir web sunucusu üzerinde fark edilmeyecektir.

Her neyse, 1400 bayt gibi gerçekten büyük bir paketle deneyebilir misiniz?


Birisi zaten belirli bir sunucu için sayıları çalıştırdı ve fark 40 nanosaniyede geri döndü. Tahmininiz 25 kat fazla büyük bir faktör tarafından kapatılmıştır.
Chris S

@LatinSuD: Yapıcı yaklaşım için teşekkür ederim ve ne yaptığımı bilmediğimi suçlamıyorum. Oradaki biçimlendirmeyi yapabileceğim için sonuçları asıl soruya göndereceğim. Ama btw. Ayrıca ağ kartlarındaki işlemciler GBit için de daha hızlı olduğu için % 90 ek yükün bir hız artışı olmasını beklerdim (umarım). @ChrisS: mikro saniye ve 25 ile ne demek istediğinizi anlamıyorum.
Andreas Richter

Mikro ve nano'yu karıştırdığım için özür dilerim; her durumda algılanamaz. LatinSuD, Mike tarafından bulunan 40 mikrosaniyeden 25 kat daha fazla olan 1 milisaniyelik bir fark öngördü.
Chris S

@ChrisS: endişelenme. 0,04 ms 38 baytlık bir ping içindi, eğer ortalama sunucu-sunucu paketimiz yaklaşık 300 bayt ise, fark 0,4 ms olabilir. Şimdi bir web sunucusu gereksinimi (Redis, MySQL, vb.) İçin 20 talepte bulunursak, bu 8ms'lik bir hız artışına yol açar ve bu da mevcut web istekleri için% 10'luk bir hız artışı olur ve ek maliyetleri tamamen haklı çıkarır. Testleri kendim yürütmek için burada kaynaklara sahip değilim, ama inan bana, insanlar tarafından algılanmasa bile, hala alakalı olabilir. Elektrik veya tanrı gibi.
Andreas Richter

1
@Andreas, bunun böyle ölçekleneceğinden şüpheliyim; her ikisi de 10 kat daha büyük bir paket 10 kat daha az gecikme ve 20 kat daha fazla paket 20 kat daha hızlıdır. Çıkarılırsa, bu ağ ek yükünde% 10'luk bir azalmadır, yine de uygulamada harcanan süreyi hesaba katmanız gerekir; bu, ağ gecikmesi bileşeninden bir ila birkaç büyüklükte daha büyük olabilir. Umarım her durumda sizin için iyi çalışır.
Chris S

1

Bu, bağlandığınız anahtarın türüne bağlıdır. Bazı satıcılarda (Crisco gibi ... yani Cisco), ICMP paketleri CPU'ya ( gag ) geri akacaktır .

Daha iyi bir test, 100Mbps ve 1Gbps bağlantısı kullanarak bir ana bilgisayardan ana bilgisayara testi yapmak olabilir (yani bir ana bilgisayardan anahtara veya ana bilgisayardan yönlendiriciye testi değil).

Günün sonunda, gecikme, anahtardaki yönlendirme hızına ve anahtar mimarisinin ayrıntılarına inecektir (ASIC'lerin tahtaya yerleştirildiği, satır kartları arasında kilitlemenin nasıl gerçekleştirileceği vb.). Testinizde iyi şanslar.


Teşekkür ederim, sadece Host-Switch-Host testlerine bakıyorum ve tüm switch interna'ları anlamıyorum. Birisi daha önce kıyaslanırsa görmek isterim: Host- (100mbit) -Switch- (100mbit) -Host, Host- (100mbit) -Switch- (1gbit) -Host ve Host- (1gbit) -Switch- (1gbit ) Farklı paket boyutları için en yüksek gecikme süresi. Kimse yapmadıysa, bunu yapacağım ve cevabı buraya göndereceğim.
Andreas Richter

1
Eskiden anahtar dişlisini satardım. Söylemek yeterli, bulgularınız bana bir Cisco anahtarına bağlı olduğunuzu gösteriyor. Daha düşük gecikmeler sağlayan başka alternatifler de vardır. Haklı olarak işaret ettiğiniz gibi, daha fazla bant genişliği daha düşük gecikmelere dönüşmez (Comcast, insanları bu konuda aptal hale getirmek için birincil suçludur). Barındırılan bir ortamda olduğunuz göz önüne alındığında, muhtemelen donanımlarına takılı kalıyorsunuz (ve barındırılan bir ortamda, fazladan birkaç microsec çok önemli değil). Kararlı durumda milyonlarca pps göster ve daha fazla ayrıntı sunmakla ilgileneceğim. :)
Sean
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.