Optimizasyonun fazlası gereksiz pahalı oluyor, çünkü optimizasyon için ayırdığınız vakit aslında bir maliyet (personelin saatlik ücreti üzerinden düşünebiliriz). Belli bir temel optimizasyondan sonraki ince ayar yerine donanıma yatırım yapmak daha ekonomik olabilir.

Ne Kadar Hızlı?

Peki ne kadar hızlı? “Hızlı”nın sonu yok aslında… 10Mbps yerine 20 Mbps, 4GB ram yerine 16GB ram, quadcore bir sürü cpu, sunucu “çiftliği”… ve hatta Yahoo’nun site hızıyla ilgili 13 prensibinden bir tanesi yerel sunuculardan bahsediyor. Yani her şehre bir sunucu koyarsanız çok daha hızlı sunabilirsiniz projenizi.

Yahoo’nun diğer bir prensibi web sunucusuna yapılan istemleri (request) sayıyor. Javascript, CSS ve imajlar gibi statik öğelerin yüksek sayıda olması demek, tarayıcınızın web sunucusuna bir sürü istek yapması demek. Ancak bu statik içeriklerin aslında “cache”de tutulduğu düşünülür ve KeepAlive’ın doğru düzgün ayarlandığı hesaba katılırsa atılan istem sayısının performansa etkisi çok da abartılı değil… Bu da istem sayısını düşürmeye yönelik önlemlere ne kadar vakit ayırmak gerektiği konusunda ikilemde bırakıyor insanı…

Bütün bunların geri dönüşü ne kadar etkiliyor peki?

FotoKritik

Bugün FotoKritik’e ek bir sunucu daha ekledik. Son zamanlarda 1 sn’nin üzerine çıkmaya başlayan php işlem hızı (exec time), tekrar 0.05 mertebelerine düştü.

Anlık ziyaretçi sayılarını karşılaştırdığımızda düne göre 1.5 ~ 2 kat arasında daha çok ziyaretçi gözlemliyoruz. Bunun sayfa gösterimini etkisini önümüdeki günlerde göreceğiz ve önemli bir yükseliş olacağı kesin.

Aslında sitenizin performans nedeniyle ziyaretçi kaybettiğinizi istatistiklerden de görebilirsiniz. Tekil kullanıcı sayınız artıyor ancak sayfa gösterimleriniz düşüyorsa, ya da tekil kullanıcıdaki değişimle kıyaslandığında sayfa gösterimlerinizdeki değişim eksi yönde açılıyorsa performans nedeniyle ziyaretçi kaybettiğiniz sonucuna varabilirsiniz.

Tabii ki ziyaretçi ve gösterim sayılarını etkileyen bir sürü faktör var, bunların içinde gündemden tutun tatillere, benzer içerikteki rakip sitelerin durumundan Türkiye’nin yurtdışı çıkışlarına kadar bir sürü değişken var. Bu değişkenleri takip edip istatistikleri yorumlamak da tabii ki ilgili projenin ekibine kalıyor…

Çoğunlukla bir yerden kazanırsanız diğer bir yerden kaybedersiniz. Mühendislikte bir kaldıraç “dünyayı kaldırabilir” belki ama kaldırabilmesi için kaldıracın uzun tarafı kilometrelerce yol kat etmesi gerekecektir, yani kuvvetten kazanırken yoldan kaybedersiniz. Ekonomide risk yönetimi prensibidir belki ya da Murphy’nin kanunlarında her zaman kazandığınızdan çok kaybedersiniz ama sonuçta birçok durum için geçerlidir bu kural.

Programlamada da işini ne kadar kolaylaştırırsanız o kadar performans kaybedersiniz. Veritabanı işlemleri için bir “wrapper” kullanmak, ayrı dili olan şablon (template) kullanmak ve hatta bunların hepsini bir arada sunan bir framework kullanmak performansı azaltacaktır. Bu konuda sanırım hepimiz hem fikiriz.

Performans konusunda bir kriter fizibilite. Yani performans kayıplarını daha güçlü ya da paralel çalışan sunucularla gidermek performanslı bir altyapıda daha uzun sürede proje tamamlamaktan daha ekonomik olacaktır, bundan daha önce bahsetmiştim. Ama tabii ki performans optimizasyonu olmasın, sıkıştıkça donanıma abanalım demiyorum.

Standart optimizasyonların dışında birazcık hile yapmak da gerekli…

Ruby iyi güzel de çok yavaş

Bu blog ağırlıklı olarak Ruby on Rails’e değiniyor çünkü Rails’in sonuca odaklı hızlı geliştirme yeteneği, yıllardır tercih ettiğim PHP’ye baskın çıkıp kafamı karıştırıyor (!) Ancak ruby’nin php’den yavaş çalıştığı bir gerçek olarak önümüzde yer alıyor.

Tabii hemen şunu da belirteyim ki mesela bir C programı da mutlaka PHP’den hızlı çalışacaktır. İşte bu noktada biraz “hile” yapmaktan zarar gelmez diyorum.

Mesela FotoKritik’in “çöp toplama” işleri için cron’da çalışan programları tercih ediyorum. Ya da günün fotoğraflarını her gece çalışan bir cron betiği seçiyor ve seçilmişleri gösteriyorum kullanıcıya. Şu an fotoğrafların küçük hallerini yükleme sırasında PHP’yle oluşturuyor olsam da günün birinde fotoğraf yükleme miktarı bugünkünün 10 katına çıkarsa fotoğraf işleme işlemini PHP yerine C’ye yaptırmakta hiç çekinmem.

Bu yazıyı yazmaya aslında Loud Thinking‘deki bir yazı sayesinde karar verdim. Rails, ilk gördüğüm günden beri kafamdaki karman çorman düşünceleri derleyip toparlaması nedeniyle hayran olduğum bir teknoloji ve bir felsefe. Rails’in yaratıcısı, ruby’nin performansı ile ilgili düşüncelerini yine her zamanki gibi %100 katıldığım bir şekilde özetlemiş aslında.

David yazısında, Yahoo’nun sayfalarını PHP ile sunarken arkaplanda C++’a dayalı bir sistem olduğundan, amazon’un C++ ve Java tabanlı altyapısının Perl ve Mason ile sunulduğundan bahsetmiş. Kendisi de basecamp’te imaj işlemlerini rails’in rmagick eklentisi yerine shell üzerinde yaptığını itiraf etmiş. Kendi deyimiyle bu hile yapmak, evet. Ama hile işe yarıyor demiş. Eğer fayda sağlıyorsa iyi birşeydir bence de…

Sonuçta amaç takım tutar gibi rails’i tutmak ya da zamanında yaptığımız gibi PHP ASP’yi döver demek değil. Amaç kaliteli bir ürünü, hızlı, sistematik, geliştirilebilir, genişletilebilir ve bakımı kolay bir şekilde ortaya çıkarmak…

Yazının sonuç cümlesi hoşuma gitti, paylaşmak isterim:

“… So please don’t let bottlenecks (real or imaginary, usually the latter) dictate your choice of software development environment. “

… Dolayısıyla lütfen bottleneck’lerin (gerçek ya da hayali, genellikle de hayali) yazılım geliştirme platformu seçiminizi etkilemesine izin vermeyin.