“Sayfa yavaş” ifadesi, hangi katmanın değişmesi gerektiğini söylemez. Sunucu yanıtı, veritabanı sorgusu, görsel yükü veya tarayıcıda çalışan kod aynı belirtiye yol açabilir. Codex'ten doğrudan önbellek eklemesini istemek, gerçek darboğazı bulmadan çözüm seçmek olur. Daha sağlam başlangıç, belirli bir kullanıcı hareketini ölçülebilir bir probleme çevirmektir. Örneğimizde ürün arama sonuçlarının geç açılmasını inceleyeceğiz.
Ölçülebilir bir başlangıç kaydı oluşturun
Önce hangi işlemin yavaş olduğunu sınırlandırın. İlk sayfa yükü ile arama düğmesine basıldıktan sonraki bekleme farklı ölçümlerdir. Aynı sorguyu, benzer veri büyüklüğünü ve aynı ortamı kullanarak birkaç deneme yapın. Tek bir hızlı ya da yavaş sonuç üzerinden karar vermek yerine değişkenliği görünür kılın.
İlk ölçümde ortamı da kaydedin: Kullanılan revizyon, veri miktarı, sıcak veya soğuk önbellek durumu ve ağ koşulu sonuca etki edebilir. Gerçek ölçüm yokken örnek sayılar üretmeyin. Codex'in araç erişimi sınırlıysa mevcut kayıtları analiz etmesini, eksik ölçüm için uygulanabilir bir yöntem önermesini isteyin. Ölçülmeyen değeri tahmin olarak bile kullanacaksanız açıkça etiketleyin.
Bir hipotezi daraltarak deneyin
Günlükler arama sırasında çok sayıda benzer sorgu gösteriyorsa ilk hipotez veri erişimi olabilir. Tarayıcıdaki bekleme ise büyük bir betik çalışmasına denk geliyorsa farklı yöne bakılır. Hipotez, mevcut kanıtla açıklanmalı ve yanlış çıkmasına izin veren bir deneme içermelidir. “Bu kod yavaştır” demek yerine hangi ölçümün bunu göstereceğini sorun.
Örnek görev:
Ürün aramasındaki gecikmeyi incele. Önce mevcut kayıt ve ölçümlerden beklemenin hangi katmanda oluştuğunu ayır. Uygulama davranışını değiştirmeden karşılaştırılabilir bir başlangıç ölçümü hazırla. Her seferinde tek hipotezi dene; sonucu aynı sorgu ve veriyle karşılaştır. Ölçmediğin hızlanmayı yüzdelik olarak yazma. Yetki filtresi ve sonuç sıralaması korunsun.
Bu talimat performans hedefini doğruluk koşullarıyla birlikte tanımlar. Daha hızlı ama yanlış sonuç dönen bir arama başarılı sayılmaz.
Tek değişkeni değiştirin
Aynı anda sorguyu, önbelleği ve arayüzü değiştirmek, kazancın nereden geldiğini belirsizleştirir. Önce en güçlü kanıta dayanan küçük müdahaleyi uygulayın. Örneğin tekrar eden veri okumasını azaltıyorsanız, değişiklik öncesi ve sonrası sorgu sayısını aynı koşulda karşılaştırın. Sonuç olumlu değilse bunu da kaydedin; başarısız hipotez sonraki araştırmayı daraltır.
Önbellek gibi çözümlerde veri güncelliği davranışını ayrıca değerlendirin. Bir sonuç eski bilgiyi gösteriyorsa yalnızca yanıt süresinin azalması yeterli değildir. Geçersizleştirme koşulu, kullanıcıya göre ayrım ve erişim kontrolü gibi noktalar yeni sorular doğurabilir. Performans düzeltmesinin oluşturduğu bakım yükünü de görünür tutun.
Kazancı kapsamıyla birlikte raporlayın
Sonuç tablosunda aynı senaryonun başlangıç ve son ölçümünü, deneme sayısını ve ortamı gösterin. Ölçüm sadece yerelde yapıldıysa canlı sistem için kesin hızlanma iddiası kurmayın. Farkın küçük ve dalgalanmanın büyük olduğu durumda daha fazla veri gerekebilir. Codex'ten bu sınırları açık bir dille yazmasını isteyin.
Son aşamada normal kullanıcı akışını tekrar kontrol edin. Hızlanan arama doğru kayıtları getiriyor, sayfalamayı koruyor ve hata durumunda anlaşılır davranıyor mu? Böylece performans işi, rastgele optimizasyon eklemek yerine hangi değişikliğin hangi koşulda değer ürettiği gösterilebilen bir araştırmaya dönüşür.
Resmî kaynaklar: OpenAI — Using Goals in Codex, OpenAI — Investigate an incident and test a fix.
