PHP 5.5 üzerinde hazır halde gelen opcache temel olarak, filesystem üzerinde bulunan php dosyalarını her requestte okumamak için tasarlanmış bir otomatik low level cache mekanizmasıdır. Php nin 5.5 sürümünü kullanıyorsanız, ve özellikle kapatmadıysanız, muhtemelen siz de bu özelliği kullanabilirsiniz / veya zaten bilmeden kullanıyorsunuzdur.

PHP interpreted bir dil olduğu için, (yazılan kodlar, çalışma anında makine diline çevrildiğinden) ilgili dosyalar normalde her çalıştırdığınızda veya sitenize her request geldiğinizde tekrar tekrar bu dosyaları load eder. Düşünün bir siteniz var ve anasayfasını ekrana basmak için 10 adet php dosyasına ihtiyacınız var. Sitenize de aynı anda(örneğin 1 saniye içinde) 100 kişi giriyor. Opcache olmadığında, bu 10 dosyayı her 100 giriş için toplamda diskten 1000 kere okuma işlemi yapması gerekiyor. Halbuki opcache üzerinde bir ayar ile bir dosyayı okuduğunda 10 saniye boyunca cachelemesini belirtebilirsinz. Bu demektir ki, 100 kişi x 10 saniye x 10 dosya = sisteminizin 10.000 kere okuma yapması gereken halde, sadece 10 kere diskten okuma işlemi yapacaksınız. Tabi, yapacağınız bir dosya değişikliğinin sitenize yansıması için bu sefer 10 saniye beklemek zorunda kalacağınızı da hatırlatmak isteriz.

Default değerleri görebileceğiniz tüm opcacahe konfigürasyon listesi için buyrunuz : http://php.net/manual/en/opcache.configuration.php

Opcache ile tam olarak ne kazandık? 

Tam olarak io kazandık, (diskten okuma yapma işlemlerimizi, sitemizin yoğunluğuna göre %100 e yaklaşan bir değere kadar azaltabiliriz.)

Dezavantajları neler?

Developer ortamında, insan bir şeyi denerken hemen dosyayı kaydedip yaptığı değişikliği anında  görmek isteyebilir. Hatta refleks olarak böyle davranır yazılımcılar. Bu durumda, local ortam için bir miktar handikap oluşturabilir, veya en güzeli, local ortam için opcache i disable etmek olabilir. (php.ini içinde opcache.enable=0 yazacaksınız) Aksi halde zırt pırt fpm restart etmek zorunda kalabilirsiniz.

Başka başka?

Opcache; büyük bir projede, aynı dosyalar ile çok fazla takıldıktan sonra, yazılımınızın yeni bir versiyonuna ait benzer sayıda çok dosya daha geldiğinde, ve artık bu dosyaları kullanmaya başladığında, sanırım eski dosyaları halen aklında tutmaya çalışmasından dolayı, yeni dosyalarınızı okurken io’su sanki opcache açık değilmişçesine artmaya ve overflow olmaya başlıyor. (bu da load vb konularında probleme sebebiyet verebiliyor. ). Çalışmamazlık durumu oluşmuyor ancak code ve dosya sayısı büyüklüğünüze göre sizi olumsuz etkiliyor. Bu noktada codebase üzerinde çok fazla değişme/yeni release yayına alma gibi aksiyonlarda php-fpm inizi restart etmenizde yarar var. (reload kurtarmıyor malesef)

“Biz bir major versiyon çıkarma kararını 2005 te aldık, bunu 2010 da çeşitli zorluklar sebebiyle durdurduk, şimdi insanların kafası PHP zaten 6 yok mu diye karışmasındansa PHP7 diyelim, aradaki 1 versiyona ne oldu diye gelen sorular, kafa karışıklığından daha önemli değil!”

Merak edenleri şuraya alıyoruz : https://wiki.php.net/rfc/php6#vote

Halen php 5.3 ile projelerde trait bile kullanamayan biri olaraktan, isyanım backward compatibility’ye.

PhpServerMonitor bu iş için biçilmiş kaftan bir yazılım.

www.phpservermonitor.org adlı siteden görebileceğiniz ve indirip kurabileceğiniz bu sistem ile artık sitelerinizi, hizmetlerinizi (mail, veritabanı vb..) otomatik olarak takip edip, herhangi bir hata durumunda ise kendinize sms, mail şeklinde uyarı gelmesini ayarlayabiliyorsunuz.

Kurulumu çok basit. Dosyaları indirip, ftp’nizden veya herhangi bir vasıta ile sunucunuza yükleyin. Bir tane de veritabanı ve veritabanı kullanıcısı açın. Bu iş için kendinize bir site kuruyormuş gibi hayal edin. İlk kurulum için tıpkı wordpress kurulumundaki gibi size bir arayüz üzerinden kurulum da yaptırabiliyor.

Daha sonra kendi yönetim paneli üzerinden takip – monitör etmek istediğiniz siteleri , hizmetleri buraya ekleyip buradan takibini yapabiliyorsunuz. Ayrıca bazı siteleri için spesifik kullanıcılara da tanım yaptırabiliyorsunuz. (yani çoklu kullanıcı desteğide mevcut)

Otomatik takip mekanizmasının en önemli kısmı ise, ilgili takibi yapan kod parçasını cronjobunuza koymaktan geçiyor. örneğin 10 dakikada bir kontrol etmesini isteyebilirsiniz. Veya her dakika bile istiyor olabilirsiniz. Bu tamamen size kalmış.
Dikkat edilmesi gereken konu, bu istekleri Curl ile yapıyor olması. Bu bağlamda sunucunuzun curl modülünün aktif olması gerekiyor. (ayrıca bu yazılım php 5.3.8 veya daha yeni bir sürüm gereksinimi duyuyor).

İlgili kurulumları yaptıktan sonra önümüzde sürekli açık olup takip etmek istediğimiz hizmetlerin, sitelerin durumlarını kırmızı , yeşil olarak gösteren güzel ve basit bir paneli de mevcut.

Aşağıdaki resim de bunun bir örneğidir.

php server monitor status table

Burada kısaca bu sistemi tanıtma amaçlı bir yazı yazdım. Kurulumu için destek isteyen olursa yardımcı olabilirim.

İnternetteki dökümanlar genelde konu güncel iken yazıldığı için, siz bir yazılım dilinin daha önceki versiyonlarına ait kurulumlar yapmak istediğinizde, varsayılan paket yöneticisi tarafından hep en son sürümü kurulmakta, ve bu da bizim o anki ihtiyaçlarımızı karşılamamaktadır.

Ben de birkaç tane projedeki php 5.3 gereksinimim sebebiyle böyle bir şey yapmak durumunda kaldım. (aslında vagrant daha güzel bir çözüm tabi ki dileyen araştırabilir.)

Öncelikle Mac’inizde homebrew (http://brew.sh/) yüklü değilse, bunu yüklememiz gerekiyor. Bunun için konsolunuzda

ruby -e "$(curl -fsSL https://raw.github.com/Homebrew/homebrew/go/install)"

komutunu çalıştırmanız gerekiyor.

Nginx kurulumu

brew install nginx

Bu kadar basit
Nginxi başlatmak için

nginx

komutunu yazmanız yeterli. (Evet konsola sadece nginx yazacağız, ubuntu gibi değil) Ancak sudo olarak çalıştırmanız gerekebilir.
Php kurulumu

php yi Nginx ile iletişim kurabilmesi için 2 şekilde kurabiliriz. 1. yöntem cgi ile. 2. yöntem ise, php-fpm ile. php-fpm ile kurmak daha mantıklı, çünkü fcgi process manager ile yönetilmeyen bir cgi kullanımı aynı anda çok fazla processi handle etmenizi yani stress test vb toolları çalıştırdığınız kısımlarda size problem çıkartabilir. Ben de bu ve birkaç sebepten dolayı php-fpm ile kurmayı anlatacağım. Ancak cgi ile kurmak isteyen için de sadece 1 parametre değişiyor

brew install php53 --with-mysql --with-suhosin --with-intl --with-imap --with-fpm

sondaki —with-fpm kısmı yerine –with-cgi yazarsanız da cgi ile kurmuş olursunuz.

Mac OS X içerisinde PHP, Ruby, Python gibi dillerin CLI (konsol üzerinden çalıştırılabilir) versiyonları ile birlikte geldiği için şu anda halen konsolda php -v yazdığınızda php 5.4.24 veya benzeri başka bir versiyonu görürsünüz. Ancak web arayüzünden (Yani browserdan nginx ile) girdiğinizde ilgili php 5.3 sürümünü çalıştırmış olacağız.

Eğer siz konsoldan da php 5.3 çalıştırmak istiyorsanız,

export PATH=/usr/local/Cellar/php53/5.3.28/bin:$PATH

şeklinde komut çalıştırmanız gerekiyor. (sudo ile çalıştırmanız icap edebilir).
Ancak bu şekilde yaparsanız da bilgisayarınızı yeniden açtığınızda (ya da konsoldaki oturumu kapattığınızda) bu ayar kaybolacaktır. Bunu kaybetmemek için bu komutu /usr/local/Cellar/php53/5.3.28/bin i sudo ile /etc/paths e yazmalısın.

Mac OS X üzerinde php-fpm ubuntudaki gibi /etc/init.d/php-fpm start stop, vb.. şeklinde kullanılamıyor. Bu yüzden kullanımı biraz farklı.
Php-fpm yi hemen başlatmak için

launchctl load ~/Library/LaunchAgents/homebrew.mxcl.php53.plist

Bilgisayarınız her açıldığında otomatik başlasın istiyorsanız da

ln -sfv /usr/local/opt/php53/*.plist ~/Library/LaunchAgents

şeklinde işlem yapmanız gerekiyor.

Şimdi sıra php-fpm.conf dosyasını bulup, buradaki ayarlardaki loglara veya dosyalara izin vermek kısmında.
php-fpm.confu bulup ilgili pid ve log dosyasını ve access log dosyasını yazabilmesi için yetki vb verip o gerekli klasörleri oluşturursan gerisi tamamdır. (Yine ubuntunun aksine, /var/run/php-fpm.pid yerine phpnin kendi klasörüne yapmanız daha mantıklı olacak ben bu şekilde yaptım. Log için de aynı yeri belirttim.)

percona-server kurulumu

Nginx kadar basit aslında.

brew install percona-server

Percona server’i hemen başlatmak için

launchctl load ~/Library/LaunchAgents/homebrew.mxcl.percona-server.plist

Bilgisayar her başladığında başlatmak için ise,

ln -sfv /usr/local/opt/percona-server/*.plist ~/Library/LaunchAgents

komutlarını çalıştırmanız gerekiyor.

Bu yazı nginx ayarları, php ayarları ve mysql ayarlarının nasıl yapıldığı ile ilgili olmadığı için o detayları burada paylaşmıyorum. Ancak ihtiyacı olan tabi ki danışabilir.

Umarım yararlı olur.

Hata ilk oluştuğunda wordpressimi bir süredir güncellemediğimi farkettim. Güncellemek için ilgili menüye geldiğimde bana bu hatayı verdi. Oldukça fazla vaktimi aldı aslında çözmek. Çünkü apacheyi yeniden başlatmak aklıma gelen ilk çözümdü ve bu çözmemişti durumu. (Ayrıca Jetpack, akismet gibi çok işe yarar eklentilerim de kullanılamaz olarak dating age limits duruyordu. Fırsat bulmuşken inceleyip hatayı gidermek istedim. )

Akabinde bir çok debugdan sonra, apacheyi restart etmek yerine önce stop sonra start yapmayı akıl edebildim. Nitekim problem çözüldü. Php’nin dns resolve işlemleri bir şekilde işletim sistemi ile haberleşemiyordu, ve eski php sürümlerinde bu tarz şeyler sıkça olabiliyordu

Hata gerçekten dns resolve işlemini (sunucunuzun dns ayarları) ile ilgili olabiliyor. Ben de ağırlıklı olarak buraya yoğunlaştım. Ancak benim problemimimin çmzümü apacheyi stop ve sonrasında start etmek idi.

Yaşayan vardır diyerekten uzun süren mecburi sessizliğimi bu yazıyla bozuyorum.

mysql_Real_Escape artık projenizde düzgün çalışmayacaktır diye tahmin ediyorum. Çünkü artık classlar üzerinden çalışıyorsunuz, ve buradaki mysql doğru connectionı bulamayabilir. (özellikle master slave ilişkili çift veya daha fazla db mimarisinde)

Tabi ki işin doğrusu statement->prepare metodu üzerinden bindParam veya bindValue ile ilerlemek. Ancak bunları için oldukça uzun bir vakit gerekebilir.

Biz de mysql_real_escape_string’in karşılığı olarak bir metod bulduk. Connection nesnesi üzerinde bulunan quote metodu.

$conn->quote(”) dediğimiz metod tam da istediğimiz şekilde çalışıyor. Hatta connection objesindeki ekstra parametreler kısmına ATTR_EMULATE_PREPARES=> true verirseniz, bu metod bildiğiniz mysql_Real_escape işlemini yapıyor. bu parametredeki tek handikap, çoklu querylerin tek seferde çalıştırılamaz hale gelmesi oluyor.

quote’un mysql_Real escape’ten tek farkı başına ve sonuna bir tırnak koyuyor. siz bunları substr ile çıkartırsanız birebir aynı olacaktır.

dikkat etmeniz gereken bir şey de şu ki, mysql server’ınızın encoding’i ile (server encodinginizin mysql e bağlanıp show variables like ‘%char%’ seklindeki degisklenlerden gorebilirsiniz) connection (DBAL ayarlarından verilen encoding) aynı olması gerkeiyor ki güvenli bir escape işlemi yapılabilsin.

GitHub Pages, projelerinize vs. websitesi oluşturabildiğiniz GitHub reponuzda host edilen, dolayısıyla terminalden git ile kontrol edebileceğiniz bir yapıdır.

Peki Jekyll’nin GitHub ile olayı nedir? Oluşturduğunuz bir GitHub Page içerisine, Jekyll push ettiğiniz takdirde, bir adet blogunuz olmakta. İşin özeti tamamen bu aslında.

Hızlıca bu işlemleri yapmak istiyorsanız, şu linke tıklamanız yeterli. Adım adım ne yapacağınız yazıyor, ancak ben kısaca bahsedeyim.

İlk olarak github içerisinde {{username}}.github.com isminde bir repo oluşturuyorsunuz. Ardından bilgisayarınızda Jekyll’i clonelayıp, remote set-url ile oluşturduğunuz repoya gönderiyorsunuz. Ve {{username}}.github.io adresiniz yaklaşık bir 10 dakika içerisinde açılmış oluyor.

Linkini verdiğim sitede layoutları bootstrap ile yapılmış bir Jekyll var. Eğer isterseniz tabi ki kendiniz de temasını şeklini felan düzenleyebilirsiniz. Ayrıca eğer isterseniz mevcut bir Jekyll’den clonelayıp kendiniz bir tane oluşturabilirsiniz. Burada bir liste var örneğin : https://github.com/jekyll/jekyll/wiki/Sites

Postların tamamı, _posts klasörünün altında bulunuyor. Eğer terminalden rake post title=”deneme” derseniz, _posts klasörünün altında, current-date-deneme.md isminde bir dosya oluşuyor. Bu dosyayı herhangi bir editör ile düzenlediğinizde bir adet post yazmış oluyorsunuz. Ancak bu şekilde yapmak zorunda değilsiniz, _posts altında herhangi bir dosya oluşturup onu {{username}}.github.io/{{dosya_adi}} şeklinde veya bir klasör oluşturup ardından onun altında dosya oluşturup {{username}}.github.io/{{klasör}}/{{dosya_adi}} şeklinde çalıştırabilirsiniz.

Jekyll’i localde çalıştırabilmek için bilgisayarınızda ayrıca ruby kurulu olması gerekiyor. Onu da buradaki yazımda anlatmıştım, belki yardımcı olabilir.

Ayrıca localde çalışırken başıma gelen bir olay; _config.yml dosyası jekyll serve dediğinizde load oluyor. Üzerinde değişiklik yaptığınızda tekrar jekyll serve  demeniz gerekiyor.

Localde çalışırken başıma gelen bir başka hata ise şu şekildeydi : runner.rb:365:in `require_program’: program version required (Commander::Runner::CommandError)

Çözümü ise : sudo gem install json

Jekyll’nin asıl amacı, yazılımcıların kod yazar gibi blog içeriği oluşturmalarıymış. Ufak bir araştırma yaptığımda kullanan sayısının bir hayli çok olduğunu da gördüm.

İnternet üzerinde bir çok yerde ve yazılımla ilgili muhabbetlerin bir çoğunda son dönemin en iyi frameworklerinden biri olarak nitelendiriliyor. Örnek olarak şuraya göz atabilirsiniz : http://www.sitepoint.com/best-php-frameworks-2014/

Bende araştırırken karşıma çıkan faydalı ve güzel linkleri bir araya getirdim. Aşağıdan ulaşabilirsiniz;

Laravel Documentation http://laravel.com/docs/introduction [ olmazsa olmaz ]

Laracast https://laracasts.com/series [ özellikle Laravel From Scratch kısmında, Laravel’in temel prensipleri güzel anlatılmış ]

Visualizing Laravel Relationships http://matthewhailwood.co.nz/visualizing-laravel-relationships/

Laravel Blog örneği https://github.com/ibrahimhizlioglu/laravel-blog-ornegi

Events & Queue örneği https://github.com/Ardakilic/laravel-4-workshop-sunum

Laravel Request Lifecycle http://laravel-recipes.com/recipes/52

Laravel Tricks http://www.laravel-tricks.com/

CMS https://github.com/sseffa/sfcms

Laravel E-Commerce https://medium.com/laravel-4/c5afca925f28 [ Laravel ile e-ticaret sistemi ]

Faydalı olan başka linkleri de iletirseniz yazıya ekleyebilirim

RVM olmadan kurulum

İlk olarak terminali açıyoruz. Ardından ruby 1.9.3 versiyonunu kuruyoruz.

sudo apt-get update
sudo apt-get install ruby1.9.3

Kurduktan sonra

ruby --version

diyerek kurulduğunu görmüş oluruz.

RVM ile kurulum

Eğer sisteminizde curl kurulu değilse ilk olarak curl kurunuz.

sudo apt-get install curl

Ardından şu işlemleri yapınız.

curl -L get.rvm.io | bash -s stable
source /usr/local/rvm/scripts/rvm

RVM için gerekli paketlerin kurulu olup olmadığına bakıyoruz, eğer gerekli paketler varsa kuruyoruz. Şu şekilde ;

rvm requirements

Son bir işlemimiz kalıyor;

rvm install 1.9.3

Öncelikle phpmyadmin’in config.inc.php dosyasını bulunuz. (linux’ta /etc/phpmyadmin/ klasörünün altında olması gerekiyor.) Buraya $cfg[‘LoginCookieValidity’] parametresini ekleyeceğiz. Ben 1 yıl timeout süresi verdim şu şekilde;

$cfg[‘LoginCookieValidity’] = 31536000; /*365 * 24 * 60 * 60*/

NOT : BUNU SADECE LOCAL ORTAMDA ÇALIŞIRKEN UYGULAYINIZ!!!