Sunucu yanıt süresi nasıl kontrol edilir

Yanıt süresi, TTFB ve sayfa yükleme aynı sayı değildir

Birbirinin yerine kullanılırlar ve farklı sorulara yanıt verirler:

• Bağlantı süresi, DNS çözümlemesi artı TCP el sıkışması artı TLS el sıkışmasıdır. Çoğunlukla mesafe ve ağ kalitesidir, ve sunucunun kendi kodunun bununla hiçbir ilgisi yoktur.
• İlk bayta kadar geçen süre (TTFB), isteğin başlangıcından itibaren ölçülen, yanıtın ilk baytının geldiği andır. Bağlantı süresini artı sunucunun işlemesini içerir: yönlendirme, veritabanı sorguları, şablon oluşturma, herhangi bir üst akış API çağrısı.
• Sunucu işleme süresi, TTFB eksi bağlantı süresidir. Bu, uygulamanızda düzeltebileceğiniz kısımdır.
• Sayfa yükleme süresi her şeydir: HTML, sonra tarayıcının getirdiği her resim, stil sayfası, betik ve yazı tipi, artı bunları oluşturma işi. Bir sayfanın mükemmel bir TTFB'si olabilir ve yine de yüklenmesi sekiz saniye sürebilir.

Bunları karıştırmak, insanları yanlış şeyi optimize etmeye gönderir. Resimleri sıkıştırmak yavaş bir veritabanı sorgusu için hiçbir şey yapmaz, ve daha hızlı bir veritabanı dört megabayt JavaScript taşıyan bir sayfa için hiçbir şey yapmaz.

curl ile ölçmek

curl, her aşamayı ayrı ayrı raporlar; bu da bağlantı maliyetini sunucu maliyetinden tek bir komutla ayırmanızı sağlar:

curl -o /dev/null -sS -w   "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n"   https://example.com/

Tüm değerler isteğin başlangıcından itibaren saniyedir, bu yüzden her biri kendinden öncekileri içerir. Sunucu işlemesi, ttfb eksi tls'dir, veya düz HTTP'de eksi connect'tir. Bunu üç veya dört kez çalıştırın: ilk istek soğuk bir önbellek veya yeni bir bağlantı için bedel ödeyebilir, ve tek bir örnek bir ölçüm değildir.

Aklınızda tutulması gereken iki şey. Bu yalnızca HTML belgesini ölçer, sayfayı değil, bu yüzden her zaman bir tarayıcı testinden daha hızlı görünür. Ve önbelleğe alınmamış, giriş yapılmış veya arama sayfası genellikle ana sayfadan çarpıcı biçimde daha yavaştır, bu yüzden / yerine önemsediğiniz URL'yi ölçün.

Normal sayılan nedir

Evrensel bir eşik yoktur. Bu bantlar, ziyaretçilerinize yakın bir konumdan ölçülen bir belge isteği için makul bir çalışma kılavuzudur:

• 200 ms altı. Hızlı. Statik içeriğin, sıcak bir önbelleğin veya doğrudan yanıt veren bir CDN kenarının tipik değeri.
• 200 ile 500 ms arası. Bir veritabanını sorgulayan dinamik bir sayfa için normal. Kimse bunu fark etmez.
• 500 ms ile 1 sn arası. Fark edilir. Genellikle bir indekse ihtiyaç duyan bir sorgu, önbelleğe alınmamış bir şablon, veya yavaş bir üst akış çağrısı.
• 1 ile 3 sn arası. Kullanıcılar hisseder, ve arama motorları ölçer. Bir kusur olarak ele almaya değer.
• 3 sn üzeri. Bir şeyler yanlış: doymuş bir sunucu, bir kilit, zaman aşımına uğrayan bir üst akış servisi, veya olması gerekenden çok daha fazla iş yapan bir istek.

Çok daha faydalı karşılaştırma kendinize karşı olandır. Geçen ay 300 ms'de yanıt veren ve bugün 900 ms'de yanıt veren bir sayfanın aradaki bir yerde ortaya çıkan belirli bir nedeni vardır, ve bunu bilmek yayınlanmış herhangi bir kıyaslamadan daha değerlidir.

Neden konuma göre değişir

Mesafe zamana mal olur ve optimize edilerek ortadan kaldırılamaz. İstemci ile sunucu arasındaki her gidiş-dönüş, en azından fiziksel yolun izin verdiği kadar sürer, ve bir TLS bağlantısı, yanıtın ilk baytı başlayabilmeden önce bile birkaç gidiş-dönüşe ihtiyaç duyar. Aynı sunucunun tam olarak aynı işi yaparken yerel olarak 150 ms'de ve başka bir kıtadan 700 ms'de yanıt verebilmesinin nedeni budur.

Yönlendirme de önemlidir, ve mesafeden daha öngörülemezdir: iki ağ arasındaki trafik, bir bölge için gecikme ekleyen ama başka hiçbiri için eklemeyen kötü bir yol izleyebilir. Bir CDN kullanıyorsanız, bazı konumlar yakındaki önbelleğe alınmış bir kopyadan sunulurken diğerleri önbelleği kaçırır ve kaynağa tam gidiş-dönüşün bedelini öder, ki bu da aynı URL için konumlar arasında geniş bir dağılım üretir.

Bu yüzden sunucunuzun bulunduğu yerden değil kullanıcılarınızın bulunduğu yerden ölçün, ve benzerini benzeriyle karşılaştırın. Bir konuma bağlı olmayan bir sayı hiçbir şeyle karşılaştırılamaz.

Yavaşlık ne zaman bozukluk anlamına gelir

Bazı yavaşlıklar bir performans sorunundan çok bir uyarıdır:

• Yük altında istikrarlı biçimde artan bir yanıt süresi, sunucunun doymuş olduğu anlamına gelir. Yalnızca yavaş sayfalarla değil zaman aşımlarıyla sonuçlanır.
• Tam olarak 30 veya 60 saniyede kümelenen süreler yavaşlık değil zaman aşımıdır. Üst akıştaki bir şey yanıt vermiyor ve bir proksi, 504 ile vazgeçmeden önce sınırının dolmasını bekliyor.
• Çoğu zaman hızlı ama arada sırada devasa sıçramalar genellikle bir kilidi, bir cron işini, bir yedeklemeyi, veya süresi dolan ve her isteğin aynı anda yeniden inşa ettiği bir önbelleği işaret eder.
• Yalnızca giriş yapmış kullanıcılar için yavaş olmak, önbelleğin anonim trafiği taşıdığı ve altında gerçekten yavaş bir uygulamayı gizlediği anlamına gelir.
• Yalnızca tek bir bölgeden yavaş olmak, bir uygulama sorunu değil bir ağ veya CDN sorunudur, ve hiçbir arka uç çalışması bunu düzeltmez.

Değiştiği günü fark etmek

Tek bir ölçüm, size yalnızca bir istek için, bir yerden, bir anda ne olduğunu söyler, ve yanıt süresi tam olarak bozulmak yerine sürüklenen türden bir ölçüttür. Zamanlanmış kontroller aynı URL'yi aynı konumlardan sürekli ölçer, değiştiği günü işaret edebilmeniz için geçmişi tutar, ve bir müşteri şikayet ettiğinde değil süre bir eşiği geçtiğinde uyarır. HostTracker bu kontrolleri 158 şehirdeki 300'den fazla kontrol noktasından çalıştırır, bu yüzden bölgesel bir yavaşlama tek başına görünür olur. Şimdi HTTP kontrolü aracıyla bir kontrol çalıştırın. Sunucu hızlı olduğu halde sayfa hala hızlı değilse, yanıtın geri kalanı web sitesi hızı nasıl kontrol edilir rehberindedir.