OPcache Nedir? PHP Sitenizi Hızlandıran Önbellek ve Ayarları

OPcache nedir ve PHP'de ne işe yarar?

OPcache, PHP'nin derlediği betikleri ortak belleğe kaydeden yerleşik bir bytecode önbelleğidir. Böylece PHP her istekte aynı dosyaları baştan okuyup derlemek zorunda kalmaz. Sonuç olarak sunucu aynı işi tekrar yapmaz, CPU yükü azalır ve sayfalarınız genellikle daha kısa sürede yanıt verir.

Bu yazıda OPcache nedir sorusunu önce kısa bir mantıkla açıklıyoruz. Ardından php.ini ayarlarını, doğrulama adımlarını ve deploy sonrası sıfırlamayı resmi PHP dokümanına dayanarak anlatıyoruz. Biz bir hosting firması değiliz, dijital pazarlama ve web ekibiyiz. Bu yüzden anlatımımız deneyim iddiasına değil, resmi dokümana dayanır.

Okurumuzu iki grup olarak düşünüyoruz. İlk grup web sitesi ya da e-ticaret sahibi olup hosting sağlayıcısıyla doğru konuşmak istiyor. İkinci grup kendi VPS ya da cPanel hesabını yönetiyor ve adım adım komut arıyor. İki grup için de ayrı notlar bıraktık.

OPcache nedir, PHP bir isteği çalıştırırken hangi adımı atlar?

PHP bir betiği çalıştırmadan önce birkaç iş yapar. Dosyayı diskten okur, sözcüklere ayırır, sözdizimini çözümler ve opcode denen ara komutlara derler. Ancak bundan sonra Zend motoru bu komutları yürütür. OPcache bu zincirin ilk yarısını, yani derleme kısmını önbelleğe alır.

OPcache açıkken ilk istekte derleme yine olur. Ardından PHP, derlenen sonucu ortak belleğe yazar. Sonraki istekler dosyayı yeniden ayrıştırmaz, doğrudan bellekteki opcode'u kullanır. Yani bellekte tuttuğunuz şey sayfanın çıktısı değil, kodun makineye yakın biçimidir.

Bu ayrım önemlidir. Sayfa çıktısını saklayan araçlar farklı bir katmanda çalışır. OPcache ise dinamik sayfanın her istekte yine üretilmesine izin verir, yalnızca kodu hazırlama maliyetini düşürür. Dolayısıyla OPcache, veritabanı sorgularınızı ya da dış API çağrılarınızı hızlandırmaz.

• Atlanan adım: dosyayı okuma, ayrıştırma ve opcode'a derleme.
• Atlanmayan adım: kodun çalışması, veritabanı sorguları, şablon üretimi.
• Saklanan şey: derlenen opcode, ortak bellekte.

Kısacası OPcache nedir sorusunun teknik cevabı, "derleme işini bir kez yapıp sonucu paylaşmak" cümlesine sığar. Geri kalan her şey, bu paylaşımın ne kadar büyük olacağı ve ne zaman yenileneceği üzerine ayardır.

OPcache açık mı, nasıl anlarsınız?

PHP dokümanına göre opcache.enable varsayılan olarak 1, yani açıktır. Ancak bu varsayılan her ortamda geçerli olmayabilir, çünkü hosting sağlayıcınız php.ini dosyasını değiştirmiş olabilir. Ayrıca eklentinin kurulu olması ile etkin olması aynı şey değildir. Bu yüzden kesin cevabı ortamınızdan almanız gerekir.

Üç yol var. Birincisi komut satırında modül listesine bakmaktır. İkincisi phpinfo çıktısında Zend OPcache bölümünü aramaktır. Üçüncüsü opcache_get_status fonksiyonunu çağırmaktır. Bu fonksiyon OPcache kapalıysa false döndürür, açıksa durum dizisini verir.

php -m | grep -i opcache
php -i | grep -E "opcache.(enable|memory_consumption)"

Dikkat edin, bu komutlar CLI sürümünü gösterir. PHP dokümanına göre opcache.enable_cli varsayılan olarak 0'dır. Dolayısıyla CLI çıktısı web sitenizdeki durumu birebir yansıtmayabilir. Web tarafı için aynı bilgiyi bir sayfa üzerinden okumanız gerekir; bunu aşağıda anlatıyoruz.

OPcache açıkken kod değişikliği siteye ne zaman yansır?

Bu sorunun cevabı iki ayara bağlıdır. validate_timestamps açıksa OPcache, revalidate_freq değeri kadar saniyede bir dosyanın değişme tarihine bakar. Varsayılan 2 saniyedir. Dolayısıyla bir dosyayı değiştirdikten kısa süre sonra yeni sürüm devreye girer.

validate_timestamps kapalıysa tablo değişir. OPcache dosyaya hiç bakmaz ve siz bildirene kadar eski opcode'u sunar. Ayrıca değişiklik, yalnızca yeni dosyanın üzerine yazıldığında değil, dosya silindiğinde de önbellekte iz bırakabilir. Kılavuz bu yüzden opcache_invalidate'i dosyayı silmeden önce çağırmanızı söyler.

Pratikte şunu görürsünüz: bir hata düzeltmesi yayınlarsınız, ama ziyaretçi eski davranışı görmeye devam eder. Önce önbellek katmanlarını sırayla eleyin. Tarayıcıyı, sayfa önbelleğini ve ardından OPcache'i kontrol edin. Böylece sorunun hangi katmanda olduğunu hızlıca bulursunuz.

WordPress sitelerinde OPcache nedir, gerçekten fark yaratır mı?

WordPress, çekirdek dosyaları, tema ve eklentilerle her istekte onlarca hatta yüzlerce PHP dosyası yükler. Bu nedenle OPcache, WordPress gibi dosya sayısı yüksek uygulamalarda en çok anlam kazanan önbelleklerden biridir. Kazancın büyüklüğü ise eklentilerinize, sunucunuza ve trafiğinize göre değişir; sabit bir oran vaat etmiyoruz.

OPcache nedir diye arayan WordPress kullanıcıları için en önemli nokta şudur: bu özellik zaten PHP'nin içinde gelir. Burada sık yapılan bir karışıklığı düzeltelim. OPcache, sayfa önbellek eklentilerinin yerine geçmez. Sayfa önbelleği hazır HTML çıktısını sunar ve PHP'yi çoğu zaman hiç çalıştırmaz. OPcache ise PHP'nin çalıştığı durumlarda onu hafifletir. Yani iki katman birbirini tamamlar.

E-ticaret sitelerinde bu fark daha belirgindir. Sepet, ödeme ve hesap sayfalarını genellikle sayfa önbelleğine almazsınız, dolayısıyla PHP her seferinde çalışır. İşte bu dinamik sayfalarda OPcache doğrudan iş görür. Konunun satışlarla ilişkisi için e-ticarette sayfa hızı satışları etkiler mi yazımıza bakabilirsiniz.

En önemli OPcache ayarları nelerdir?

OPcache onlarca ayar sunar, ancak çoğu site için beş altı tanesi yeterlidir. Aşağıdaki tabloda varsayılan değerleri PHP kılavuzundaki OPcache yapılandırma sayfasından aldık. Kılavuz, sürümler arasında farklılık olabilecek ayarlar için ilgili sürüm notlarını da belirtir; kendi sürümünüzde mutlaka kontrol edin.

Bu ayarların çoğu yalnızca php.ini düzeyinde değişir. Dokümana göre memory_consumption, max_accelerated_files ve enable_cli INI_SYSTEM türündedir. Yani bunları sayfa içinden ini_set ile değiştiremezsiniz.

opcache.memory_consumption değeri nasıl seçilir?

Bu ayar, OPcache'in kullanacağı ortak bellek miktarını megabayt cinsinden belirler. PHP kılavuzu varsayılanı 128 MB olarak verir ve en düşük değeri 8 MB olarak zorlar. Ayrıca interned strings belleği bu toplamdan pay alır. Yani 8 MB'lık dize tamponu, 128 MB'ın bir parçasıdır.

Doğru değeri tahmin etmezsiniz, ölçersiniz. Siteyi bir süre normal trafikle çalıştırın, ardından opcache_get_status çıktısındaki used_memory, free_memory ve wasted_memory alanlarına bakın. Free memory sürekli sıfıra yakınsa ya da cache_full true görünüyorsa belleği artırmanız gerekir.

Öte yandan gereğinden büyük bir değer yazmak da kaynak israfıdır. Özellikle küçük bir VPS'te her megabayt başka işlere de lazımdır. Bu nedenle küçük adımlarla artırın ve her değişiklikten sonra durum çıktısını yeniden kontrol edin.

• Önce mevcut kullanımı ölçün.
• Ardından değeri makul bir adımla artırın.
• Son olarak PHP servisini yeniden başlatın ve durumu tekrar okuyun.

opcache.max_accelerated_files neden önemlidir ve nasıl hesaplarsınız?

Bu ayar, önbellek hash tablosundaki en fazla betik anahtarı sayısını belirler. Varsayılan 10000'dir. Kılavuza göre gerçekte kullanılan değer, 223, 463, 983, 1979, 3907, 7963, 16229, 32531, 65407, 130987, 262237, 524521 ve 1048793 dizisinden, yazdığınız değere eşit ya da büyük olan ilk asal sayıdır.

Örnek hesap: sitenizde eklentiler ve vendor klasörü dahil yaklaşık 12000 PHP dosyası olsun. Kılavuzdaki asal listeye göre varsayılan 10000 değeri 16229'a yükselir ve 12000 dosya sığar. Dosya sayınız 20000 olsaydı, 32531 devreye girerdi. Bu sayılar yalnızca örnektir, kendi sayınızı kendiniz ölçmelisiniz.

Dosya sayısını öğrenmek için proje klasörünüzde basit bir sayım yapabilirsiniz.

find /var/www/example.com -name "*.php" | wc -l

Üstelik bu sayıya yalnızca çalışan dosyalar değil, önbelleğe giren tüm betikler dahildir. Sınıra yaklaşırsanız önbellek yeni dosyaları alamaz ve bazı isteklerde yeniden derleme maliyeti geri gelir. Kılavuza göre geçerli aralık 200 ile 1.000.000 arasındadır.

opcache.validate_timestamps açık mı kapalı mı olmalı?

Bu ayar OPcache'in en kritik tercihidir. Açıkken OPcache, revalidate_freq saniyede bir dosyanın değişip değişmediğine bakar. Kapalıyken hiç bakmaz. PHP kılavuzu, kapalı durumda dosya değişikliklerinin görünmesi için opcache_reset, opcache_invalidate ya da web sunucusunun yeniden başlatılması gerektiğini belirtir.

Peki hangisini seçmelisiniz? Geliştirme ortamında açık bırakın, çünkü kodu her değiştirişinizde sıfırlama düşünmek istemezsiniz. Canlı ortamda kapatmak hız için cazip görünebilir. Ancak yalnızca düzenli bir deploy sürecinde, sıfırlama adımı otomatik yapılıyorsa kapatın.

WordPress'te bu risk daha belirgindir. Panelden eklenti ya da tema güncellerseniz dosyalar değişir. Kapalı ayarda eski kod bellekte kalabilir ve site yarım güncelleme almış gibi davranabilir. Bu nedenle yönetimini bilmediğiniz bir canlı sitede bu ayarı kapatmayın.

revalidate_freq, save_comments ve interned strings ne işe yarar?

revalidate_freq, validate_timestamps açıkken kontrol aralığını saniye cinsinden verir. Varsayılan 2'dir. Kılavuza göre 0 değeri, OPcache'in her istekte güncelleme kontrolü yapması anlamına gelir. validate_timestamps kapalıysa bu ayar zaten yok sayılır.

save_comments varsayılan olarak 1'dir. Kapatırsanız doküman yorumları önbellekten düşer ve bellek biraz küçülür. Ancak kılavuz, Doctrine, Zend Framework 2 ve PHPUnit gibi yorumlardan anotasyon okuyan çerçevelerin bozulabileceğini açıkça söyler. Dolayısıyla kodunuzun neye dayandığını bilmeden bu ayarı kapatmayın.

interned_strings_buffer ise tekrar eden dizelerin tek kopyasını tutan alandır. Varsayılan 8 MB'dır. Büyük bir kod tabanında bu alan dolarsa durum çıktısında fark edersiniz. Böyle bir durumda değeri artırmayı düşünebilirsiniz, ancak önce ölçün.

• revalidate_freq: kontrol sıklığı, yalnızca zaman damgası kontrolü açıkken geçerli.
• save_comments: yorumları saklar, anotasyon kullanan kodlar için gerekli.
• interned_strings_buffer: dize tamponu, toplam bellekten ayrılır.

Örnek bir OPcache yapılandırması neye benzer?

Aşağıdaki blok bir örnektir, resmi bir öneri ya da varsayılan değil. Sayıları kendi ölçümlerinize göre değiştirmelisiniz. Hosting sağlayıcınız php.ini düzenlemenize izin vermiyorsa, bu ayarları panelin PHP seçenekleri bölümünden ya da destek ekibinden isteyin.

opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.validate_timestamps=1
opcache.revalidate_freq=2

Bu örnekte validate_timestamps bilerek açık bırakıldı. Çünkü kapatmak, deploy sürecinizde sıfırlama adımı olduğunu varsayar. Ayrıca ayar dosyasının yeri dağıtıma ve kuruluma göre değişir. Doğru dosyayı bulmak için phpinfo çıktısındaki Loaded Configuration File satırına bakın.

Değişiklikten sonra PHP servisinin ayarı yeniden okuması gerekir. INI_SYSTEM türündeki ayarlar çalışma anında değişmez. Bu yüzden FPM ya da web sunucusu sürecini yeniden başlatmanız ya da yeniden yüklemeniz gerekir; servis adı kuruluma göre farklıdır.

Ayarların çalıştığını phpinfo ve opcache_get_status ile nasıl doğrularsınız?

Ayarı yazmak yetmez, web tarafında gerçekten uygulandığını görmelisiniz. En basit yol, geçici bir PHP dosyasına phpinfo çağrısı koymaktır. Çıktıda Zend OPcache bölümünü arayın ve ayarlarınızı bu bölümdeki değerlerle karşılaştırın. İşiniz bitince dosyayı hemen silin, çünkü phpinfo sunucu ayrıntılarını açığa çıkarır.

Daha ayrıntılı bilgi için opcache_get_status kullanabilirsiniz. Fonksiyonun include_scripts parametresini false verirseniz, uzun betik listesi çıktıdan çıkar. Böylece sonucu okumak kolaylaşır. Dosya içeriği olarak şu tek satır yeterlidir; dosyanın başına PHP açılış etiketini siz eklersiniz.

var_dump(opcache_get_status(false));

Çıktıda dört grup alana bakın. opcache_enabled ve cache_full genel durumu verir. memory_usage bölümü kullanılan, boş ve boşa harcanan belleği gösterir. opcache_statistics bölümü num_cached_scripts, hits, misses ve opcache_hit_rate değerlerini içerir. Son olarak oom_restarts ve hash_restarts yeniden başlatma sebeplerini ayırır.

Deploy sonrası OPcache'i nasıl sıfırlarsınız?

Kod güncellediğinizde eski opcode bellekte kalabilir. validate_timestamps açıksa bu durum kısa sürede düzelir. Kapalıysa sıfırlamayı siz yapmalısınız. PHP iki fonksiyon sunar: opcache_reset tüm önbelleği temizler, opcache_invalidate ise yalnızca belirttiğiniz dosyayı geçersiz kılar.

opcache_invalidate için kılavuz iki önemli not düşer. Varsayılan davranışta dosyayı yalnızca değişiklik tarihi önbellektekinden yeniyse geçersiz kılar; force parametresi true ise koşulsuz geçersiz kılar. Ayrıca fonksiyon girdiyi bellekten çıkarmaz, yalnızca yeniden derlemeyi zorlar. Önbellek doluysa opcache_reset'in yerini tutmaz.

CLI ve web için OPcache neden ayrı çalışır?

Çoğu kurulumda komut satırındaki PHP ile web sunucusunun ya da FPM'in PHP'si ayrı süreçlerdir ve ayrı bir opcode önbelleği kullanır. PHP kılavuzundaki kullanıcı notları bunu açıkça söyler: CLI'dan çağırdığınız opcache_reset, web önbelleğini temizlemez. Fonksiyon true döndürse bile web tarafı değişmez.

OPcache nedir sorusunu CLI ile birlikte düşününce bu detay sık hata kaynağı olur. Biri SSH ile bağlanıp bir komutla sıfırlama yapar ve sorunu çözdüğünü sanır. Oysa web siteniz eski kodu sunmaya devam eder. Dolayısıyla sıfırlamanın web tarafında yapıldığından emin olmalısınız.

Ayrıca CLI için enable_cli varsayılan olarak kapalıdır. Yani komut satırında OPcache'in kapalı görünmesi sorun değildir. Önemli olan web isteğinin gördüğü ayardır. Bu nedenle kontrolü her zaman bir HTTP isteği üzerinden yapın.

• CLI çıktısı web durumunu göstermeyebilir.
• CLI'dan yapılan sıfırlama web önbelleğine dokunmayabilir.
• Güvenilir kontrolü, web üzerinden çalışan bir betikle yaparsınız.

OPcache sıfırlama adresini güvenli şekilde nasıl kullanırsınız?

Kılavuzdaki kullanıcı notları yaygın bir yöntem önerir: web'den erişilen küçük bir betik yazıp onu çağırmak. Teknik olarak işe yarar. Ancak bu betiği herkese açık bırakırsanız, herhangi biri önbelleğinizi sürekli boşaltabilir ve sitenizi gereksiz yere yavaşlatabilir.

Bu yüzden iki kural koyun. Birincisi, betiği kimlik doğrulamasız bırakmayın; yalnızca sunucunun kendi adresinden erişilebilsin. İkincisi, adresi tahmin edilebilir bir yola koymayın. En iyisi bu betiği hiç kalıcı yapmayıp deploy aracınızın bir adımı olarak çalıştırmaktır.

Sıfırlama için belge köküne parola ya da anahtar içeren geçici betik bırakmak ayrıca risklidir. Unutulan bir dosya aylarca açık kalabilir. Güvenlik tarafını genişletmek isterseniz OWASP Top 10 web güvenlik açıkları yazımızdaki kontrol listesi iyi bir başlangıçtır.

Kendi başınıza güvenli bir kurulum yapamıyorsanız, deploy sonrası sıfırlamayı hosting sağlayıcınızdan ya da yazılım ekibinizden isteyin.

OPcache dolarsa ne olur ve hangi belirtiler çıkar?

OPcache dolduğunda yeni betikleri önbelleğe alamaz. Kılavuz, durum dizisinde cache_full alanını ve oom_restarts sayacını verir. Oom_restarts, bellek yetersizliği yüzünden olan yeniden başlatmaları gösterir. Hash_restarts ise anahtar tablosunun dolmasıyla ilgili yeniden başlatmaları sayar.

Belirtiler genellikle dolaylıdır. Sunucu CPU kullanımı beklenenden yüksek kalabilir, bazı sayfalar zaman zaman daha yavaş açılabilir. Ayrıca opcache_hit_rate düşük çıkar. Ancak bu belirtiler başka nedenlerden de çıkabilir, bu yüzden kesin teşhis için durum çıktısını okuyun.

• cache_full true ise bellek ya da dosya sınırı dolmuştur.
• oom_restarts artıyorsa memory_consumption yetersizdir.
• hash_restarts artıyorsa max_accelerated_files'ı gözden geçirin.
• Düşük hit rate, önbelleğin ısınmadığını ya da sık sıfırlandığını gösterebilir.

Çözüm genellikle ilgili ayarı artırıp servisi yeniden başlatmaktır. Yine de önce sorunun gerçekten OPcache'ten geldiğini doğrulayın.

OPcache JIT nedir, açmanız gerekir mi?

JIT, OPcache içinde yer alan ve opcode'u makine koduna çeviren derleyicidir. PHP kılavuzuna göre opcache.jit varsayılanı PHP 8.4.0 ile "disable" oldu; önceki sürümlerde varsayılan "tracing" idi. jit_buffer_size sıfırsa JIT zaten devre dışı kalır. Sürümünüzdeki değeri kılavuzdan kontrol edin.

Tipik bir WordPress ya da e-ticaret sitesi, ağırlıklı olarak veritabanı ve girdi çıktı beklediği için JIT'ten büyük kazanç beklemeyin. JIT daha çok yoğun hesaplama yapan iş yüklerinde anlam kazanır. Bu yüzden önce sıradan OPcache ayarlarını doğru yapın.

Ayrıca JIT açıldığında, kılavuza göre paylaşılan bellek bölümü memory_consumption artı jit_buffer_size toplamı kadar olur. Yani bellek planınızı değiştirir. JIT'i yalnızca kendi iş yükünüzde ölçüm yaptıktan sonra açın ve sonucu kaydedin.

OPcache, Redis, Memcached, Varnish ve sayfa önbelleği arasındaki fark nedir?

Bu araçları sık karıştırırsınız, çünkü hepsine "önbellek" denir. Oysa her biri zincirin başka bir halkasında çalışır. OPcache kodu, Redis ve Memcached veriyi, Varnish ve sayfa önbelleği ise HTTP çıktısını saklar. Dolayısıyla biri diğerinin alternatifi değil, tamamlayıcısıdır.

OPcache nedir sorusunu diğer önbelleklerden ayırmak için bu tabloya bakın. Veri önbelleğini ayrıntılı anlatan yazımız hazır: yazılımda önbellekleme, Redis ve Memcached. Bu yüzden burada tekrar etmiyoruz. Yalnızca şunu not edin: OPcache hosting tarafında genellikle zaten kuruludur, diğerleri ise ayrı kararlar gerektirir.

OPcache etkisini nasıl ölçersiniz?

OPcache nedir sorusunu anlamak kadar etkisini görmek de önemlidir. Ölçmeden değiştirmek tahmin yürütmektir. OPcache ayarını değiştirmeden önce ve sonra aynı koşullarda aynı sayfaları test edin. En kullanışlı metrik, sunucunun ilk baytı ne kadar sürede gönderdiğidir. Bunu tarayıcı geliştirici araçlarında ya da Lighthouse raporunda görebilirsiniz.

Bir testi tek kez yapmayın. Ağ ve sunucu yükü sürekli değişir, bu yüzden her ölçümü birkaç kez tekrarlayın. Ayrıca önbellek ısınmadan yapılan ilk istek her zaman daha yavaştır. Bu nedenle sonuçları ısınmış önbellekle kıyaslayın.

Lighthouse kullanımını Google Lighthouse ile site performans testi yazımızda anlattık. Hızın arama görünürlüğüne etkisi için site hızı SEO'yu nasıl etkiler yazısına da bakın. Örneğin LCP ve INP gibi ölçümleri Core Web Vitals rehberimizde bulabilirsiniz.

Kazancı rakamla vaat etmiyoruz. Çünkü sonuç; kod tabanınıza, eklentilerinize ve sunucunuza göre değişir.

Hosting sağlayıcınıza OPcache için hangi soruları sorabilirsiniz?

Sunucuyu siz yönetmiyorsanız, doğru soru sormak yarı çözümdür. Destek ekibi çoğu zaman genel bir cevap verir. Somut ve ölçülebilir sorular sorarsanız, hem sağlayıcı işi hızlı çözer hem de siz neyin değiştiğini anlarsınız.

• OPcache bu hesapta web tarafında açık mı?
• memory_consumption ve max_accelerated_files değerleri nedir?
• validate_timestamps açık mı, kapalıysa deploy sonrası sıfırlama nasıl yapılıyor?
• Panelden ya da destek talebiyle bu değerleri değiştirebilir miyim?
• PHP servisini yeniden başlatmak kısa bir kesintiye yol açar mı?

Cevapları not edin ve bir kayıt tutun. Daha sonra bir güncelleme sonrası sorun çıkarsa, hangi ayarın ne zaman değiştiğini bilmek işinizi kolaylaştırır. Kendi değerlerinizi ise bu yazıdaki ölçüm adımlarıyla doğrulayın.

OPcache ne zaman sizin işiniz değil, hosting sağlayıcınıza bırakmalısınız?

Paylaşımlı hostingde php.ini üzerinde yetkiniz sınırlıdır ve bu normaldir. Sağlayıcı, OPcache'i büyük olasılıkla tüm hesaplar için tek bir yapılandırmayla yönetir. Böyle bir ortamda ayar peşinde koşmak yerine, destek ekibine somut bir soru sormak daha verimlidir.

Şu durumlarda işi sağlayıcıya ya da altyapıyı bilen bir uzmana bırakın. Birden fazla site aynı sunucuyu paylaşıyorsa, tek bir yanlış ayar hepsini etkiler. Canlı mağazanızda deneme yapmak da risklidir. Ayrıca servis yeniden başlatmanın kesinti yaratıp yaratmayacağını bilmiyorsanız, dokunmayın.

• Yetkiniz yoksa destek ekibinden mevcut değerleri ve sıfırlama yöntemini isteyin.
• Canlı mağazada ayarı önce bir test kopyasında deneyin.
• Yedek almadan sunucu ayarına dokunmayın.

Yedek planı için web sitesi yedekleme stratejisi yazımıza bakın. Hosting seçimini ise web sitesi için hosting nasıl seçilir rehberimiz anlatır.

OPcache'te en sık yapılan hatalar nelerdir?

OPcache nedir sorusunu bilen biri bile aynı tuzaklara düşebilir. Hataların çoğu ayarın kendisinden değil, ayarı yanlış ortamda doğrulamaktan çıkar. Aşağıdaki liste, bu konuda en sık karşılaşılan karışıklıkları toplar. Bunların hepsi resmi dokümandaki davranışlardan türer, bizim sunucu deneyimimizden değil.

• CLI çıktısına bakıp web durumunu tahmin etmek.
• validate_timestamps kapatıp deploy sonrası sıfırlamayı unutmak.
• Sıfırlama betiğini herkese açık bırakmak.
• max_accelerated_files'ı dosya sayısını ölçmeden seçmek.
• save_comments'ı kapatıp anotasyon kullanan kodu bozmak.
• Değişiklikten sonra servisi yeniden başlatmayı unutmak.

Bir diğer hata da OPcache'i tüm yavaşlığın çözümü saymaktır. Yavaş bir veritabanı sorgusu ya da büyük görseller OPcache ile düzelmez. Bu yüzden önce darboğazı bulun. Görsel tarafı için araçlar sayfamızdaki dönüştürücülere, altyapı tarafı için site altyapı tespiti aracına göz atabilirsiniz.

OPcache nedir sorusundan sonra hız için sıradaki adımlar neler?

OPcache doğru ayarlandıktan sonra sıra diğer katmanlara gelir. Önce ölçüm yapın, ardından en büyük darboğazı seçin. Çoğu sitede bu görseller, ağır betikler ya da tema ve eklenti şişkinliği olur. Sunucu tarafı ayarlar ise bunların yalnızca bir parçasıdır.

Hızın arama sonuçlarıyla ilişkisini görmek için SEO tarafını da gözden geçirin. Teknik sağlığı ve içerik planını birlikte ele almak isterseniz SEO danışmanlığı hizmetimiz bu işi kapsar. Yeni bir sitede hız hedeflerini baştan koymak için web tasarım hizmetimize bakabilirsiniz.

Biz bir hosting firması değiliz; sunucu işletmeyi vaat etmiyoruz. Buna karşın web ve pazarlama ekibi olarak, hosting kararınızın sitenizin performansına ve güvenliğine etkisini anlamanıza yardımcı oluyoruz. Kısacası bu yazıdaki adımları kendiniz deneyin, emin olmadığınız yerde sağlayıcınıza ya da bize danışın.