Roni yazdıAristona yazdı
Şuan Laravel'in class loaderinin kaç tane dosyayı include ettiğinden haberin var mı?
Performansa bu kadar meraklıysanız, gidin salt PHP'de yazın uygulamanızı. Blade kullanmayacaksınız ama framework binlerce dosyayı include ediyor, onlar ne olacak? Onlar kastırmıyorda sunucuyu kastıran birkaç tane regex call mı?
Frameworklerin en büyük açmazlarıda bu zaten. Örneğin header için yerel bir fonksiyon olan
http_response_code(404); (PHP 5.4 ) kullanılması gerekirken onun yerine
Response::make($feed, 404, array('Content-Type' => 'text/html')); kullanılmasını mantıklı bulmuyorum. Yada
Response::make($feed, 200, array('Content-Type' => 'text/html')); gibi bir kullanım ve bunun için yazılmış bir Response sınıfı. Bu sadece bir örnek. Daha bunun gibi bir sürü gereksiz bulduğum sınıf bileşeni var. Diyeceksiniz ki o zaman kullanmayın, buda bir görüş tabi.
Yine
require() veya
include() direktiflerini en aza indirmek gerekirken, bir bakıyorsun onlarca
include() işlemi yapılıyor. Disk okuma işlemi sizcede önemli değilmi? Framework bir kaç ziyaretçinin girebileceği sistemler için geliştiriliyorsa, hiç geliştirilmesin daha iyi. Programcılar fantazi peşinde. Blade işlemi sadece regex ten ibaret değil,
Regex + PHP yorumu + include veya
require direktifi. Topladığınızda tabiki sisteme önemli bir yük getiriyor.
configuration işlemleri için bir dosya,
route için bir dosya,
filter için bir dosya,
settings için bir dosya vb gibi ayar dosyaları daha optimize olabilir. Örneğin tek dosyada bu işlemler yapılabilir. Sadece bu dosyalar tek başına en az 10 require direktifini oluşturuyor.
Eğer dediğiniz gibi başka alternatifler kullanılacaksa o zaman frameworklere neden ihtiyaç duyuluyor. Spageti kod yazmaktan kurtulmak için mi?, yoksa daha düzenli, daha güvenli ve aynı zamanda geliştirmeye açık uygulamalar yapmak için mi?, yada şimdilik bununla devam edeyim daha sonra başka alternatiflere yönelirim mi?. Programcılar bunların hepsi için frameworkleri tercih ediyor yada framework ihtiyacı bu yüzden ortaya çıkyor.
Öyleyse performans benim için önemli değil diyemeyiz. Framework geliştiricileri bunu göz önünde bulundurarak fantazi üretmenden en olabilirliği yapmalıdırlar.
Bunun cevabı aslında PHP'de mail() fonksiyonu varken neden SwiftMailer gibi sınıfları kullanıyoruz sorusunun cevabıyla aynı. PHP'nin mail() sınıfı son derece güvenilmezken SwiftMailer gereken hertürlü şeyi kendisi sağlıyor. (SMTP desteği vb.) http_response_code() PHP 5.4 ile gelmiş bir fonksiyon. Response componenti aynı işin daha iyisini (örn JSON response veya streamed response özelliklerini destekliyor) PHP 5.3 olarak sunuyor.
Ben önemli değil demedim. Tabiki önemli, ancak route ve configleri tek dosyada toplamanın performans açısından bir getirisi yok. Bunlar mikro optimizasyonlar. Çift tırnak yerine tek tırnak kullanmak, işlemleri tek if kontrolünde gerçekleştirmek, herşeyi aynı dosyaya yazmak. Buradan kazanacağın süre avantajı belkide 0,0001 milisaniye. Ancak büyük düşünüp bunu tamamen önleyecek bir sistem üzerine yoğunlaşırsan (opcode cache kullanmak gibi, yükü birkaç sunucuya paylaştırmak gibi) burada kazanacağın avantaj çok daha büyük olacaktır.
Blade size birçok konuda avantaj sağlıyor. Viewler arasında inheritence, veya sık kullanılan XSS protection methodların üzerine bir wrapper çekilmesi (örn <?php echo htmlspecialchars($a, ENT_QUOTES, 'UTF-8') ?> yazmak yerine {{{ $a }}} yazmanın yeterli olması.) büyük bir avantaj. Ayrıca bahsettiğin konuların bazıları yanlış. PHP yorumu sen salt PHP ile viewlerini oluşturduğunda da çalışacak. include ve require eğer sınıflar arasında layout/partial yapısı kuracaksan yine kullanacaksın. Kullandığın yapı birgün yetersiz gelecek (örneğin viewler arasında bağlantı olsun isteyeceksin, veya Laravel'deki View::composer mantığını geliştirmek isteyeceksin) ve yine Blade'ye yakın bir view sınıfı geliştirmiş olacaksın. Aynı şey Response sınıfı içinde geçerli. Headerleri değiştirmek isteyeceksin, veya json/xml çıktısı vermek isteyeceksin, veya streaming çıktısı vermek isteyeceksin, veya PHP 5.4'ün altındaki versiyonlarda da bu işlemin çalışmasını isteyeceksin. Sonuç olarak yine yazacağın sınıf aşağı yukarı Response komponentiyle eşdeğer olacak. (ve senin karşılaşacağın muhtemel buglar orada aylar öncesinden fixlenmiş + testleri yazılmış olacak)
Frameworklere ihtiyaç duyuluyor çünkü bir üstteki mesajımla direkt alakalı. Tecrübeli yazılımcılar Response sınıfını baştan yazıp tekerleği tekrar icat etmeye çalışmaktansa halihazırda yapılmış olanını kullanıyor. Framework dediğimiz olay zaten bu tür sınıfların birleşmesinden oluşan bir yapı. Composer gibi araçlar PHP dünyasındaki dağınıklığı ve herkesin tekerleği baştan icat etmeye çalışmasının önüne geçmek için atılmış adımlar.
Laravel'in performansını çok küçümsüyorsunuz gibi geliyor bana. Eğer Laravel size yavaş geliyorsa Slim veya Silex gibi mikroframeworkleri kullanın, veya Phalcon gibi C extensionu halinde çalışan frameworkleri kullanın, veya salt PHP kullanın, veya hiçbirşey kullanmayın direkt assemblyde yazın? Şuana kadar hantal bir framework ile yazılıp, 1.000.000 kullanıcıyı kaldıramadığı için batan bir proje duymadım. Laravel'in yetersiz geleceği noktada senin/veya şirketinin cebinde tomarla para olur. Cluster, cloud, varnish, cdn vsvs. ne duyduysanız denersiniz ve sorunu çözersiniz.
configleri, routeleri vb. birleştirmek bir kurala aykırı. Seperation of Concerns. Evet, belki oop ile bir ilgisi yok ancak birbirinden bağımsız olan şeyleri ne kadar ayrı tutarsan o kadar avantajlı. Misal uygulamana bir güncelleme geliştirdin ve routes.php'i müşterine verdin. Eğer veritabanı bilgileri bu dosyada tutuluyor olsa müşteri copy paste sonrası tekrar db bilgilerini girmek zorunda kalacak.
Ben böyle yazınca beni koskoca clusteri yöneten birisi falan sanmayın. Benimde sunucum DigitalOcean'ın 5 dolarlık uyduruk VPS'i ve 1 saat içerisinde kurduğum LAMP stacktan ibaret. 3 tane demo uygulama barınıyor ve şuana kadar kaldırmadığını görmedim. Kaldırmazsa neler yapabileceğimi kaldırmadığı zaman düşünürüm.
Şimdiden performans konusuna takılmak mahalle takımına 100.000 kişilik stadyumun temellerini atmakla eşdeğer. Senin maçını maksimum 500 kişi izleyecekse o zaman 500 kişilik bir stadyum yaparsın. Eğer birgün Fenerbahçe gibi bir takımla maç yapıp 10.000 kişinin izleyeceğini düşünüyorsan o zaman maçı büyük bir sahaya taşırsın ve maç bittiğinde tekrar kendi sahana dönersin. Scalability dediğimiz olay bu. Senin stadyumun duruma göre büyüyüp küçülebilen bir yapıda olabilir. Gece kimsenin girmeyeceği zamanlarda küçük kalabilirsin, gündüz peak saatlerde büyürsün. Aniden büyümen gerekirse resource takviyesi yaparsın.
murat yazdı@by_arda2 ben bir çırak olarak, ustaların çıraklarına attığı fırça olarak algıladım
gerekçeleriyle birlikte yazdıklarını okuyunca haklı adam. fırçayı atmış ama bir sürüde bilgi vermiş.:D "tamam abi" diycez,
by_arda2 yazdıYeni başlayan biri olarak aklıma takıldığı için sormuştum.Cevabın için teşekkürler
(döver gibi yazsan bile - veya ben öyle anladım)
Pardon, o mesajımı sinirli bir anımda yazmışım, biraz sert yazmış olabilirim. Usta olabilecek seviyede değilim. Zira bende Laravel'de yeni sayılırım.