WooCommerce ve Büyük WordPress Siteleri İçin Disk, IOPS ve inode Planlama Rehberi

WooCommerce veya büyük bir WordPress sitesi işletiyorsanız, çoğu kapasite planlama tartışmasının CPU ve RAM etrafında döndüğünü fark etmişsinizdir. Oysa pratikte performansı öldüren, sepet adımlarında takılmalara ve 500 hatalarına yol açan asıl katman çoğu zaman disk, IOPS ve inode tarafıdır. DCHost ekibi olarak yeni bir e‑ticaret projesi planlama toplantısına girdiğimizde artık refleks olarak sadece “kaç vCPU, kaç GB RAM?” diye sormuyoruz; “dakikada kaç sipariş bekleniyor, kaç ürün görseli var, dakikada kaç log kaydı üretiyorsunuz ve günlük yedek boyutları ne olacak?” diye soruyoruz. Çünkü bu sorular doğrudan disk kapasitesi, IOPS ihtiyacı ve inode tüketimiyle ilgilidir.

Bu rehberde, WooCommerce ve büyük WordPress sitelerinde disk tarafını baştan sona planlayabilmeniz için somut, sayılara dayalı bir yol haritası paylaşacağım. NVMe mi yeter, SATA SSD mi, kaç IOPS hedeflemelisiniz, inode limitine takılmamak için ne kadar pay bırakmalısınız, log ve cache klasörleri nasıl kontrol altında tutulur… Hepsini, gerçek senaryolar ve DCHost ortamlarında sık gördüğümüz örneklerle adım adım ele alacağız. Amacımız “rastgele yüksek kaynaklı bir paket” almak yerine, gerçekten ihtiyacınıza göre bilinçli bir mimari kurmanızı sağlamak.

Disk, IOPS ve inode Neden WooCommerce’de Bu Kadar Kritik?

WooCommerce, basit bir blog sitesinden farklı olarak yoğun disk erişimi yapan bir yapıdır. Her ziyaretçi için;

• Ürün listeleri ve detay sayfalarının yüklenmesi,
• Sepete ekleme, sepet görüntüleme, kupon hesaplama,
• Ödeme adımları, sipariş kaydı, stok güncellemesi,
• Log yazımı (PHP, access, error loglar),
• Cache dosyalarının oluşturulması veya temizlenmesi

gibi çok sayıda okuma ve yazma işlemi gerçekleşir. Bu da doğrudan IOPS (Input/Output Operations Per Second) ihtiyacını ve disk gecikmesini (latency) etkiler. Yani sadece “disk kapasitesi doldu mu?” sorusunu değil, “bu disk aynı anda gelen istekleri yeterince hızlı cevaplayabiliyor mu?” sorusunu da cevaplamanız gerekir.

inode tarafında ise tablo daha sinsi: Toplam disk alanınız boş görünürken, milyonlarca küçük dosya (cache, session, geçici dosyalar, log rotasyonları, yedekler) yüzünden inode limitine vurup siteyi tamamen kullanılamaz hale getirebilirsiniz. DCHost’ta özellikle paylaşımlı hosting ve giriş seviye VPS paketlerinde inode planlaması doğru yapılmadığında, sitenin “disk dolu” hatası vermesi ama aslında GB olarak hala boş alan olması sık gördüğümüz bir tablo.

Özetle: Kapasite planlaması = disk boyutu + IOPS + inode üçlüsünü birlikte düşünmek demektir. Bu üçü dengeli değilse, CPU ve RAM yüksek olsa bile WooCommerce mağazanız pratikte yavaş ve kırılgan kalır.

Temel Kavramlar: Disk Türleri, IOPS ve inode Nedir?

Disk türleri: NVMe, SATA SSD ve HDD

Önce disk türlerini netleştirelim, çünkü performans ve IOPS kapasitesi doğrudan buradan gelir:

• HDD (mekanik disk): Dönmekte olan plakalar üzerinde çalışan, mekanik okuma kafasına sahip disklerdir. Kapasite ucuzdur ama gecikme yüksektir, IOPS düşüktür. Modern WooCommerce siteleri için genellikle sadece yedek ve arşiv depolama amaçlı tercih edilir.
• SATA SSD: HDD’ye göre çok daha düşük gecikme ve daha yüksek IOPS sunar. Küçük ve orta ölçekli siteler için uzun yıllar standart oldu. Ancak günümüzde yüksek trafikli WooCommerce ve yoğun WordPress projelerinde NVMe’ye kıyasla sınırlayıcı hale gelmeye başladı.
• NVMe SSD: PCIe üzerinden haberleşen, çok daha yüksek IOPS ve düşük gecikme sunan disklerdir. Özellikle rastgele okuma/yazma yapan WooCommerce iş yükleri için farkı dramatiktir. DCHost’ta WooCommerce ve büyük WordPress projeleri için temel önerimiz NVMe altyapıdır.

Bu konuyu daha sayısal görmek isterseniz, ayrıntılı NVMe SSD, SATA SSD ve HDD karşılaştırması rehberimizi de mutlaka okumanızı öneririm.

IOPS nedir, WooCommerce’i nasıl etkiler?

IOPS, saniyede kaç okuma/yazma işlemi yapılabildiğini gösteren metriktir. Basitleştirirsek:

• Her sayfa açılışı = çok sayıda küçük okuma,
• Her sipariş = en az birkaç yazma işlemi (sipariş kaydı, stok güncelleme, log vb.),
• Her cache temizleme = büyük miktarda dosya silme/yazma.

IOPS yetmiyorsa neler görürsünüz?

• Sayfalar bazen çok hızlı, bazen anlamsız şekilde yavaş açılır (disk kuyruğu dolduğunda).
• Yoğun saatlerde sepet/ödeme adımları takılır, timeout ve 500 hataları artar.
• Veritabanı sorguları aslında optimize olsa bile disk bekleme süresi yüzünden yavaşlar.

Bu yüzden trafik artışı = sadece CPU yükü artışı demek değildir. Eş zamanlı ziyaretçi sayısı arttıkça, aynı anda yürüyen IO sayısı da artar, yani IOPS ihtiyacınız katlanır.

inode nedir, neden disk boyutundan daha önce bitebilir?

inode, Linux dosya sisteminde her dosya ve klasör için tutulan meta veri kaydıdır. Her dosya 1 inode tüketir (bazı özel durumlar hariç). Diskinizde teorik olarak 100 GB boş alan olsa bile, inode limitiniz dolmuşsa yeni dosya oluşturamazsınız ve sistem “disk dolu” hatası verir.

WooCommerce ve büyük WordPress sitelerinde inode tüketen başlıca kaynaklar:

• Cache klasörleri (sayfa cache, object cache dosyaları, minify edilmiş CSS/JS),
• PHP session dosyaları,
• Geçici upload ve thumbnail dosyaları,
• Eski tema ve eklenti dosyaları,
• Rotasyon yapılmamış veya temizlenmemiş log dosyaları.

Paylaşımlı hosting ortamlarında inode sınırı daha düşük olduğu için, özellikle WordPress sitelerinde inode temizliği kritik hale gelir. Bu konuyu detaylı ele aldığımız paylaşımlı hosting’de inode limitine takılmamak için uygulamalı temizlik rehberi yazımıza da göz atabilirsiniz.

WooCommerce İş Yükünü Anlamak: Hangi Dosyalar, Hangi IOPS’i Tüketir?

Doğru planlama için önce hangi bileşenin diski nasıl kullandığını anlamanız gerekir. WooCommerce’de başlıca disk tüketicileri şunlardır:

1) Çekirdek WordPress ve WooCommerce dosyaları

wp-admin, wp-includes, wp-content/plugins klasörlerinizdeki çekirdek ve eklenti dosyaları genellikle okuma ağırlıklıdır. Günlük IO tüketiminin önemli bir kısmı bu dosyalara sürekli yapılan okumalardan gelir. Bu yüzden disk gecikmesi düşük olan NVMe gibi diskler, CPU’dan önce bu okuma yükünü hafifletir.

2) Uploads klasörü (ürün görselleri, içerik medyası)

WooCommerce sitelerinde en hızlı şişen klasör wp-content/uploads klasörüdür. Her ürün için:

• Ana görsel,
• Galeri görselleri,
• Farklı çözünürlüklerde oluşturulan thumbnail’ler

birlikte düşünülmelidir. WordPress varsayılan olarak tek bir görselden birden fazla boyut üretir, tema ve eklentiler fazladan boyut ekleyebilir. Yani 1 görsel upload ettiğinizde disk üzerinde 8‑10 dosya oluşması olağandır. Bu da hem kapasiteyi hem de inode sayısını hızla yükseltir.

Orta ve büyük ölçekli projelerde görselleri doğrudan web sunucusu diski yerine harici nesne depolamaya taşıyan object storage ile medya offload stratejisi genellikle hem maliyet hem de performans açısından ciddi avantaj sağlar.

3) Cache klasörleri (sayfa, object cache, minify)

Cache performans için hayat kurtarıcıdır ama yanlış yapılandırılırsa inode kabusuna dönüşebilir. Örneğin:

• Her ziyaretçi için ayrı HTML cache dosyası oluşturan ayarlar,
• Her deploy’da yüzbinlerce minify CSS/JS dosyası bırakan eklentiler,
• Eskimeyen, TTL’i çok yüksek ayarlanmış cache dosyaları

kısa sürede yüzbinlerce hatta milyonlarca küçük dosya üretebilir. Doğru yapılandırılmış bir tam sayfa önbellek (Nginx microcache, LiteSpeed Cache vb.) ve periyodik cache temizliği ile hem IOPS yükünü hem de inode kullanımını kontrol altında tutabilirsiniz.

4) Log dosyaları (PHP, web sunucusu, WooCommerce logları)

Loglar, yaşanmış sorunları analiz etmek için vazgeçilmezdir ancak kontrol edilmezse hem disk alanını hem de inode’u sessizce bitirir. Özellikle:

• PHP hata logları (tekrarlayan uyarılar yüzünden GB’larca büyüyebilir),
• Access ve error loglar,
• WooCommerce’in kendi kayıt altına aldığı sipariş ve ödeme logları

için log rotasyonu (logrotate) ve saklama süresi mutlaka tanımlanmalıdır. Bu konuyu pratik açıdan ele aldığımız VPS disk kullanımı ve logrotate ayarlarıyla “No Space Left on Device” hatasını önleme rehberi log tarafındaki riskleri iyi özetliyor.

5) Veritabanı dosyaları (MySQL/MariaDB InnoDB tabloları)

Veritabanı dosyaları genellikle tekil olarak büyük dosyalardır; inode değil, daha çok kapasite ve IOPS tarafını etkilerler. WooCommerce’de ürün, stok, sipariş ve sepet verileri veritabanında tutulduğu için, yüksek sipariş hacmi olan sitelerde veritabanı diski için ekstra IOPS ve mümkünse ayrı disk havuzu (ayrı NVMe) planlamak doğru olur.

Disk Kapasitesi Planlama: Ürün, Görsel ve Log’lardan Gerçekçi Hesaplar

Disk planlamasında en sık gördüğümüz hata, sadece “şu anki site boyutu”na bakmak ve %20‑30 pay bırakmaktır. Oysa WooCommerce siteleri dinamik büyür: yeni ürünler, kampanya görselleri, loglar, yedekler, cache dosyaları… Hepsi zamanla siteyi katlar.

Adım 1: Mevcut boyutu ve dosya dağılımını analiz edin

Önce mevcut durumu kabaca görün:

• wp-content/uploads boyutu,
• wp-content/plugins ve themes boyutu,
• wp-content/cache ve benzeri cache klasörleri,
• mysql veya mariadb veri dizini (çoğunlukla /var/lib/mysql),
• log klasörleri (ör. /var/log, home altındaki error_log’lar).

Bu dağılım, hangi klasörün ne kadar hızlı büyüdüğünü görmek için referans noktanız olacak.

Adım 2: Ürün ve görsel bazlı büyüme tahmini

Basit bir model kurabiliriz:

• Ortalama ürün görseli boyutu: 250 KB (optimize edilmiş JPEG/WebP varsayıyoruz).
• WordPress’in ürettiği boyut sayısı: 8 (tema ve eklentilere bağlı olarak değişir).

Bu durumda tek ürün için ortalama disk tüketimi:

250 KB × 8 = 2 MB / ürün

Eğer her üründe ortalama 3 görsel varsa:

2 MB × 3 = 6 MB / ürün

1000 ürünlü bir mağaza için kabaca:

1000 × 6 MB = 6 GB sadece görseller

Buna videolar, blog yazıları için kullanılan görseller, banner’lar vb. eklenince rahatlıkla %30-50 fazlasını düşünmek gerekir. Yani 1000 ürünlü bir mağaza için en az 10 GB sadece uploads klasörü için makul başlangıçtır.

Adım 3: Log ve yedek büyümesini hesaba katın

Loglar ve yedekler genellikle gözden kaçan ama diski patlatan kısımdır:

• Ortalama günlük access + error log: 100‑500 MB (trafiğe göre artar),
• PHP hata logları: Hatalı bir eklenti ile bir günde 1‑2 GB’a sıçrayabilir,
• Günlük tam yedek boyutu: Canlı sitenin toplam boyutuna yakın (örneğin 15‑20 GB).

Haftalık 7 yedek tuttuğunuzu düşünürsek, sadece yedekler 140 GB’a çıkabilir. Bu yüzden genellikle şu stratejiyi öneriyoruz:

• Canlı sunucuda sadece 1‑2 günlük yedek tutmak,
• Eski yedekleri harici object storage veya yedek sunucusuna taşımak,
• Loglar için sıkı logrotate ve saklama süresi tanımlamak.

Yedekleme tarafında geniş perspektifi görmek için NVMe, SATA ve object storage’ı birlikte kullanan sıcak‑soğuk‑arşiv yedek stratejisi rehberi iyi bir tamamlayıcı okuma olacaktır.

Örnek kapasite senaryoları

Aşağıda kabaca disk kapasitesi tahmin tablosu düşünebiliriz (canlı sunucu tarafı için):

• Küçük WooCommerce (500 ürün, az görsel): 20‑30 GB NVMe disk (yine de harici yedek önerilir)
• Orta ölçek (2.000‑5.000 ürün, her üründe 3‑5 görsel): 80‑160 GB NVMe disk (görseller için object storage ciddi rahatlatır)
• Büyük katalog (10.000+ ürün, zengin görsel içerik): 200 GB+ NVMe disk + görseller için object storage ve ayrı yedek alanı

Bunlar temkinli başlangıç değerleridir. Gerçek ihtiyaç, optimizasyon düzeyine (görsel sıkıştırma, CDN kullanımı, log yönetimi vb.) göre aşağı veya yukarı oynar.

IOPS Planlama: Trafiğe Göre Okuma/Yazma Yükünü Tahmin Etmek

Disk kapasitesi yetse bile IOPS yetmezse kullanıcıya yansıyan sonuç aynıdır: Yavaş site, timeout’lar ve zaman zaman 500 hataları. Bu nedenle özellikle WooCommerce’de IOPS’i ayrı düşünmek zorundasınız.

IOPS’i kabaca tahmin etmenin basit modeli

Kaba bir pratik kural koyabiliriz:

• 1 sayfa görüntüleme (ürün veya liste) için ortalama 10‑30 IO işlemi,
• 1 sepet/checkout işlemi için 30‑100 IO işlemi (veritabanı yazmaları dahil).

Diyelim ki:

• Yoğun saatte 500 ziyaretçiniz var,
• Bu ziyaretçiler toplamda 2.000 sayfa görüntülemesi yapıyor,
• Saatte 50 sipariş alıyorsunuz.

Kaba hesap:

• Sayfa görüntülemeleri: 2.000 × 20 IO = 40.000 IO
• Siparişler: 50 × 60 IO = 3.000 IO

Toplamda saatte ~43.000 IO, saniyeye bölersek:

43.000 / 3.600 ≈ 12 IOPS

Bu rakam çok düşük görünebilir ama bu sadece kaba teorik değer. İşin içine cache verimliliği, veritabanı optimizasyonu, paralel çalışan cron görevleri ve arka plan işlemleri girince gerçek ihtiyaç bunu 3‑5 katına rahatlıkla çıkabilir. Ayrıca kritik olan, sadece ortalama IOPS değil, pik anlarda disk kuyruğuna girip girmediğinizdir.

Bu nedenle WooCommerce için DCHost üzerinde plan yaparken genellikle şu yaklaşımı benimsiyoruz:

• Küçük trafik: NVMe disk üzerinde 1.000‑2.000 IOPS sağlayabilen altyapı,
• Orta trafik: 3.000‑5.000 IOPS seviyesinde rezerv,
• Yüksek trafik: 5.000+ IOPS sağlayabilen NVMe ve mümkünse veritabanı için ayrı disk havuzu.

Daha genel kapasite planı için hazırladığımız WooCommerce kapasite planlama rehberi (vCPU, RAM, IOPS hesaplama) yazısında CPU/RAM ile IOPS’i birlikte ele alıyoruz.

IOPS’i ölçmek ve takip etmek

Plan kadar önemli olan bir diğer konu da gerçek IOPS kullanımını izlemek. DCHost üzerinde VPS veya dedicated sunucu kullanıyorsanız:

• iotop ile anlık IO yoğun süreçleri görebilir,
• iostat ile disk başına IOPS ve bekleme sürelerini inceleyebilir,
• Netdata, Prometheus + Grafana gibi araçlarla uzun dönemli grafikleri takip edebilirsiniz.

Bu konuda adım adım örnek komutlar ve dashboard önerileri görmek isterseniz, VPS kaynak kullanımı izleme rehberi tam olarak bu amaca yönelik hazırlandı.

inode Planlama ve Temizlik Stratejileri

inode, “disk GB olarak dolmadan içten içe biten görünmez kota” gibi düşünülebilir. Özellikle cache ve log yoğun WooCommerce sitelerinde inode tüketimi çok hızlı artar.

inode tüketimini artıran tipik kaynaklar

• Cache klasörleri: Her URL için ayrı cache dosyası; kullanıcıya özel cache (örneğin üyelik bazlı sayfa varyantları).
• Session ve geçici dosyalar: Kampanya dönemlerinde artan giriş trafiği ile birlikte yüzbinlerce session dosyası.
• Thumbnail patlaması: Aşırı fazla görsel boyutu üreten tema ve eklentiler.
• Eski sürümler: Kullanılmayan eski tema ve eklenti klasörleri.
• Eksik log rotasyonu: Her gün yeni log dosyası açıp eski dosyaları hiç silmeyen yapılandırmalar.

inode için sayısal planlama

Kaba bir plan yaparken şu yaklaşımı kullanıyoruz:

• Ürün başına ortalama 10‑20 dosya (görseller ve thumbnail’ler),
• Cache yapısına göre 10.000 ziyaretçi için 50.000‑200.000 arası cache dosyası (agresif ayarlarda),
• Günlük log rotasyonu ile log başına 1 dosya/gün, saklama süresine göre çarpan (ör. 90 gün).

Örneğin:

• 5.000 ürün × 15 dosya ≈ 75.000 inode (sadece görseller),
• Cache yapısına bağlı olarak 200.000‑500.000 inode,
• Log ve diğer dosyalarla birlikte rahatlıkla 1 milyon inode seviyelerine çıkabilirsiniz.

Bu yüzden büyük WooCommerce projelerinde en az 1‑2 milyon inode sınırı planlamak, hatta büyümeyi düşünerek daha yüksek inode sunan VPS veya dedicated sunucu tercih etmek iyi bir fikirdir.

inode temizliği ve sürdürülebilirlik

Plan kadar önemli olan bir diğer konu da düzenli temizlik rutinleri kurmaktır:

• Cache eklentilerinde TTL ve otomatik purge ayarlarını disiplinli tutmak,
• Eski tema ve eklentileri sunucudan tamamen kaldırmak,
• Gereksiz thumbnail boyutlarını kapatmak veya azaltmak,
• PHP session klasörünü düzenli temizlemek (cron ile),
• Loglar için logrotate ve maksimum saklama süresi tanımlamak.

Paylaşımlı hosting ortamlarında inode ile nasıl pratik mücadele edileceğini adım adım gösteren inode temizlik rehberi, burada anlattıklarımızı çok somut komut ve görsellerle destekliyor.

WooCommerce İçin Doğru Disk Mimarisi: Paylaşımlı, NVMe VPS, Dedicated ve Object Storage

DCHost üzerinde WooCommerce ve büyük WordPress projeleri için çalışırken disk mimarisini genellikle üç katmanda düşünüyoruz:

• Sıcak depolama (hot storage): Uygulama dosyaları ve veritabanı için hızlı NVMe diskler,
• Sıcak/ılık depolama: Daha az kritik ama yine de hızlı olması gereken loglar, geçici dosyalar, bazı yedekler,
• Soğuk depolama: Eski yedekler, arşiv loglar, düşük erişimli medya.

Paylaşımlı hosting mi, NVMe VPS mi?

Küçük WooCommerce mağazaları başlangıçta iyi yapılandırılmış paylaşımlı hosting planlarında sağlıklı çalışabilir. Ancak:

• Ürün sayısı ve trafik arttıkça,
• Özellikle kampanya dönemlerinde ani IOPS patlamaları yaşandıkça,
• inode ve log limitlerine daha sık takıldıkça

NVMe diskli bir VPS’e geçmek genellikle kaçınılmaz olur. Bu geçişi kesintisiz yapmak için hazırladığımız paylaşımlı hosting’den VPS’e sorunsuz geçiş rehberi geçiş süreçlerinde sıkça referans aldığımız bir kaynak.

Object storage ile medya ve yedekleri ayırmak

Orta ve büyük ölçekli WooCommerce projelerinde en büyük disk tüketimini görseller ve yedekler yapar. Bu yüzden tipik olarak şu mimariyi öneriyoruz:

• WooCommerce uygulaması + veritabanı: DCHost üzerinde NVMe diskli VPS veya dedicated sunucu,
• Ürün görselleri ve medya: DCHost’un sunduğu S3 uyumlu object storage benzeri çözümler üzerinde,
• Eski yedekler: Ayrı bir yedek sunucusu veya object storage üzerinde saklanır.

WordPress medyasını S3 uyumlu depolamaya taşımanın pratik adımlarını, CDN ve imzalı URL’lerle entegrasyonunu WordPress medyanı S3’e taşıma rehberimizde detaylandırdık. WooCommerce için de aynı yaklaşım geçerlidir: Uygulama diskinizi hafifletir, IOPS’i uygulama sorgularına bırakır, disk maliyetini öngörülebilir hale getirir.

Veritabanı için ayrı disk veya ayrı sunucu ne zaman mantıklı?

Belli bir ölçeğin üzerinde WooCommerce sitelerinde veritabanı IO yükü toplam IO’nun ciddi bir kısmını üstlenir. Şu sinyaller varsa:

• Disk bekleme süresi (await) yüksek,
• Yoğun sorgularda MySQL “disk bound” hale geliyor,
• Uygulama dosyaları ve veritabanı aynı disk üzerinde IO için yarışıyor.

o zaman veritabanını ayrı bir NVMe diske veya ayrı bir sunucuya almak performansı ciddi iyileştirir. Bu kararı vermek için hazırladığımız WooCommerce için ayrı veritabanı ve önbellek sunucusu ne zaman mantıklı? rehberindeki işaret listesi karar sürecinde işe yarayacaktır.

İzleme, Uyarı ve Bakım: Sorun Çıkmadan Önce Haberiniz Olsun

İyi bir disk/IOPS/inode planı yaptınız, doğru mimariyi kurdunuz. Bundan sonra en kritik adım izleme ve bakımtır. Çünkü trafik ve veri büyümesi durmaz; sadece hızlanır veya yavaşlar.

İzlemeniz gereken temel metrikler

• Disk kullanım yüzdesi: %80 üstünü sürekli olarak görmek, yakın gelecekte alarm demektir.
• inode kullanım yüzdesi: %70 üstüne çıktığınızda temizlik ve ölçekleme planını netleştirmeniz gerekir.
• IOPS ve bekleme süresi: Yük altında disk kuyruğu oluşuyor mu, bekleme süreleri tırmanıyor mu?
• Log büyüme hızı: Özellikle hata logları beklenmedik şekilde büyüyorsa, arkada çözülememiş bir problem var demektir.

Otomatik uyarı ve rutinler

DCHost üzerinde VPS veya dedicated sunucu kullanırken genellikle şu rutinleri kurmanızı tavsiye ediyoruz:

• Disk ve inode kullanımı belirli eşikleri geçtiğinde (ör. %80) e‑posta veya webhook ile uyarı,
• Log klasörleri için düzenli logrotate ve maksimum saklama süresi,
• Cache ve geçici dosyalar için belirli aralıklarla çalışan cron temizlik görevleri,
• Yedeklerin düzenli olarak harici depolamaya taşınması ve geri yükleme testleri.

Genel cron güvenliği ve planlama için Linux crontab en iyi uygulamalar rehberi ve log yönetimi için sunucu loglarını okuma rehberi iyi tamamlayıcı kaynaklar.

DCHost Üzerinde Örnek Planlama Senaryoları

Teori kadar pratik görmek de önemli. DCHost ortamında sık gördüğümüz üç tip WooCommerce/WordPress senaryosunu kabaca şöyle özetleyebiliriz:

Senaryo 1: Küçük butik WooCommerce mağazası

• 500’e kadar ürün,
• Aylık 20‑30 bin sayfa görüntülemesi,
• Günlük 20‑50 sipariş.

Önerilen disk ve inode yaklaşımı:

• NVMe diskli giriş seviye VPS veya performans odaklı paylaşımlı hosting planı,
• En az 20‑30 GB disk alanı,
• En az 500‑700 bin inode,
• Haftalık 1 tam yedek, günlük veritabanı yedeği (mümkünse harici depolamaya da akıtılmalı).

Senaryo 2: Orta ölçekli WooCommerce + içerik blogu

• 2.000‑5.000 ürün,
• Yoğun görsel kullanılan blog yazıları,
• Aylık 200‑500 bin sayfa görüntülemesi,
• Günlük 200‑500 sipariş.

Önerilen yaklaşım:

• NVMe diskli orta seviye VPS (gerekirse veritabanı ve dosya sistemi için ayrı NVMe havuzları),
• Canlı sunucuda en az 80‑160 GB NVMe disk,
• 1‑2 milyon inode sınırı,
• Ürün görselleri ve büyük medya için object storage entegrasyonu,
• Günlük otomatik yedek + harici depolama, logrotate ve cache temizlik cron’ları.

Senaryo 3: Büyük kampanya siteleri, marketplace yapılar

• 10.000+ ürün, çok sayıda varyasyon,
• Aylık milyonlarca sayfa görüntülemesi,
• Kampanya dönemlerinde dakikada onlarca sipariş.

Burada artık klasik tek sunucu yerine ayrıştırılmış mimari konuşuyoruz:

• Uygulama sunucuları (1+ NVMe VPS veya dedicated),
• Veritabanı için ayrı NVMe diskli sunucu,
• Redis/Memcached object cache sunucusu,
• Medya ve yedekler için object storage + yedek sunucusu.

Disk tarafında:

• Toplamda yüzlerce GB NVMe disk kapasitesi,
• IOPS tarafında 5.000+ seviyelerini hedefleyen tasarım,
• En az 5‑10 milyon inode kapasitesi,
• Sıkı izleme, alarmlar ve periyodik kapasite gözden geçirme toplantıları.

Böyle projelerde DCHost tarafında genellikle müşteriyle birlikte detaylı bir kapasite planlama çalışması yapıyor, trafik simülasyonları (load test), veritabanı indeksleme ve sorgu optimizasyonu ile disk ve IOPS ihtiyacını netleştiriyoruz.

Sonuç ve Yol Haritanız

WooCommerce ve büyük WordPress projelerinde gerçek performans, sadece güçlü bir CPU veya bol RAM ile gelmiyor. Disk türü (NVMe/SATA), IOPS kapasitesi ve inode sınırları birlikte planlanmadığında, en kritik anda sepet/ödeme adımlarınızın yavaşladığına, logların veya cache klasörlerinin diski gizlice doldurduğuna, inode limitine çarpıp sitenin tamamen kilitlendiğine şahit olabilirsiniz. DCHost olarak sahada gördüğümüz pek çok performans sorununu incelediğimizde, kök nedenin büyük kısmı disk, IOPS ve inode planlamasındaki eksiklikler oluyor.

İyi haber şu: Bu sorunlar, baştan doğru soruları sorup somut hesaplar yaparak büyük oranda önlenebilir. Ürün sayınızı, beklenen trafiği, görsel kullanımınızı, log ve yedek stratejinizi masaya yatırıp; disk kapasitesi, IOPS hedefi ve inode sınırlarını buna göre belirlerseniz, WooCommerce mağazanız uzun yıllar sağlıklı şekilde büyüyebilir. Disk tarafını projenizin omurgası gibi düşünün; üzerine inşa ettiğiniz her şeyin güvenle ayakta kalması buna bağlı.

Eğer mevcut sitenizde disk veya IOPS kaynaklı sorunlardan şüpheleniyorsanız ya da yeni bir WooCommerce projesi planlıyorsanız, DCHost ekibi olarak kapasite planlama, mimari tasarım ve taşıma süreçlerinde yanınızdayız. Mevcut loglarınızı, trafik istatistiklerinizi ve büyüme hedeflerinizi birlikte analiz ederek; size özel disk, IOPS ve inode planı çıkarabilir, doğru NVMe VPS, dedicated sunucu veya colocation altyapısını birlikte kurgulayabiliriz. Böylece sunucu tarafını güvenle bize bırakıp, siz işinizi büyütmeye odaklanabilirsiniz.