PHP Sürüm Yükseltmenin Hıza Etkisi

Sitenizi hızlandırmak için yapabileceğiniz en ucuz iş, muhtemelen henüz yapmadığınız iş: PHP sürümünü yükseltmek. Tek bir eklenti kurmadan, tek satır kod yazmadan, çoğu durumda hosting panelindeki bir açılır listeden seçim yaparak aynı sunucuda ölçülebilir bir hız kazancı elde edersiniz. Buna rağmen sahada gördüğüm sitelerin ciddi bir bölümü hâlâ yıllar önce ömrünü tamamlamış bir PHP sürümüyle çalışıyor; sebep genelde "dokunmayalım, çalışıyor" korkusu oluyor.

Bu korku tamamen haksız değil — hazırlıksız bir sürüm atlaması gerçekten site kırabilir. Ama doğru sırayla yapıldığında yükseltme, geri dönüşü birkaç dakika süren, riski ölçülebilir bir işlemdir. Bu rehberde PHP sürümleri arasındaki hız farkının nereden geldiğini, hangi sürüm atlamalarında ne kazandığınızı, uyumluluğu yükseltmeden önce nasıl kontrol edeceğinizi ve geçişi kesintisiz yapmanın adımlarını anlatacağım. Ayrıca yükseltmenin ardından mutlaka doğrulamanız gereken OPcache ayarlarına ve sık karşılaşılan uyumsuzluk hatalarına da değineceğim.

Hız Farkı Tam Olarak Nereden Geliyor#

PHP 7.0'da PHP çekirdeği baştan yazıldı; değişkenlerin bellekte tutulma biçimi (zval yapısı) küçültüldü, hash tablosu yeniden tasarlandı ve bellek erişimi çok daha az işaretçi takibi gerektirir hâle geldi. Bu tek başına PHP 5 dünyasına göre iki katına yaklaşan bir sıçrama üretti. PHP 8 serisinde ise kazanç farklı bir yerden geldi: sanal makinenin komut seti optimize edildi, sık kullanılan fonksiyonlar için özel hızlı yollar eklendi, kalıtım ve özellik erişimi ucuzladı, ve bazı dâhili yapılar önbellek dostu hâle getirildi.

Bunun pratikteki anlamı şudur: aynı kod, aynı donanımda, daha az CPU çevrimiyle çalışır. Kazanç sadece "sayfa daha hızlı açılır" değildir; aynı sunucu daha fazla eşzamanlı isteği kaldırır. Bir PHP süreci isteği %30 daha kısa sürede bitiriyorsa, aynı pm.max_children değeriyle birim zamanda daha fazla istek işlersiniz. Yani yükseltme hem gecikmeyi düşürür hem kapasiteyi artırır.

Kazancın büyüklüğü uygulamanızın neyle zaman geçirdiğine bağlıdır. Bunu ölçmek için basit bir ayrım yapın:

# Sunucudan, PHP'nin işi ne kadar sürüyor (TTFB yaklaşık ölçümü)
curl -o /dev/null -s -w 'baglanti: %{time_connect}s\nilk_bayt: %{time_starttransfer}s\ntoplam: %{time_total}s\n' \
  https://firmaniz.com/

# Aynı sayfa, PHP tarafındaki gerçek çalışma süresi için uygulama profilleyicisi
# ya da PHP-FPM slowlog kullanın

ilk_bayt değerinin büyük kısmı PHP'de geçiyorsa (yani sunucu tarafı üretimde), sürüm yükseltmesi doğrudan işinize yarar. Ama süre veritabanı sorgularında ya da harici bir API çağrısında geçiyorsa PHP sürümü çok az fark yaratır; o zaman önce veritabanı sorguları sayfa hızını nasıl etkiler yazısındaki yönteme bakmalısınız. Ölçmeden yükseltmek zarar vermez, ama beklentiyi doğru kurmak gerekir.

Hangi Sürüm Atlaması Ne Kazandırır#

Aşağıdaki tablo, tipik bir CMS iş yükünde (WordPress benzeri, veritabanı ağırlıklı ama önbelleksiz) sahada gözlemlenen genel eğilimi özetler. Kesin rakamlar uygulamaya göre değişir; tablo büyüklük mertebesi vermek içindir.

Buradan çıkan pratik sonuç şudur: hâlâ PHP 5.x veya 7.0-7.2 kullanıyorsanız, elinizdeki en büyük tek hız kazancı budur ve hiçbir kod optimizasyonu bununla yarışmaz. Zaten 8.x serisindeyseniz, bir sonraki küçük sürüme geçmek hız açısından mütevazı bir kazançtır; asıl sebebiniz güvenlik güncellemesi almaya devam etmek olmalıdır.

Güvenlik boyutunu hafife almayın. Ömrünü tamamlamış bir PHP sürümü artık güvenlik yaması almaz; sunucunuzda bilinen ve düzeltilmeyecek açıklar taşıyorsunuz demektir. Hız kazancı olmasa bile desteklenen bir sürümde kalmak tek başına yeterli gerekçedir. Sunucunuzda hangi sürümün çalıştığını ve desteklenen sürümleri şöyle görürsünüz:

# Aktif CLI sürümü
php -v
# PHP 8.3.11 (cli) (built: Aug  8 2026 09:14:32) (NTS)

# Sunucuda kurulu tüm sürümler (Debian/Ubuntu)
ls -1 /etc/php/
# 7.4
# 8.1
# 8.3

# Web tarafında hangi sürümün çalıştığı (CLI'den farklı olabilir!)
php -r 'echo PHP_VERSION;'   # CLI
curl -sI https://firmaniz.com/ | grep -i x-powered-by

CLI ile web sürümünün farklı olması çok sık rastlanan bir durumdur ve teşhiste yanıltır: terminalde php -v size 8.3 derken siteniz 7.4 üzerinde çalışıyor olabilir. Web tarafındaki gerçek sürümü öğrenmenin en kesin yolu geçici bir dosyada phpversion() çağırmak ya da PHP-FPM havuzunun hangi sürüme ait olduğuna bakmaktır.

Yükseltmeden Önce Uyumluluk Kontrolü#

Bu bölüm, "site kırılır mı" korkusunun cevabıdır. Yükseltmeyi denemeden önce kodun yeni sürümle uyumlu olup olmadığını statik olarak kontrol edebilirsiniz. En yaygın araç PHP_CodeSniffer üzerine kurulu uyumluluk kural setidir:

# Composer ile kur (geliştirme makinenizde ya da hazırlık sunucusunda)
composer require --dev squizlabs/php_codesniffer phpcompatibility/php-compatibility

# Kural setinin yolunu tanıt
vendor/bin/phpcs --config-set installed_paths vendor/phpcompatibility/php-compatibility

# Kodu PHP 8.3 hedefiyle tara
vendor/bin/phpcs -p . --standard=PHPCompatibility --runtime-set testVersion 8.3 \
  --extensions=php --ignore=vendor/,node_modules/

Çıktı size hangi dosyanın hangi satırında kaldırılmış bir özellik kullandığını söyler. Tipik bulgular şunlardır:

Hazır bir CMS kullanıyorsanız asıl risk çekirdekte değil, üçüncü parti eklentilerde ve temada olur. Çekirdek uzun süredir yeni sürümleri destekliyordur; ama üç yıldır güncellenmemiş bir eklenti PHP 8'de ölümcül hata verebilir. Bu yüzden yükseltmeden önce tüm eklenti ve temaları güncelleyin, güncellemesi olmayan ve terk edilmiş görünenleri listeleyin. Terk edilmiş bir eklenti, yükseltmeyi engelleyen asıl sebep hâline gelirse doğru karar sürümü ertelemek değil, o eklentiyi değiştirmektir.

Geçişi Kesintisiz Yapmanın Adımları#

Yükseltmeyi doğrudan canlıda denemeyin. İzlemeniz gereken sıra şudur:

1. Tam yedek alın. Dosyalar ve veritabanı; geri dönüşün mümkün olduğundan emin olun. Yedekleme alışkanlığınız yoksa yedekleme tarafını yükseltmeden önce çözün.
2. Bir hazırlık (staging) kopyası oluşturun. Aynı sunucuda alt alan adı olarak ya da ayrı bir sunucuda; canlının aynısı olsun.
3. Kopyada sürümü yükseltin ve uyumluluk taramasındaki bulguları düzeltin.
4. Kritik akışları elle test edin: giriş, form gönderimi, ödeme, arama, yönetim paneli, e-posta gönderimi.
5. Hata günlüğünü açık tutarak gezinin. display_errors kapalı, log_errors açık olsun; sessiz hataları yakalayacak olan budur.
6. Canlıda düşük trafikli bir saatte geçin ve ilk yarım saat günlükleri izleyin.
7. Geri dönüş planını hazır tutun: eski sürüm kurulu kalsın, tek satırla geri alabilin.

Sunucu tarafında Nginx + PHP-FPM kullanıyorsanız geçiş, sanal sunucu bloğundaki soket yolunu değiştirmekten ibarettir:

location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    # Eski: unix:/run/php/php7.4-fpm.sock
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}

# Yeni sürümün servisini başlat ve açılışta gelmesini sağla
systemctl enable --now php8.3-fpm

# Nginx yapılandırmasını doğrula ve yeniden yükle
nginx -t && systemctl reload nginx

# Doğrula: hangi süreç isteği karşılıyor
curl -s https://firmaniz.com/surum-testi.php

Eski sürümün servisini hemen kaldırmayın; birkaç gün kurulu kalsın. Bir sorun çıkarsa fastcgi_pass satırını geri alıp nginx -t && systemctl reload nginx çalıştırmak saniyeler sürer. Bu, geçişin risk profilini tamamen değiştiren küçük bir alışkanlıktır.

cPanel kullanıyorsanız iş daha da basittir: MultiPHP Manager ekranından alan adını seçip istediğiniz sürümü uygularsınız. Aynı panelde MultiPHP INI Editor ile memory_limit, upload_max_filesize gibi değerleri sürüm bazında ayarlayabilirsiniz. Değişiklik anında etkili olur ve aynı ekrandan geri alınabilir.

Yükseltmeden Sonra Mutlaka Doğrulanacaklar#

Sürümü değiştirdiğinizde bazı ayarlar sıfırlanır ya da yeni sürümün varsayılanlarıyla gelir; bunları kontrol etmezseniz "yükselttim ama hızlanmadı" sonucuna varırsınız. En kritik olanı OPcache'tir: PHP kodunuzun derlenmiş hâlini bellekte tutar ve her istekte yeniden derlenmesini engeller. Kapalıysa, yeni sürümün kazancının büyük bölümünü göremezsiniz.

; /etc/php/8.3/fpm/conf.d/10-opcache.ini
opcache.enable=1
opcache.enable_cli=0
opcache.memory_consumption=256        ; MB — büyük projelerde artırın
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000   ; dosya sayınızdan büyük olsun
opcache.validate_timestamps=1         ; canlıda 0 yapabilirsiniz (deploy'da flush şart)
opcache.revalidate_freq=2
opcache.save_comments=1               ; anotasyon kullanan çatılarda 1 KALMALI

Ayarların gerçekten uygulandığını doğrulayın:

# OPcache açık mı ve doluluk oranı ne
php -i | grep -E 'opcache.enable|opcache.memory_consumption'

# Web tarafındaki gerçek durum için PHP-FPM üzerinden bakın
php-fpm8.3 -tt 2>&1 | head

opcache.max_accelerated_files değeri projenizdeki PHP dosya sayısından küçükse önbellek dolar ve dosyalar sürekli düşüp yeniden derlenir; bu, hızlandırma yerine yavaşlama üretir. Dosya sayınızı find . -name '*.php' | wc -l ile ölçüp değeri onun üzerine ayarlayın. opcache.save_comments=0 ayarı ise bellek kazandırır ama anotasyon okuyan çatılarda (doctrine benzeri) uygulamayı kırar; emin değilseniz 1 bırakın.

İkinci kontrol noktası bellek ve süre limitleridir. Yeni sürümün php.ini dosyası taşınmaz; eski memory_limit, upload_max_filesize, post_max_size ve max_execution_time değerlerinizi yeni sürüme taşımayı unutursanız, dosya yükleme ya da içe aktarma işlemleri sessizce başarısız olur. Üçüncü kontrol uzantılardır: imagick, intl, redis, soap gibi uzantılar sürüm bazında kurulur; eski sürümde vardı diye yenisinde otomatik gelmez.

# Yeni sürümde yüklü uzantıları listele ve eskisiyle karşılaştır
php8.3 -m > /tmp/ext-83.txt
php7.4 -m > /tmp/ext-74.txt
diff /tmp/ext-74.txt /tmp/ext-83.txt

Havuz ayarlarını da gözden geçirin: yeni sürümde istekler daha hızlı bittiği için aynı pm.max_children değeriyle daha fazla kapasiteniz olur, ama süreç başına bellek kullanımı da değişmiş olabilir. Ölçüm ve hesap yöntemini PHP-FPM havuz ayarları yazısında bulabilirsiniz.

Sık Yapılan Hatalar#

Birincisi, ölçmeden yükseltip ölçmeden sonuç çıkarmak. Yükseltmeden önce birkaç anahtar sayfanın ilk bayt süresini kaydedin; sonra aynı ölçümü tekrarlayın. Kayıt yoksa "sanki hızlandı" dışında bir şey söyleyemezsiniz ve bir sorun çıktığında sürümün mü yoksa aynı gün yapılan başka bir değişikliğin mi sebep olduğunu ayıramazsınız.

İkincisi, hataları görünmez bırakmak. Yükseltmeden sonra display_errors kapalı olmalıdır (ziyaretçi hata mesajı görmemeli) ama log_errors mutlaka açık olmalı ve günlük dosyası izlenmelidir. PHP 8, önceden uyarı olan bazı durumları ölümcül hataya çevirdi; bunlar günlükte görünür ama sayfa boş döndüğü için fark edilmeyebilir.

display_errors = Off
log_errors = On
error_log = /var/log/php/php8.3-error.log
error_reporting = E_ALL & ~E_DEPRECATED

Üçüncüsü, CLI ile web sürümünü karıştırmak. Cron görevleriniz php komutunu çağırıyorsa ve varsayılan CLI sürümü hâlâ eskiyse, siteniz 8.3'te çalışırken zamanlanmış görevleriniz 7.4'te çalışmaya devam eder. Cron satırlarında sürümü açıkça yazın: /usr/bin/php8.3 /var/www/firmaniz.com/cron.php.

Dördüncüsü, tüm siteleri aynı anda geçirmek. Bir sunucuda on site varsa hepsini tek seferde yükseltmek, bir sorun çıktığında hangisinin etkilendiğini bulmayı zorlaştırır. Havuz bazında geçiş yapın; her sitenin kendi PHP-FPM havuzu varsa sırayla ve kontrollü ilerleyebilirsiniz.

Beşincisi, önbelleği temizlememek. Sürüm değişince OPcache içeriği geçersizdir; ayrıca uygulama düzeyinde bir tam sayfa önbelleğiniz varsa eski çıktıları sunmaya devam edebilir. Geçiş sonrası PHP-FPM'i yeniden yükleyin ve varsa uygulama önbelleğini boşaltın. Katmanların hangisini nasıl temizleyeceğinizi sunucu tarafı önbellekleme katmanları yazısında adım adım bulabilirsiniz.

Sıkça Sorulan Sorular#

PHP sürümünü yükseltmek sitemi ne kadar hızlandırır#

Bu, kaçtan kaça çıktığınıza ve uygulamanızın nerede zaman harcadığına bağlıdır. PHP 5.6'dan 7.4 ya da 8.x'e geçiyorsanız istek süresinin kabaca yarıya inmesi beklenir; 8.1'den 8.3'e geçişte kazanç çok daha mütevazıdır. Süreniz veritabanı sorgularında ya da harici API çağrılarında geçiyorsa PHP sürümü sonucu az değiştirir; o durumda önce sorguları ve önbelleği ele almalısınız.

PHP sürümünü yükseltince sitem bozulur mu#

Hazırlıksız yapılırsa bozulabilir, çünkü yeni sürümler eski fonksiyonları kaldırır ve bazı uyarıları ölümcül hataya çevirir. Riski neredeyse sıfıra indirmenin yolu şudur: önce hazırlık kopyasında deneyin, PHPCompatibility ile statik tarama yapın, tüm eklenti ve temaları güncelleyin, ve eski sürümü kurulu bırakarak geri dönüş yolunu açık tutun.

cPanel'de PHP sürümünü nasıl değiştiririm#

cPanel'e girip Software başlığı altındaki MultiPHP Manager ekranını açın, alan adınızın yanındaki kutuyu işaretleyin, sağ üstteki listeden hedef PHP sürümünü seçip Apply deyin. Değişiklik anında uygulanır. Bellek ve yükleme limitlerini aynı panelin MultiPHP INI Editor bölümünden sürüm bazında ayarlayabilirsiniz.

Hangi PHP sürümünü kullanmalıyım#

Kural olarak, uygulamanızın desteklediği en yeni kararlı sürümü kullanın. Yeni çıkan bir ana sürümde birkaç ay beklemek makuldür; ekosistemdeki kütüphane ve eklentilerin uyum sağlaması zaman alır. Asla ömrünü tamamlamış, güvenlik yaması almayan bir sürümde kalmayın — hız kazancı olmasa bile bu tek başına yükseltme sebebidir.

Yükselttim ama hızlanmadı, neden#

En sık sebep OPcache'in kapalı ya da yanlış boyutlandırılmış olmasıdır; yeni sürümde ayar dosyanız taşınmadıysa varsayılanlarla çalışıyor olabilirsiniz. İkinci sebep, darboğazın PHP'de değil veritabanında ya da ağda olmasıdır. Üçüncü sebep, web tarafının hâlâ eski sürümü kullanmasıdır; CLI'de php -v yeni sürümü gösterirken PHP-FPM havuzu eski sürüme bağlı kalmış olabilir.

Eski PHP sürümünü sunucudan silmeli miyim#

Geçişten hemen sonra silmeyin. Eski sürümün kurulu kalması, bir sorun çıktığında fastcgi_pass satırını geri alarak saniyeler içinde eski duruma dönmenizi sağlar. Yeni sürümle birkaç hafta sorunsuz çalıştıktan, cron görevlerinin ve arka plan işlerinin de yeni sürüme geçtiğini doğruladıktan sonra eski paketleri kaldırabilirsiniz.

Cron görevlerim de otomatik yeni sürüme geçer mi#

Hayır, geçmez. Cron satırlarınızda php yazıyorsa sistemin varsayılan CLI sürümü çalışır ve bu, web tarafındaki sürümden farklı olabilir. Yükseltmeden sonra crontab -l çıktısını gözden geçirin ve komutlarda sürümü açıkça belirtin: /usr/bin/php8.3 /var/www/firmaniz.com/cron.php gibi. Aksi hâlde site yeni sürümde, zamanlanmış görevler eskisinde çalışmaya devam eder.

Kapanış#

PHP sürüm yükseltmesi, hız/çaba oranı bakımından yapabileceğiniz en verimli optimizasyondur; ama getirisi kadar hazırlığı da gerçektir. Aklınızda kalması gereken dört alışkanlık şudur: yükseltmeden önce ve sonra aynı sayfanın ilk bayt süresini ölçmek, canlıya dokunmadan önce hazırlık kopyasında statik uyumluluk taraması yapmak, eski sürümü kurulu bırakarak geri dönüşü tek satıra indirmek ve geçişten sonra OPcache ile limit ayarlarının gerçekten taşındığını doğrulamak. Bunlar yapıldığında yükseltme, korkulan bir operasyon olmaktan çıkıp rutin bir bakım işine dönüşür.

Bu adımlarla uğraşmadan güncel bir PHP altyapısında çalışmak isterseniz Clou.TR paketleri güncel sürümleri hazır ve ayarlanmış biçimde sunar. Panel üzerinden tek tıkla sürüm seçebileceğiniz web hosting ve WordPress hosting paketlerimizi inceleyebilir, kendi PHP yığınınızı baştan kurmak isterseniz tam root erişimli VDS sunucularımızı tercih edebilirsiniz. Geçişi sizin yerinize yapmamızı isterseniz site taşıma ve sunucu yönetimi hizmetlerimiz yükseltme ve doğrulama adımlarını da kapsar.