opcache

Php 5.5 Opcache Nedir? (ve overflow problemi)

Opcache Nedir?

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)

PHPnin yeni major versiyonu PHP6 yerine PHP7 olacak

PHP’nin yeni versiyon numarası https://wiki.php.net/rfc/php6#vote adresinde görüleceği anketin ardından PHP7 olmasına karar verilmiş.
2 kilometre yazı yazarak anlattıkları şey aslında özetle şu :

“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 status table

Site ve Servis takip monitor etme sistemi – PhpServerMonitor

Web dünyasında sürekli online olmasını istediğimiz çeşitli servisler, siteler, hizmetler olduğu günümüzün en önemli gereksinimlerinden. Peki ya örneğin internet siteniz, sürekli çalışıyor mu, erişilebiliyor mu? Çalışmadığında veya erişilemediğinde nasıl haberiniz olacak?

 

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.

phpservermonitor status table

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.

Mac OS X Nginx PHP 5.3 ve percona-server (mysql) kurulumu

Bu yazıda Mac OS X üzerine Nginx ve PHP5.3 (özellikle php5.3, daha yenisi değil) kurmayı anlatmaya çalışacağım.

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

wordpress guncellemesinde temporary failure in name resolution hatasi

Bir süredir yeni yazı eklemiyor ve yorumları kontrol edemiyordum. Bunun sebebi php’nin cgi fonksiyonları üzerinde başlıkta belirttiim temporary failure in name resolution hatasını almamdan dolayı olduğunu keşfettim.

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.