504 Gateway Timeout: Yavaş Arka Uçlar ve Zaman Aşımları
Bir 504 Gateway Timeout, bir proksinin arka ucunuza ulaştığı, bir yanıt beklediği, ve biri gelmeden vazgeçtiği anlamına gelir. Hiçbir şey çökmedi ve hiçbir şey isteği reddetmedi: proksinin arkasındaki bir şey, proksinin beklemeye razı olduğundan daha yavaştır.
Bir 504 ne raporlar
RFC 9110, erişmesi gereken bir üst akış sunucusundan zamanında bir yanıt almayan, ağ geçidi veya proksi olarak davranan bir sunucu için 504'ü tanımlar. "Zamanında" kelimesi spesifikasyon tarafından değil yapılandırma tarafından tanımlanır, bu yüzden bir 504 her zaman aynı anda iki şey hakkında bir ifadedir: arka ucun ne kadar yavaş olduğu, ve proksinin hangi sınıra ayarlandığı.
Bunun önemli bir pratik sonucu vardır. Bir proksi 504 döndürdüğünde, arka uç genellikle istek üzerinde çalışmaya devam eder. İstemciye olan bağlantı gitmiştir, ama yavaş sorgu hala çalışıyordur, rapor hala oluşturuluyordur, ve kaynaklar hala tutulmaktadır. Bu yüzden bir 504 dalgası genellikle bir sunucuyu daha da kötüleştirir: her terk edilmiş istek arkasında iş bırakır, ve kuyruk boşaldığından daha hızlı büyür.
504'e karşı 502'ye karşı 503
| 502 Bad Gateway | 503 Service Unavailable | 504 Gateway Timeout | |
|---|---|---|---|
| Ne oldu | Arka uç geçersiz bir yanıt verdi veya bağlantıyı kapattı | Sunucu işi kasıtlı olarak reddetti | Arka uç işi kabul etti ve zamanında hiç yanıtlamadı |
| Arka uç durumu | Çökük, çöküyor, veya yanlış protokol konuşuyor | Çalışıyor, ama aşırı yüklü veya bakımda | Çalışıyor ve meşgul, hala işliyor |
| Yanıt hızı | Genellikle anında | Genellikle anında | Yavaş, zaman aşımı sınırında gelir |
| Tipik günlük satırı | connect() failed veya upstream prematurely closed connection | Bakım kuralı, veya sağlıklı üst akış yok | upstream timed out (110: Connection timed out) |
Retry-After | Alışılmadık | Yaygın ve önerilir | Alışılmadık |
| Bakılacak ilk yer | Arka uç süreci çalışıyor mu? | Kapasite, bakım bayrakları, sağlık kontrolleri | Yavaş sorgular ve yavaş bağımlılıklar |
Pratikte bir 502 hızlı başarısız olur, bir 503 kibarca reddeder, ve bir 504 önce sizi bekletir. Diğer ikisini eksiksiz olarak, özel 502 rehberi ve 5xx genel bakışı kapsar.
Arka uç neden çok yavaş
- Yavaş veritabanı sorguları. Eksik bir indeks, veriyle birlikte büyüyen bir sorgu, bir döngüde bir N+1 deseni, veya eşzamanlılık altında kilit çekişmesi. En yaygın tek neden.
- Yavaş üçüncü taraf çağrıları. Kendi zaman aşımı olmayan giden bir API isteği, uzak servisin en kötü gününü miras alır ve ziyaretçilerinize aktarır.
- Soğuk başlangıçlar. Bir ölçeklendirmeden, bir konteyner başlatmasından veya boşta bir dönemden sonraki ilk istek, başlatma, bağlantı kurulumu ve önbellek ısıtmasının hepsinin bedelini bir kerede öder.
- Bir web isteğinde gerçekten ağır iş. Eşzamanlı olarak ele alınan rapor oluşturma, dışa aktarmalar, resim işleme veya toplu içe aktarmalar sonunda herhangi bir makul zaman aşımını aşar.
- Kaynak çekişmesi. CPU doygunluğu, bellek baskısı ve takas alanı kullanımı her isteği yavaşlatır, bu yüzden en yavaş olanlar sınırı ilk geçenlerdir.
- Çok sıkı ayarlanmış zaman aşımları. Bir uç nokta meşru olarak proksinin izin verdiğinden daha uzun süreye ihtiyaç duyuyorsa, hatalı olan koddan çok yapılandırmadır.
- Sıçramalar arasındaki ağ sorunları. Üst akış adresi için paket kaybı veya DNS çözümleme gecikmeleri, uygulama zamanlamalarında görünmeyen gecikme ekler.
Bir 504 nasıl teşhis edilir ve düzeltilir
- Hataya kadar geçen süreyi ölçün. Bir 504'ten önceki gecikme genellikle yapılandırılmış zaman aşımıyla eşleşir, ki bu da size hangi sıçramanın onu ürettiğini söyler:
Neredeyse tam olarak 60 saniyede bir 504, varsayılan bir proksi okuma zaman aşımını işaret eder. 30 veya 100 saniyedeki bir tane, o sayıyla yapılandırılmış olan bileşeni işaret eder, ki bu genellikle kendi proksinizden çok bir CDN'dir.curl -sS -o /dev/null -w "%{http_code} %{time_total}s\n" https://example.com/slow-page - Bunun tek bir uç nokta mı yoksa hepsi mi olduğunu bulun. Yavaş tek bir URL bir uygulama sorunudur. Aynı anda her şeyin yavaş olması kaynak doygunluğu veya başarısız bir bağımlılıktır.
- Proksi hata günlüğünü okuyun. nginx ile satır açıktır:
Üst akışı ve aşamayı adlandırır, ki bu da yavaş bir bağlanmayı yavaş bir yanıttan ayırır.[error] upstream timed out (110: Connection timed out) while reading response header from upstream, upstream: "http://127.0.0.1:8080/" - Arka ucu proksi olmadan doğrudan zamanlayın. Aynı istek kaynağa karşı 90 saniye sürüyorsa, proksi gerçeği raporluyordur ve düzeltme uygulamaya aittir.
- Yavaş yolu profilleyin. Önce yavaş sorgu günlüğünü, sonra uygulama izlerini kontrol edin. Çoğu 504, tek bir sorguya veya tek bir giden çağrıya çözümlenir.
- Zaman aşımından önce nedeni düzeltin. İndeksi ekleyin, pahalı sonucu önbelleğe alın, veya gerçekten uzun işi hemen dönen ve ilerlemeyi ayrı raporlayan bir arka plan işine taşıyın.
- İş meşru olarak uzun olduğunda zaman aşımını yalnızca o zaman yükseltin, ve onu her sıçramada tutarlı şekilde yükseltin. 30 saniyelik bir CDN sınırı, 120 saniyelik bir kaynak zaman aşımını anlamsız kılar.
- Yavaş bir bağımlılığın, proksi vazgeçene kadar bir işçiyi tüketmek yerine net bir hatayla hızlıca başarısız olması için kendi giden çağrılarınıza zaman aşımları koyun.
Yanıt süresi erken uyarıdır
Bir 504, bir süredir biriken bir yavaşlamanın son durumudur. Yanıt süreleri yarım saniyeden iki saniyeye, sonra ona sürüklenir, ve istekler sınırı geçmeye başlayana kadar kimse fark etmez. Zamanlanmış bir HTTP kontrolü, her kontrolün yanıt süresini durum koduyla birlikte kaydeder, bu yüzden eğilim ilk zaman aşımından çok önce bir grafik olarak görünür, ve uyarı destek kuyruğu dolduktan sonra değil ilk gerçek başarısızlıkta gelir. Birkaç bölgeden kontrol etmek de yardımcı olur, çünkü bir kıtadan hızlı ve diğerinden yavaş bir rota, veritabanınızdan çok ağ yolunu veya kenar yapılandırmasını işaret eder.