WordPress ve Laravel İçin php.ini Ayarları: En Mantıklı memory_limit, max_execution_time ve upload_max_filesize Değerleri

php.ini Nedir, WordPress ve Laravel’i Neden Bu Kadar Etkiler?

WordPress ve Laravel projelerinde performans, stabilite ve hata oranı büyük ölçüde PHP yapılandırmasına bağlıdır. Bu yapılandırmanın kalbi de php.ini dosyasıdır. memory_limit, max_execution_time ve upload_max_filesize gibi birkaç kritik ayarı doğru yapmadığınızda, siteniz çok iyi bir sunucuda bile beyaz ekran hataları, zaman aşımı sorunları ve başarısız dosya yüklemeleriyle uğraşabilir.

DCHost altyapısında her gün gördüğümüz tipik senaryo şu: Geliştirici veya ajans tarafı kodu gayet temiz yazmış, veritabanı fena değil, ama PHP tarafında 64M memory_limit ve 30 saniyelik max_execution_time ile WooCommerce mağazası veya yoğun bir Laravel paneli koşmaya çalışıyor. Sonuç; özellikle yoğun saatlerde 500 hataları, eksik gelen sayfalar ve kopan AJAX istekleri.

Bu yazıda, özellikle WordPress (blog, kurumsal site, WooCommerce, sayfa oluşturucular) ve Laravel (API, yönetim paneli, SaaS, queue işçileri) projeleri için php.ini tarafında en kritik üç ayarı detaylı olarak ele alacağız:

• memory_limit: Her bir PHP sürecinin kullanabileceği maksimum RAM
• max_execution_time: Bir PHP isteğinin en fazla kaç saniye çalışabileceği
• upload_max_filesize (ve post_max_size): Kullanıcıların yükleyebileceği maksimum dosya boyutu

Genel PHP ayarlarıyla ilgili daha temel bir çerçeveye ihtiyaç duyuyorsanız, önce PHP ayarlarını doğru yapmak üzerine yazdığımız rehbere göz atıp, ardından bu makaledeki WordPress ve Laravel odaklı detaylara dalmanız iyi bir yol olur.

WordPress ve Laravel İçin Kaynak Planlama Mantığını Kurmak

php.ini değerlerini ezbere rakamlarla değil, arkasındaki kaynak planlama mantığını anlayarak ayarlamak çok daha sağlıklı. Çünkü memory_limit sadece tek başına bir sayı değildir; sunucunuzun toplam RAM miktarı, PHP-FPM havuzu, aynı anda kaç sürecin çalıştığı ve veritabanı/önbellek sunucularının RAM kullanımıyla birlikte ele alınmalıdır.

DCHost üzerinde gördüğümüz projelerde kabaca şu tablo oluşuyor:

• Küçük WordPress blogları ve kurumsal siteler: 1–2 vCPU, 2–4 GB RAM
• WooCommerce ve yoğun içerikli WordPress siteleri: 2–4 vCPU, 4–8 GB RAM
• Orta ölçekli Laravel SaaS / API projeleri: 4+ vCPU, 8+ GB RAM

CPU ve RAM boyutlamasını daha derinlemesine anlamak isterseniz, WordPress blog, WooCommerce ve SaaS için CPU ve RAM planlama rehberimizi mutlaka okumanızı öneririz. Oradaki kapasite mantığı, burada seçeceğiniz php.ini değerleriyle birebir bağlantılıdır.

Ayrıca PHP işlemlerinin nasıl havuzlandığı ve eşzamanlı süreç sayısının nasıl hesaplanacağı konusunda WordPress ve WooCommerce için PHP-FPM ayarları rehberimiz size iyi bir temel sağlar. Şimdi tek tek ayarlara inelim.

memory_limit: Her PHP Sürecine Ne Kadar RAM Vermelisiniz?

memory_limit, bir PHP sürecinin kullanabileceği maksimum RAM miktarını belirler. Çok düşük ayarlarsanız “Allowed memory size of XXX bytes exhausted” hataları ve beyaz ekranlarla uğraşırsınız. Çok yüksek ayarlarsanız bu sefer de birkaç ağır istek tüm sunucu RAM’ini çekip diğer servisleri (MySQL, Redis, web sunucusu) çökertme riskini artırır.

WordPress İçin Önerilen memory_limit Değerleri

WordPress tarafında eklentiler, tema ve sayfa oluşturucular hafızayı hızla tüketebilir. Özellikle WooCommerce, Elementor, Divi, görsel sıkıştırma ve yedekleme eklentileri bellek kullanımını ciddi artırır. DCHost üzerinde gördüğümüz gerçek senaryolara göre mantıklı aralıklar şöyle:

• Küçük blog / basit kurumsal site (hafif tema, az eklenti): 128M
• Orta ölçekli WordPress (standart tema, 15–25 eklenti): 256M
• WooCommerce mağazası (ortalama trafik, 30+ eklenti, sayfa oluşturucu kullanımı): 256M – 512M
• Ağır WooCommerce + sayfa oluşturucu + çok dilli yapı: 512M – 768M

Burada dikkat etmeniz gereken nokta şu: memory_limit, her bir PHP süreci için geçerlidir. Örneğin:

• Sunucunuzda 4 GB RAM varsa,
• PHP-FPM için eşzamanlı 20 child sürecine izin verdiyseniz,
• memory_limit’i 512M yaparsanız teorik maksimum PHP bellek kullanımı 20 × 512M = 10 GB olur (yani pratikte mümkün değil, sunucu RAM’inizi hızla tüketecektir).

Bu yüzden memory_limit’i belirlerken mutlaka PHP-FPM havuz ayarlarına da bakmalısınız. Bu konuyu detaylı anlattığımız Laravel prod ortam optimizasyonu rehberimizde PHP-FPM ve bellek ilişkisini Laravel örneği üzerinden ama WordPress’e de uyarlanabilir şekilde anlattık.

Laravel İçin Önerilen memory_limit Değerleri

Laravel tarafında durum biraz farklıdır; çünkü Laravel projeleri genellikle:

• Queue işçileri (queue workers)
• Horizon, Octane, scheduler
• Ağır raporlama / export işleri

gibi arka plan süreçleriyle birlikte çalışır. Önerdiğimiz başlangıç değerleri:

• Küçük/orta ölçekli API veya admin panel: 256M
• Orta ölçekli SaaS / çok tenant’lı panel: 256M – 512M
• Ağır raporlama, çok büyük koleksiyon işleme, PDF/export ağırlıklı işler: web için 256M – 512M, CLI ve queue işçileri için 512M mantıklı bir başlangıçtır.

Laravel’de asıl kritik nokta, uzun yaşayan queue işçilerinin üzerindeki bellek sızıntılarını fark etmenizdir. Horizon veya Supervisor ile çalışan işçiler uzun süre restart edilmezse memory_limit’i düşük tutmak, sızıntıyı daha erken görmenize yardımcı olur. Örneğin:

• Web istekleri: memory_limit = 256M
• Queue işçileri (CLI): memory_limit = 512M, ama işçi başına iş sayısını sınırlayarak (örneğin 1000 işte bir restart) bellek tüketimini kontrol altında tutmak.

memory_limit Değerini Hesaplama Mantığı

Pratik bir yaklaşım olarak şu formülü kullanabilirsiniz:

• Sunucu toplam RAM’inin en fazla %40–50’sini PHP’ye ayırın (geri kalanı MySQL, Redis, sistem ve disk cache için kalsın).
• PHP-FPM için beklediğiniz eşzamanlı child sayısını (pm.max_children) belirleyin.
• PHP için ayırdığınız toplam RAM / child sayısı ≈ güvenli memory_limit başlangıç değeri.

Örneğin:

• 8 GB RAM’li bir VPS’te 4 GB’ı PHP için ayırıyorsunuz.
• pm.max_children = 20 ise, 4 GB / 20 ≈ 200 MB civarı.
• Buradan yola çıkarak 256M mantıklı bir başlangıç, yoğun WooCommerce ise 20 child yerine 15 child ve 256–384M aralığında bir değer düşünebilirsiniz.

memory_limit Nasıl Değiştirilir?

Bulunduğunuz ortama göre farklı yöntemler vardır:

• Paylaşımlı hosting: cPanel/DirectAdmin PHP Selector veya benzeri arayüzden memory_limit ayarı; bazı ortamlarda .user.ini veya php.ini ile.
• VPS / dedicated: Global /etc/php/X.Y/fpm/php.ini ve .../cli/php.ini dosyalarında; ayrıca havuz bazlı ayarlar için www.conf veya siteye özel pool dosyaları.
• .htaccess (Apache): php_value memory_limit 256M (mod_php kullanılan nadir ortamlarda).

max_execution_time: Zaman Aşımı Ayarını Gerçekçi Tutmak

max_execution_time, bir PHP betiğinin ne kadar süre çalışabileceğini saniye cinsinden belirler. Web istekleri sonsuza kadar sürmemelidir; aksi halde hem kullanıcı deneyimi kötüleşir, hem de kaynak tüketimi kontrolden çıkar.

WordPress İçin max_execution_time Önerileri

WordPress’te yavaş çalışan işlemler genellikle şuralarda karşımıza çıkar:

• Büyük eklenti/tema güncellemeleri
• Toplu içe/dışa aktarma (import/export) işlemleri
• Yedek alma veya büyük görselleri işleme

Normal sayfa görüntüleme istekleri çoğu zaman 1 saniyenin altında bitmelidir. Kullanıcıya cevap veren HTTP istekleri için 60 saniyeden uzun süreler çoğu zaman gereksizdir. DCHost tarafında gördüğümüz sağlıklı aralıklar:

• Standart WordPress site: 60 saniye
• WooCommerce + ağır sayfa oluşturucu: 60–90 saniye
• Nadiren ihtiyaç duyulan büyük import/export scriptleri (CLI veya özel admin sayfası): 120–300 saniye

Önemli bir nokta: Uzun sürecek işleri mutlaka gerçek cron ve/veya CLI komutlarıyla çalıştırmaya çalışın. Yönetim paneli üzerinden tek HTTP isteği içinde çok büyük iş yapmak yerine, işi parçalayıp arka planda çalışan bir job yapısı kurmak her zaman daha stabil ve güvenlidir. WordPress tarafında bu mantığı kurarken wp-cron yerine gerçek cron kullanma rehberimizden de yararlanabilirsiniz.

Laravel İçin max_execution_time Önerileri

Laravel dünyasında iki ayrı kategori düşünmek gerekir:

• HTTP istekleri: Kullanıcıya direkt cevap veren web veya API istekleri
• CLI / queue işleri: artisan komutları, scheduler, queue workers

Önerdiğimiz aralıklar:

• Web/API istekleri: 30–60 saniye
• Yönetim panelinde ağır raporlar: 60–120 saniye (mümkünse raporu queue’ye atıp arka planda üretmek daha doğru)
• CLI ve queue işleri: Çoğu ortamda max_execution_time = 0 (sınırsız) bırakılır, bunun yerine işçi başına iş sayısı, timeout ve retry mantığı uygulamaya bırakılır.

Laravel’de uzun süren işlerin çoğunu queue tarafına itip, web isteğini mümkün olduğunca hızlı tamamlamak her zaman daha sağlıklı bir mimaridir. DCHost üzerinde Laravel prod ortamı kurarken Laravel prod optimizasyon rehberimizde anlattığımız Horizon, queue, OPcache ve PHP-FPM kombinasyonunu takip ederseniz, max_execution_time’ı da çok uç değerlere çekmek zorunda kalmazsınız.

max_execution_time İçin Pratik Tavsiyeler

• Web istekleri: 30–60 saniye aralığı genelde fazlasıyla yeterli.
• Bakım/güncelleme gibi ağır işlemleri CLI’da çalıştırın; burada 300–600 saniye bile mantıklı olabilir.
• Sürekli 120+ saniye çalışan web istekleri görüyorsanız, muhtemelen mimariyi gözden geçirmeniz gerekiyordur (veritabanı sorguları, N+1 problemleri, eksik indeksler vb.).

upload_max_filesize ve post_max_size: Dosya Yükleme Sınırını Doğru Koymak

WordPress ve Laravel’de en sık sorulan sorulardan biri: “Müşteri 200 MB’lık PDF yükleyemiyor, neden?” Çoğu zaman sebep PHP tarafındaki upload_max_filesize ve post_max_size değerleridir.

Bu İki Ayar Arasındaki İlişki

• upload_max_filesize: Tek bir dosyanın maksimum boyutu.
• post_max_size: Bir POST isteğiyle gönderilen tüm verinin (dosyalar + form alanları) toplam boyut limiti.

Genel kural:

• post_max_size ≥ upload_max_filesize olmalıdır.
• Genelde post_max_size’i upload_max_filesize’den biraz daha büyük tutmak iyi bir pratiktir (örneğin 64M upload, 80M post).

WordPress İçin Dosya Yükleme Sınırları

WordPress’te tipik senaryolar:

• Küçük blog / kurumsal site: 8–16 MB çoğu zaman yeterli.
• Orta ölçekli içerik siteleri (yüksek çözünürlüklü görseller): 32–64 MB.
• WooCommerce ürün görselleri + dokümanlar: 64–128 MB.
• Online eğitim / video yüklenen platformlar: 256–512 MB (mümkünse büyük videoları doğrudan object storage/CDN’e yüklemek daha iyi mimari).

Burada stratejik düşünmek önemli. Büyük dosyaları gerçekten web sunucunuz üzerinden mi taşımak istiyorsunuz, yoksa object storage ile medya offload stratejisi gibi çözümlerle medya trafiğini farklı bir katmana mı aktarmak daha iyi? DCHost altyapısında media offload, hem PHP yükünü hem de disk I/O’yu ciddi oranda hafifletiyor.

Laravel İçin Dosya Yükleme Sınırları

Laravel tarafında upload limitleri genellikle:

• Yönetim paneline dosya yükleme (dokümanlar, görseller, CSV/Excel import)
• Kullanıcı tarafından yüklenen profil resimleri, raporlar, PDF’ler
• API üzerinden gönderilen dosyalar

Genel tavsiye aralıkları:

• Standart uygulamalar: 16–64 MB
• CSV/Excel import ağırlıklı uygulamalar: 64–128 MB
• Özel medya uygulamaları: 256+ MB (yine, burada da object storage ve parçalı upload mimarilerini düşünmek gerek)

Laravel’de de büyük dosyalar için tek dev POST isteği yerine, parçalı yükleme (chunked upload) ve doğrudan object storage’a yazma gibi mimariler ciddi avantaj sağlar. Bu tarz senaryoları planlarken, büyük medya dosyaları için yükleme stratejisi rehberimizi incelemek iyi bir başlangıç olur.

WordPress İçin Örnek php.ini Senaryoları

Aşağıda DCHost üzerinde sık gördüğümüz üç tip WordPress projesi için makul başlangıç ayarlarını toparlayalım. Bunlar örnek başlangıç değerleridir; gerçek projede izleme yapıp gerektiğinde yukarı/aşağı çekmek en doğrusudur.

1) Kişisel Blog / Basit Kurumsal Site

• Trafik: Düşük–orta
• Eklenti sayısı: 10–15
• WooCommerce yok

memory_limit = 128M
max_execution_time = 60
upload_max_filesize = 16M
post_max_size = 20M

Bu tip sitelerde asıl kazanç sunucu tarafı önbellek (OPcache, gerektiğinde tam sayfa cache) ve doğru sunucu seçimiyle gelir. OPcache tarafını detaylı kurcalamak isterseniz, WordPress ve Laravel için OPcache ayarları rehberimiz tam bu konuyu anlatıyor.

2) Orta Ölçekli Kurumsal Site / İçerik Ağırlıklı Blog

• Trafik: Orta
• Eklenti sayısı: 20–30
• Görsel/makale sayısı fazla

memory_limit = 256M
max_execution_time = 60
upload_max_filesize = 64M
post_max_size = 80M

Bu seviyede veritabanı optimizasyonu, CDN ve doğru cache stratejisi devreye girer. Sunucu tarafında TTFB’yi düşürüp Core Web Vitals metriklerini iyileştirmek için Core Web Vitals’ı hosting tarafında iyileştirme rehberimize göz atmak iyi olur.

3) WooCommerce Mağazası (Sayfa Oluşturuculu)

• Trafik: Orta–yüksek
• WooCommerce + Elementor/Divi + birçok entegrasyon
• Yoğun ürün kataloğu, kampanyalar

memory_limit = 512M
max_execution_time = 90
upload_max_filesize = 128M
post_max_size = 160M

Burada mutlaka PHP-FPM ayarları, MySQL/InnoDB tuning ve tam sayfa cache stratejisiyle beraber düşünmek gerekiyor. WooCommerce için kapasite ve veritabanı tarafını detaylı ele aldığımız WooCommerce MySQL/InnoDB tuning rehberi ile birlikte bu ayarları düşünürseniz çok daha dengeli bir yapı kurarsınız.

Laravel İçin Örnek php.ini ve Uygulama Senaryoları

Laravel tarafında genelde üç ana profil görüyoruz: sadece API, admin paneli + API, bir de queue ağırlıklı SaaS uygulamaları.

1) Sadece API Sunan Laravel Uygulaması

• Ön uç: React/Vue/Next.js gibi ayrı bir frontend
• Laravel sadece JSON API sunuyor

memory_limit = 256M
max_execution_time = 60
upload_max_filesize = 32M
post_max_size = 40M

API’lerde ideal olan, neredeyse tüm isteklerin birkaç yüz milisaniye ile 2–3 saniye arasında tamamlanmasıdır. Eğer max_execution_time’ı sürekli artırmaya ihtiyaç duyuyorsanız, sorgularda N+1 problemleri, eksik indeksler veya gereksiz dosya işlemleri olabilir.

2) Admin Paneli + API Laravel Uygulaması

• Hem son kullanıcı API’leri hem de yöneticilerin kullandığı panel
• CSV/Excel import, PDF export gibi işlemler de var

memory_limit = 256M – 512M
max_execution_time = 60 – 120
upload_max_filesize = 64M
post_max_size = 80M

Burada özellikle rapor üretimlerini ve büyük import işlemlerini queue’ye itmeniz çok kritik. Böylece kullanıcı arayüzü hızlı kalır, ağır işler arka planda Laravel queue işçileri tarafından yapılır.

3) Queue Ağırlıklı SaaS / Arka Plan İşleri Yoğun Uygulamalar

• Çok sayıda arka plan işi (e-posta gönderimi, rapor, üçüncü parti API entegrasyonları)
• Horizon, Octane, Redis gibi bileşenler devrede

Bu tür projelerde iki farklı php.ini mantığına ihtiyaç olabilir:

• Web istekleri için daha muhafazakâr ayarlar
• CLI/queue işçileri için daha geniş memory_limit ve farklı timeout davranışları

; Web (FPM)
memory_limit = 256M
max_execution_time = 60

; CLI (queue workers)
memory_limit = 512M
max_execution_time = 0 ; Süresiz, yönetim işçi bazında

Queue işçilerinin sınırsız süre çalışmasına izin verirken, Horizon veya Supervisor konfigürasyonunda job timeout, max-jobs (işçi başına iş sayısı) ve memory limit gibi ayarları mutlaka doğru yapılandırın. Bunları nasıl bir araya getireceğinizi yine Laravel prod ortam optimizasyon rehberinde adım adım anlattık.

Paylaşımlı Hosting, VPS ve dedicated sunucuda Farklı Yaklaşım

php.ini ayarlarını yaparken bulunduğunuz altyapı türü de sınırlarınızı belirler:

• Paylaşımlı hosting: Üst sınırlar hosting firması tarafından tanımlıdır. Örneğin 256M üzerini seçemeyebilirsiniz. Bir noktadan sonra sadece php.ini ayarını büyütmek değil, üst pakete ya da VPS’e geçmek gerekir.
• VPS (sanal sunucu): DCHost üzerinde kendi NVMe VPS’inizde php.ini ve PHP-FPM üzerinde tam kontrol sağlar, bellek limitlerini hem uygulamanın ihtiyacına hem de toplam RAM’e göre ayarlayabilirsiniz.
• Dedicated / colocation: Yüksek trafikli WordPress, WooCommerce veya Laravel SaaS projeleri için bellek, disk ve network üzerinde tam kontrol ve izole performans sunar.

Eğer sürekli memory_limit’i yükseltmek zorunda kalıyor, buna rağmen 500 hataları, yavaşlayan sorgular ve “Resource Limit” uyarıları görüyorsanız; belki de sorun sadece php.ini değeri değil, kullandığınız planın kapasitesidir. Bu noktada DCHost ekibi olarak hem paylaşımlı hosting → VPS geçişlerinde, hem de VPS’ten dedicated veya colocation’a geçerken kapasite planlama desteği veriyoruz.

php.ini Değişikliklerini Test Etmek ve Geri Almak

Son olarak, php.ini üzerinde değişiklik yaparken bazı temel pratiklere uymanızı öneririz:

• Tek seferde çok büyük değişiklikler yapmayın; önce memory_limit’i 128M’den 256M’ye çıkarıp gözlemleyin, sonra gerekiyorsa 512M’ye yükseltin.
• Değişiklik sonrası kısa bir PHP-FPM restart (veya paylaşımlı hostingte PHP versiyonunu bir değiştirip geri alma gibi tetikleyiciler) uygulamayı unutmayın.
• phpinfo() ile gerçekten hangi ayarın aktif olduğunu kontrol edin; bazen global php.ini yerine .user.ini veya panel bazlı ayar geçerli olabilir.
• Önemli değişikliklerden sonra hata loglarını ve sunucu kaynak kullanımını (RAM, CPU, I/O) en az birkaç gün izleyin.
• Mümkünse önce bir staging ortamında deneyip sonra canlıya alın. Paylaşımlı hostingte bile alt alan adı + klon site ile küçük bir staging mimarisi kurmak mümkün; bunun için WordPress staging ortamı rehberimiz iyi bir yol gösterici olacaktır.

Sonuç ve DCHost Üzerinde Sağlam php.ini Stratejisi

WordPress ve Laravel projelerinde memory_limit, max_execution_time ve upload_max_filesize ayarlarını ezbere değil, projenin gerçek ihtiyaçlarına, sunucunun toplam kaynaklarına ve kullanılan mimariye göre belirlemek gerekir. Çok düşük değerler anlamsız hatalara, çok yüksek değerler ise tüm sunucuyu çökerten kaynak tüketimine yol açabilir.

Bu yazıda paylaştığımız sayılar, DCHost üzerindeki yüzlerce WordPress, WooCommerce ve Laravel kurulumundan süzülmüş gerçekçi başlangıç aralıkları. En iyi sonucu almak için bunları:

• Doğru boyutlandırılmış bir DCHost paylaşımlı hosting, VPS veya dedicated paketiyle,
• PHP-FPM, OPcache, veritabanı tuning ve önbellekleme ayarlarıyla birlikte,
• Düzenli log ve kaynak kullanımı izlemesiyle

beraber düşünmelisiniz. Altyapınızı DCHost üzerinde kuruyor veya taşıyorsanız, projenizin trafiğini, teknoloji yığınını (WordPress/Laravel, veritabanı, cache, queue) ve büyüme planlarını bizimle paylaşırsanız; hem doğru sunucu tipini hem de mantıklı php.ini başlangıç değerlerini birlikte netleştirebiliriz.

Yeni bir proje planlarken ya da mevcut WordPress/Laravel altyapınızı DCHost’a taşırken, php.ini ayarlarını sadece “hata kaybolsun” diye değil, uzun vadeli ölçeklenebilirlik ve performans perspektifiyle ele almak, sizi ileride yaşanacak pek çok sorundan kurtaracaktır.