Bir istek yarıda kesiliyor ve nedenini bulamıyorsunuz. Hata mesajı belirsiz, günlüklerde net bir kayıt yok. Sorun genellikle katmanlardan birindeki zaman aşımı ayarında — ve o katmanların sayısı düşündüğünüzden fazla.
Bu yazı, zaman aşımı zincirini ve doğru yapılandırmayı ele alıyor.
Zaman Aşımı Zinciri
Bir istek sunucunuza ulaştığında birden fazla katmandan geçer ve her birinin kendi süresi vardır:
- Yük dengeleyici veya ters vekil
- Web sunucusu
- Uygulama çalışma zamanı
- Veritabanı bağlantısı
- Dış servis çağrıları
- İstemci tarafı
Kritik kural şudur: dıştaki katmanın süresi, içteki katmanların toplamından uzun olmalıdır.
Aksi hâlde dıştaki katman bağlantıyı keser, ama içteki işlem çalışmaya devam eder. Sonuç, kullanıcının hata görmesi ama işlemin arka planda tamamlanmasıdır — ve bu, çift kayıt gibi sorunlara yol açar.
Belirtilerden Katmanı Bulmak
Hangi katmanın kestiğini anlamak için:
| Belirti | Muhtemel kaynak |
|---|---|
| Ağ geçidi zaman aşımı hatası | Ters vekil kesti |
| Boş yanıt, bağlantı kapandı | Web sunucusu veya vekil |
| Ölümcül hata: süre aşıldı | Uygulama çalışma zamanı |
| Sorgu iptal edildi | Veritabanı |
| Tarayıcıda takılı kalma | Hiçbiri kesmemiş |
Üçüncü satır teşhis açısından en iyi durumdur: uygulama seviyesinde kesilen bir istek, hangi satırda takıldığını da günlüğe yazar.
Birinci satırda ise bilgi kaybı vardır — vekil yalnızca "yanıt gelmedi" der, arkada ne olduğunu bilmez. Bu yüzden uygulama süresini vekil süresinden kısa tutmak, teşhis kabiliyeti kazandırır.
Uzun Süren İşler
Bazı işlemler doğası gereği uzundur ve süre artırmak doğru çözüm değildir:
- Rapor üretimi
- Toplu veri aktarımı
- Medya dönüştürme
- Büyük dosya işleme
- Dış servis toplu sorgusu
Bu işlemler için süreyi uzatmak yerine mimariyi değiştirmek gerekir: web isteği içinde dakikalarca süren bir iş, süre yeterli olsa bile web sunucusu sürecini kilitler ve diğer ziyaretçilere yer kalmaz.
Doğru yapı kuyruktur — istek işi kaydeder ve hemen döner, işlem arka planda tamamlanır, kullanıcıya durum gösterilir.
Dış Servis Çağrıları
En kritik zaman aşımı burada tanımlanır:
- Bağlantı zaman aşımı kısa olmalı. Birkaç saniye.
- Toplam süre sınırlı olmalı.
- Varsayılan değere güvenmeyin. Bazı kütüphanelerde sınırsızdır.
- Yeniden deneme sayısını sınırlayın.
- Toplam bütçeyi hesaplayın. Deneme sayısı × süre.
Beşinci madde sıkça atlanan bir hesaptır: on saniyelik zaman aşımı ve üç deneme, aslında otuz saniyelik bir bekleme demektir — ve bu, uygulama süre sınırınızı aşabilir.
Üçüncü madde ise en tehlikeli varsayılandır. Zaman aşımı tanımlanmamış bir istek, karşı taraf yanıt vermediğinde süresiz bekler ve süreç sonsuza kadar meşgul kalır.
Boşta Kalma Süreleri
Aktif istek dışında da zaman aşımları vardır:
| Ayar | İşlevi |
|---|---|
| Bağlantı boşta kalma süresi | Kullanılmayan bağlantıyı kapatır |
| İstek okuma süresi | Yavaş istemcilere karşı |
| Yanıt yazma süresi | Yavaş indirmelere karşı |
| Oturum boşta kalma | Güvenlik için |
İkinci satır bir güvenlik önlemidir: isteği çok yavaş gönderen bir istemci, sunucu kaynaklarını uzun süre meşgul edebilir — bu, bilinen bir kaynak tüketme yöntemidir.
Üçüncü satır ise büyük dosya sunan sitelerde dikkat gerektirir. Süre çok kısaysa yavaş bağlantıdaki kullanıcıların indirmeleri yarıda kesilir.
Pratik Değerler
Başlangıç noktası olarak kullanılabilecek yaklaşım:
- Dış servis çağrısı: En kısa — saniyeler.
- Veritabanı sorgusu: Kısa — çoğu sorgu milisaniyeler sürer.
- Uygulama isteği: Orta.
- Web sunucusu: Uygulamadan biraz uzun.
- Ters vekil: En uzun.
Bu sıralama, sorunun her zaman en içteki katmanda yakalanmasını sağlar: içten dışa doğru artan süreler, hatanın en bilgilendirici katmanda oluşmasını garanti eder.
Ayrıca farklı yollar için farklı değerler tanımlamak mümkündür — dosya yükleme uç noktası uzun, normal sayfalar kısa süre kullanabilir. Bu ayarları doğrudan düzenleyebildiğiniz VDS sunucu hizmetleri yapılandırmasında bu ayrımı kolayca kurabilirsiniz.
Test Etmek
Ayarların gerçekten uygulandığını doğrulamak için:
- Kasten yavaş bir uç nokta oluşturun
- Süreyi kademeli artırarak isteyin
- Hangi noktada hangi hatanın geldiğini kaydedin
- Beklenen katmanın kestiğini doğrulayın
- Test uç noktasını kaldırın
Üçüncü madde haritanızı oluşturur: hangi sürede hangi hatanın geldiğini bilmek, gerçek bir sorunda teşhis süresini dakikalara indirir.
Sonuç
Zaman aşımı ayarlarında tek kural her şeyi belirler: içten dışa doğru artan süreler tanımlayın — böylece hata en bilgilendirici katmanda oluşur ve hangi satırda takıldığını öğrenirsiniz. Dış servis çağrılarında varsayılan değere asla güvenmeyin; bazı kütüphanelerde sınırsızdır. Yeniden deneme sayısını da hesaba katın: on saniyelik süre ve üç deneme, otuz saniyelik bir bekleme demektir. Uzun süren işler için ise süreyi uzatmak değil, kuyruğa taşımak doğru çözümdür.
Sıkça Sorulan Sorular (SSS)
İsteğim kesiliyor, hangi katman kesiyor?
Hata mesajından anlaşılır. Ağ geçidi zaman aşımı hatası ters vekilden gelir; "ölümcül hata: süre aşıldı" uygulama çalışma zamanından. Uygulama seviyesindeki hata en bilgilendiricidir çünkü hangi satırda takıldığını da günlüğe yazar.
Süreleri nasıl sıralamalıyım?
İçten dışa artan şekilde: dış servis çağrısı en kısa, sonra veritabanı, uygulama, web sunucusu ve en dışta ters vekil. Aksi sırada dıştaki katman keser ama içteki işlem çalışmaya devam eder — kullanıcı hata görür, işlem yine de tamamlanır.
Uzun süren işlem için süreyi artırayım mı?
Hayır. Süre yeterli olsa bile dakikalarca süren bir iş web sunucusu sürecini kilitler ve diğer ziyaretçilere yer kalmaz. Doğru çözüm kuyruktur: istek işi kaydedip hemen döner, işlem arka planda tamamlanır.
Varsayılan değerler yeterli değil mi?
Özellikle dış servis çağrılarında değil. Bazı kütüphaneler zaman aşımını varsayılan olarak sınırsız bırakır — karşı taraf yanıt vermediğinde süreç sonsuza kadar bekler. Bu, tek bir yavaş servisin tüm sitenizi durdurmasına yol açar.
