Bu blog ağırlıklı olarak Ruby on Rails‘e değiniyor. Rails’in sonuca odaklı hızlı geliştirme yeteneği, yıllardır tercih ettiğim PHP’ye baskın çıkarken ruby’nin php’den yavaş çalıştığı bir gerçek olarak önümüzde yer alıyor. Peki tercih yaparken performansı ne kadar göz önünde tutmalıyız, biraz irdeleyelim…

Ç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.