Etkileyici performans artışları önemli olmadığında

• Performans optimizasyonu, karmaşık sistemleri anlamak ve ürünü geliştirmek için güçlü bir araçtır; ancak 10 kat daha hızlı sonuçlar bile gerçek çalışma biçimini veya iş hacmini değiştirmeyebilir
• Sorgu yanıtını 5~10 dakikadan 30 saniye~1 dakikaya indirmek bile, insanın beklerken dikkatini koruduğu yaklaşık 10 saniyelik eşik aşılıyorsa hissedilen etkiyi sınırlı bırakır
• İşler günde 1 veya 2 görev gibi tam sayı birimlerine bağlıysa, %25~50 iyileşme yeterli olmaz; yolculuk süresi dahil her işin 4 saatin altına inmesi gerekir ki günde 2 iş mümkün olsun
• Veri pipeline'larında yavaş bir aşama yukarı akışa backpressure uygular; bu yüzden tek bir aşama ciddi biçimde hızlansa bile, tüm darboğazlar çözülmeden uçtan uca throughput artmayabilir
• Performans iyileştirmeleri tekil benchmark'lara göre değil, istenen sonuca göre değerlendirilmelidir; dikkat süresini koruma, iş birimini artırma veya toplam throughput gibi kısıtlar aşılamıyorsa büyük iyileştirmelerin bile pratik etkisi sınırlı kalır

---

Performans rakamlarıyla gerçek sonuçlar neden uyuşmaz

• Performans çalışmaları, sistemi daha verimli hale getirip müşterilere yeni olanaklar sunabildiği için tatmin edicidir
• Ayrıca ölçek ve yük altındaki karmaşık sistemlerin nasıl etkileştiğini ampirik olarak anlama konusunda da yardımcı olur
• Sisteme yakından bakma sürecinde ürün ve hizmetleri geliştirecek fikirler ortaya çıkar; bunların bir kısmı performans optimizasyonuyla doğrudan ilgili bile değildir
• Ancak “10 kat daha hızlı”, “%50 daha az kaynak” gibi göze hoş gelen sonuçlar da gizli kısıtları aşamıyorsa beklenen değişimi yaratmakta zorlanabilir

10 saniyeyi aşınca kullanıcının dikkati kopar

• Yeni bir veritabanında sorgu performansını iyileştirerek, eski veritabanında en maliyetli sorguların 5~10 dakika sürmesini 30 saniye~1 dakikaya indiren bir örnek vardır
• Bu sonuç yaklaşık 10 katlık bir iyileşmeydi, ancak kullanıcı deneyimini gerçekten değiştirmek için bir büyük sıçrama daha gerekiyordu
• İnsan-bilgisayar etkileşimi araştırmaları, kişinin tüm göreve dikkatini sürdürebildiği sınırı yaklaşık 10 saniye olarak görür
  • 0,1 saniye, anlık geri bildirim olarak algılanan eşiktir
  • Yaklaşık 1 saniye, görev akışının kesilmeden sürdüğü eşiktir
  • Yaklaşık 10 saniye, tüm göreve dikkatin korunabildiği eşiktir
  • İlerleme göstergesi veya tahmini süre gibi geri bildirimler, dikkatin korunmasına yardımcı olabilir
• 30 saniye de 5 dakika da 10 saniyeyi aştığı için kullanıcı mesajlarını kontrol eder, kahve almaya gider, bir sohbete başlar ya da başka bir işe geçer
• Kullanıcı birkaç dakika veya birkaç saat sonra geri döndüğünde UI zaten yüklenmişse, gerçek bekleme süresinin 30 saniye mi yoksa 5 dakika mı olduğu çalışma biçiminde büyük fark yaratmaz
• O projede sonunda birçok sorgu 10 saniyenin altına indirildi ve daha önce timeout nedeniyle mümkün olmayan bazı sorgular da çalıştırılabilir hale geldi
  • Genel performans iyileştirmesi için yalnızca veri sorgusu gecikmesi değil, metadata sorgusu gecikmesi ve web sayfası render süresi de önemliydi
  • Asenkron IO ve veri toplulaştırma iyileştirmeleriyle bir 10 katlık sıçrama daha mümkün görünüyor; bu gerçekleşirse eskiden birkaç dakika süren sorgular 1 saniyenin altında dönebilir

Günde 1 işten 2 işe geçme eşiği

• Bir projede manuel işleri otomatikleştirme, gereksiz adımları kaldırma, kısmi paralelleştirme ve daha sonra asenkron yapılabilecek adımları erteleme sayesinde tüm süreç birkaç saatten istikrarlı biçimde 1 saatin altına indirildi
• İyileşme oranı yaklaşık %25~50 idi, ancak tüm süreç lojistik kısıtlar nedeniyle değişmedi
• Bunun için tesisatçı, elektrikçi veya marangoz gibi önce bir lokasyona gidip zamanı ayırarak işi tamamlaması gereken durumlar düşünülebilir
  • Günde 8 saat çalışılıyorsa ve tek bir lokasyondaki iş 8 saat sürüyorsa, 2~3 saat tasarruf etmek yeni bir lokasyona gidip yeni işi bitirmeye yetmez
  • Yolculuk süresi dahil her iş 4 saatin altına inmedikçe günde 2 iş tamamlamak mümkün olmaz
• Bu tür eşikler aşılmadan, ara adımlardaki verimlilik artışı üretim miktarında artışa dönüşmez
• Performansa odaklanmak, müşteri deneyimini doğrudan etkileyen kalite ve güvenilirlik iyileştirmelerini de beraberinde getirebilir
  • Production ortamında dönüm noktası yaratmayan küçük performans artışları bile test ortamındaki yineleme hızını artırarak özellik geliştirme ve hata çözümünü hızlandırabilir

Backpressure olan pipeline'lardaki darboğazlar

• Pek çok kurumsal yazılım altyapısında araçlar, fabrika ekipmanları, cep telefonları ve finansal işlemler gibi çeşitli kaynaklardan gelen olayları işleyen veri pipeline'ları bulunur
• Olaylar genellikle dayanıklı bir log'a yazılır ve aşağı akış servisleri bunları tüketip işler
• Büyük ölçekte yüksek throughput için log'un partition edilmesi gerekir; aşağı akış servisleri de batching, pipelining, paralellik, verimli bellek tahsisi ve dinamik ölçekleme gibi tekniklerden yararlanır
• Veri pipeline'larındaki darboğazları bulmak zordur çünkü sistem davranışları birbiriyle bağlantılıdır
  • Yavaş bir aşama, kasıtlı olarak yukarı akış aşamalarına backpressure uygular
  • Birden fazla darboğaz varsa, son darboğaz kaldırılana kadar toplam throughput artmayabilir
• Pipeline'ı aşamalara ayırıp her aşamanın performans özelliklerini ve sınırlarını anlamak iyi bir mühendislik pratiğidir
• Ancak tek bir aşamayı birkaç mertebe iyileştirmek bile toplam throughput üzerinde hiçbir etki yaratmayabilir
• Throughput iyileştirmesinde önemli olan metrik, tek tek aşamaların benchmark'ları değil uçtan uca throughput değeridir

Darboğaz bulmak için ampirik yaklaşım

• Bu tür sistemlerin dinamiklerini ve darboğazlarını anlamak için, pipeline'ın başlangıç noktasından itibaren ampirik doğrulama yapmak faydalıdır
• Örneğin, dağıtık log'dan olayları okuyup atan aşamayla başlanabilir
  • Yalnızca bu aşama bile hedef throughput'a ulaşamıyorsa, aşağı akış aşamalarını optimize etmek zaman kaybı olur
• Veritabanına saniyede kaç satır eklenebildiği gibi aşağı akış benchmark'ları da önemli olabilir; ancak analiz yukarı akıştan başlamalıdır
• Karmaşık sistemleri ve performansı anlamada simülasyonlar da değerli bir yöntemdir
  • Marc Brooker'ın Simple Simulations for System Builders
  • Try again: The tools and techniques behind resilient systems

Performans iyileştirmesinin ölçütü istenen sonuçtur

• Performans çalışmaları zordur, ancak aynı zamanda karmaşık sistemleri derinlemesine anlamak ve daha iyi ürünler üretmek için de bir eğitimdir
• İnsan dikkatini elde tutmak istiyorsanız, yanıtın yaklaşık 10 saniye içinde gelmesi gerekir
• Kısıt toplam iş birimindeyse, yüzdesel iyileştirme yetmez; günde 1 işten 2 işe geçiş mümkün olmalıdır
• Backpressure içeren pipeline'larda throughput'u en üst düzeye çıkarmak için, çoğu zaman bir veya iki değil tüm darboğazların çözülmesi gerekir
• Bu tür kısıtlar aşılamıyorsa, 10 katlık performans artışları bile istenen sonucu üretmeyebilir

[GN⁺]

Lobste.rs yorumları

• Toplam throughput üzerinde etkisi olmayan tek bir aşamayı onlarca kat iyileştirip hayal kırıklığına uğrama durumuysa, burada Amdahl yasasına değinmek yerinde olur

  • Bilgisayar biliminin geneline yayılmış çeşitli yasa adları derlemesi gibi bir şey var mı merak ediyorum
    Sürekli yeni yasalar duyuyorum; ama sık kullanılmayacak kadar niş oldukları için sonra yine unutuyorum. Bu, o yasaların kuşaklar arası bilgi olarak geçerli ya da yararlı olmadığı anlamına gelmiyor

• En başta toplam sürenin çok küçük bir parçasını oluşturan kısmı neden optimize ettikleri soru işareti
  Yönlendirme mi kötüydü, performans araçları mı yetersizdi, bilmiyorum. Bilinçli olarak etkisi neredeyse olmayan bir iş yapmaya çalışan insan azdır; genelde daha büyük bir sorun gizlidir

  • Böyle bir şeyin ortaya çıkma yollarından biri kabaca şöyle bence
    Bir probleme bakarken örnekleme sonuçlarında belirli bir fonksiyon büyük görünür; kısa bir bakışla implementasyonu epey kolay iyileştirilebilecek gibi durur. Ama o sırada başka bir işle meşgulsünüzdür, “sonra hallederim” diye ertelersiniz
    Daha sonra o kolay iyileştirme aklınıza gelir ve başlarsınız; ama değişiklik beklediğinizden karmaşık hale gelse bile tünel görüşü oluşur, bulmacayı çözmek istersiniz ve çok zaman harcarsınız
    Oysa gerçekte o performans sorunu önemsizdir. O an baktığınız bağlam içinde oransal olarak büyük görünmüş olabilir, mutlak süre pek anlamlı olmayabilir ya da CPU değil I/O tarafından sınırlanıyor olabilirsiniz. Bir tür kendi kendine nerd sniping gibi
  • Google’da bir kez, pipeline’ın bir bölümünü optimize etme önerisi vardı ve birkaç kişi o bölümün toplam hesaplama miktarının %0,1’inden azını oluşturduğunu, dolayısıyla toplam kazancın da tanım gereği %0,1’den az olacağını açıkladı
    Yine de bunu görmezden gelip optimizasyona devam ettiler; toplam iyileşme %0,1’in altında çıkınca şaşırdılar. Alan bilgisiyle sezgisel olarak da pahalı olmayan bir bölümdü, ama zaman kaybetmesinler diye gerçek performans maliyetini ölçmeye kadar yardımcı olduk
  • Tahminle hareket ediyor, her zaman uyguladıkları en iyi pratikleri içselleştirmiş ya da sınırlı bir durumda gördükleri gerçek bir sorunu aşırı genellemiş olabilirler
    Ya da benchmark yanıltıcı olmuş olabilir. Her sistem, üretim ortamında her metodun ya da sürecin maliyetini kolayca göstermiyor
    Bu açıklamaların hepsi derece farkıyla da olsa işlev bozukluğuna yakın; bazıları daha çok kişinin sorunu, bazıları daha çok ortamın sorunu
  • Olası birkaç neden var
    1. Yetenekli bir junior mühendisin problem çözmeyi öğrenmiş ama çözmeye değer problemi seçmeyi öğrenmemiş olması. Bulduğu her verimsizliğe, uçtan uca etkisinden bağımsız olarak saldırır. Şanslıysa biri öğretir; değilse PM’in sıkı kontrol etmesi gereken bir senior mühendiste takılı kalır
    2. Uçtan uca performansı düzgün görememek. Sistemin bir yerinde performans düşüşü vardır ve yönetim baskı yapar; ama doğru düzgün monitoring kurma yetkisi alamazsınız, bu yüzden tahminle çeşitli bileşenleri kurcalayıp birinin tutmasını umarsınız. Sonra acil yangın sönünce yeniden kullanıcı özellikleri çıkarmaya dönersiniz
    3. Şu an sorun değildir ama yakında sorun olacağından korkup önceden düzeltmek. Yeterince etkiniz varsa ya da fazla mesaiyi dayatabiliyorsanız, hemen görünen bir etkisi olmasa da ilerlersiniz. Harika mühendisler de gelecekte önemli olacağına inanırsa siyasi sermayesini buna harcar; daha kötü mühendisler ise hepsini yakıp tüketir
       3.1. Bir hyperscaler’da çalışıyorsanız, kullanıcıya hiç görünmeyen hesaplama miktarında %0,1 tasarruf bile kârlılık üzerinde sahil evi parasını karşılayacak kadar etki yaratabilir
    4. Meydan okumaya dayanamamak. Gerçekte hiçbir şeyin değişmeyeceğini bilirsiniz ama CRUD uygulamaları yapmaktan sıkılmışsınızdır ve blogda gördüğünüz şeyi deneme fırsatı çıkmıştır. Anlamsızlığın ağırlığını hafifletmek için kendinizi nerd snipe etmek gibi
  • Yaygın kanının aksine, birçok sistem yalnızca birkaç bottleneck’ten oluşmaz
    Sık görülen programlama pratiklerinin kendisi çoğu zaman genel olarak yavaştır. Örneğin akla, bolca pointer içeren ve genel allocator üzerinden heap allocation yapan çok sayıda nesne yönelimli kod geliyor. Nereyi düzeltirseniz düzeltin toplam sürenin küçük bir parçasıdır; en kötü durumda tamamen yeniden yazmak dışında çözüm yoktur. Şanslıysanız kademeli olarak yeniden yazabilirsiniz
    Sadece iki bottleneck olsa bile, birbirlerine tek haneli bir çarpan mesafesindelerse, en kötü bottleneck’i kusursuzca düzeltseniz bile tek haneli kat iyileşme bile çıkmaz. Çoğu durumda, yazıda söylendiği gibi anlamlı kazanç için bunun çok daha ötesine geçmek gerekir
    Ayrıca bilgisayarlar paralel çalışan dağıtık sistemlere daha yakındır. Birkaç CPU, GPU, disk, Ethernet vb. vardır; sürecin hızı pipeline’daki en yavaş aşama tarafından sınırlanır. O aşamayı düzeltirseniz bu kez bir sonraki en yavaş aşama sınırlar; en kötü durumda en yavaş aşamalardan birkaç tane vardır ve sadece birini düzeltmek hiçbir kazanç sağlamaz
    Yine de bu iyi niyetli bir yorum; bazen de insan sadece optimizasyon oyununa kapılıp önceliği kaybeder ya da hata yapar

• Kullanıcı fark etmese bile yazılımın hesaplama süresini azaltmak hâlâ iyidir
  Çünkü maliyeti düşürüp ölçeklenmeyi kolaylaştırabilir

  • Bu, karmaşıklık maliyetine bağlı
    Kodu hızlandırmanın bedeli olarak aşırı karmaşıklık gelirse, bakımı bir yana, uzun vadede performansa zarar veren sonraki sonuçlar doğar. Mimari değişikliklerde artık gereksiz hale gelecek kod kalır; onu anlamak ya da kaldırmak için toplam karmaşıklığı tamamen anlamanız gerekir
    “Daha hızlı oluyor” gerekçesi, karmaşıklık ya da bakım yapılabilirlik kaygılarını görmezden gelmek için mazeret olmamalı

• Şu an benzer bir durumdayım; birkaç küçük projeyle 5 dakika süren sorguları 30 saniyenin altına indiriyorum
  Ekibe uzun vadede bunun yeterli olmadığını söylüyorum, ama açıkça bir iyileşme ve etkisi de büyük
  Müşteri açısından bekleme, çileden çıkaracak seviyeden sadece sinir bozucu seviyeye iniyor
  Şu an odak kullanıcı başına performans değil, toplam performans. 5, 10, 30 dakikalık onlarca süreci optimize edince sistemin diğer bölümleriyle oluşan çekişme ciddi biçimde azalıyor. Veritabanını 10 dakika boyunca dövmek çok uzun bir süre ve sonunda her şey hızlanıyor, herkes fayda görüyor