cPanel reseller paketlerinde limit tasarımı neden bu kadar önemli?

{
“title”: “cPanel Reseller Paket Tasarımı: CPU, inode, Disk ve E‑Posta Limitlerini Doğru Kurgulamak”,
“content”: “n

cPanel reseller kullanırken teknik olarak elinizde kısıtlı ama paylaşılabilir bir kaynak havuzu var: CPU, RAM, disk, inode, IO, e‑posta kapasitesi… Bu havuzu doğru bölüştürmediğinizde iki uç sorunla karşılaşırsınız: Ya agresif limitler yüzünden müşteriler sürekli kısıtlamaya takılır, ya da aşırı esnek davranıp birkaç sitenin tüm sunucuyu kilitlemesine izin verirsiniz. Her ikisi de hem markanıza hem de kârlılığınıza zarar verir.

n

DCHost tarafında reseller altyapılarını tasarlarken en çok zaman harcadığımız konulardan biri, bu kaynakların adil, öngörülebilir ve ölçeklenebilir şekilde dağıtılması. Özellikle ajanslar ve freelancer’lar için, bir WordPress vitrini ile WooCommerce mağazasının aynı limitle çalışamayacağını biliyoruz. Bu yazıda, cPanel reseller paket tasarımında CPU, inode, disk ve e‑posta limitlerini nasıl planlamanız gerektiğini; gerçekçi senaryolar, basit hesaplar ve pratik tavsiyelerle detaylı şekilde ele alacağız.

n

Yazının odağı teknik ama dilini mümkün olduğunca sade tutacağım. cPanel üzerindeki kaynak metriklerine aşina değilseniz, önce cPanel kaynak limitlerini doğru okuma rehberine göz atmanız, burada anlatacaklarımızı çok daha hızlı sindirmenizi sağlar.

nn

Reseller dünyasında gerçekten önemli olan kaynaklar

n

cPanel reseller tarafında konuştuğumuz tüm limitleri kabaca dört gruba ayırabiliriz:

n

n
• CPU ve süreç limitleri (Entry Processes, RAM, IO)

n

• Disk alanı ve inode (dosya sayısı)

n

• E‑posta limitleri (hesap kotası, saatlik/günlük gönderim limiti)

n

• Bant genişliği / trafik (bu yazıda ikincil odakta tutacağız)

n

n

RAM, IO ve trafik de önemli olsa da, reseller paket tasarımında pratikte en çok başınızın ağrıdığı yerler CPU, inode, disk alanı ve e‑posta oluyor. Çünkü:

n

n
• CPU patladığında siteler yavaşlıyor veya 508/503 hataları başlıyor.

n

• inode limitine gelindiğinde site dosya yükleyemiyor, eklenti güncelleyemiyor.

n

• Disk alanı dolduğunda çoğu zaman önce e‑postalar gönderilemez/alamaz hale geliyor.

n

• E‑posta limiti yanlış kurgulandığında da spam şikâyetleri ve IP itibarı hızla bozuluyor.

n

n

DCHost’ta reseller altyapılarını planlarken bu dört alan için ayrı ayrı politika belirleyip, daha sonra da ajans/bayi profiline göre hazır paket şablonları çıkarıyoruz. Siz de benzer bir yaklaşımı kendi müşterilerinize sunabilirsiniz.

nn

Temel ilkeler: adalet, öngörülebilirlik, ölçeklenebilirlik

n

Limitleri tek tek konuşmadan önce, iyi tasarlanmış bir cPanel reseller paketinin üç temel özelliğini netleştirelim:

n

n
• Adalet: Birkaç yüksek trafikli site, geride kalan 20 küçük vitrinin performansını öldürememeli.

n

• Öngörülebilirlik: Müşteri, hangi pakette ne yapabileceğini tahmin edebilmeli. “Bazen çalışıyor, bazen kısıtlıyor” hissi en tehlikelisidir.

n

• Ölçeklenebilirlik: Paket modeli; 10 site ile başladığınızda da, 100 siteye çıktığınızda da mantıklı kalmalı.

n

n

Bu ilkeleri sağlayabilmek için DCHost tarafında şu prensipleri uyguluyoruz:

n

n
• Her pakete mutlaka bir maksimum hesap sayısı tanımlıyoruz (örneğin 30 cPanel hesabına kadar).

n

• Her cPanel hesabına minimum CPU payı ve minimum disk/inode limiti veriyoruz.

n

• Ajanslarda kritik projeleri u201cPremiumu201d pakete almayı teşvik ediyor, limitleri buna göre segmentliyoruz.

n

• Kritik müşteriler için gerektiğinde reseller’dan bir üst seviye olan VPS tabanlı ajans mimarisine geçiş yolunu açık tutuyoruz.

n

nn

CPU ve süreç (Entry Processes) limitlerini tasarlamak

n

CPU, pratikte müşteri memnuniyetini en çok etkileyen metrik. Özellikle WordPress, WooCommerce, Laravel gibi PHP tabanlı sitelerde, CPU ve eşzamanlı süreç sayısı (Entry Processes) doğru ayarlanmazsa şu şikâyetler başlıyor:

n

n
• u201cGün içinde belli saatlerde site çok yavaşlıyor.u201d

n

• u201cAdmin paneli sürekli zaman aşımına düşüyor.u201d

n

• u201cHosting panelinde CPU %100 görünüyor ama neyin tükettiğini anlayamıyorum.u201d

n

n

Bu semptomlarla karşılaşıyorsanız, detaylı teşhis için CPU ve MySQL darboğazı teşhis rehberine mutlaka göz atın. Reseller paket tasarımı yaparken kullanabileceğiniz pratik bir çerçeve oluşturalım.

nn

1) Toplam CPU havuzunuzu bilin

n

Örnek bir senaryo üzerinden gidelim. Diyelim ki DCHost üzerinde şu özelliklerde bir reseller planı kullanıyorsunuz:

n

n
• Toplam: 4 vCPU (paylaşımlı ama garanti alt sınırlar tanımlanmış)

n

• Toplam RAM: 8 GB

n

• CloudLinux LVE ile her cPanel hesabına ayrı limit verilebiliyor

n

n

Bu durumda hiçbir zaman tüm hesaplara birden 4 vCPU vaat etmemelisiniz. Onun yerine şu mantığı kullanabilirsiniz:

n

n
• Her hesap için minimum 0.5 vCPU

n

• Yoğun siteler için 1 vCPUu2019ya kadar çıkabilen u201cpremiumu201d paket

n

• Toplamda 4 vCPUu2019yu aşmayacak şekilde, hesap başına CPU limitlerini paylaştırmak

n

n

Örneğin 20 hesaplık bir reseller portföyünde:

n

n
• 15 küçük site: 0.25 vCPU (toplam 3.75 vCPUu2019ya kadar eşzamanlı tavan)

n

• 5 orta/yoğun site: 0.75 vCPU (teorik üst sınır 3.75 vCPU)

n

n

Gerçekte tüm siteler aynı anda tepeye vurmadığı için bu, sürdürülebilir bir oversell oranıdır. Ancak kritik nokta, premium gördüğünüz sitelere gerçekten daha fazla CPU tanımlamaktır; herkese u201csınırsızu201d diyerek sorunu ötelemek değil.

nn

2) Entry Processes (EP) sınırlarını doğru ayarlayın

n

Entry Processes, aynı anda sunucuya gelen PHP/CGI istek sayısının sınırıdır. Çok düşük ayarlarsanız, kampanya döneminde siteler 508 hatası vermeye başlar; çok yüksek ayarlarsanız da bir iki müşterinin u201cpatlama anıu201d tüm sunucuyu kilitler.

n

DCHost tarafında genel yaklaşımımız şöyle:

n

n
• Küçük vitrin sitesi: 10–15 EP

n

• Kurumsal/orta seviye WordPress: 20–30 EP

n

• Küçük WooCommerce mağazası: 30–40 EP

n

n

Reseller paket şablonlarınızı da buna göre segmentleyebilirsiniz:

n

n
• Starter paket: 0.25 vCPU, 512–768 MB RAM, 15 EP

n

• Business paket: 0.5 vCPU, 1 GB RAM, 25 EP

n

• Pro/E‑ticaret paket: 1 vCPU, 2 GB RAM, 40 EP

n

n

Bu sınırlar, özellikle WordPress ağırlıklı reseller portföylerinde oldukça sağlıklı çalışıyor. CPU/EP tarafını daha derin anlamak isterseniz, cPanel kaynak limitleri ve “Resource Limit Reached” yazımızdaki grafiklere mutlaka bakın.

nn

Disk alanı ve inode limitlerini dengelemek

n

Disk alanını herkes konuşur ama inode (dosya sayısı) çoğu zaman gözden kaçırılır. Oysa çok sayıda küçük dosyadan oluşan bir site, diskte görece az yer kaplasa bile inode limitine çok hızlı vurabilir.

n

inode kabaca u201ckaç adet dosya ve klasörünüz var?u201d sorusunun cevabıdır. WordPress çekirdeği + eklentiler + temalar + cache dosyaları derken, tek bir sitede 80–120 bin inode görmek hiç şaşırtıcı değildir. Üzerine bir de e‑posta klasörleri eklenince, sınırlar hızla dolmaya başlar.

nn

1) inode sınırlarını paketlere göre bölmek

n

Örnek olarak 1 milyon inode havuzuna sahip bir reseller düşünelim. Bunu dağıtırken şu modeli kullanabilirsiniz:

n

n
• Starter paket: 50.000 inode

n

• Business paket: 100.000 inode

n

• Pro paket: 200.000 inode

n

n

20 müşterinizin 10u2019u Starter, 7u2019si Business, 3u2019ü Pro olsa teorik üst sınır 1.6 milyon inode olur; ancak hepsi sınırına vurmaz. Yine de özellikle yedek dizinleri, eski staging kopyaları ve gereksiz cache klasörleri sebebiyle inode şişmesinin çok yaygın olduğunu unutmayın.

n

Müşterilerinizi eğitmek için onlara inode limitine takılmamak için uygulamalı temizlik rehberimizi göndermek, destek yükünüzü ciddi anlamda azaltacaktır.

nn

2) Disk alanı planlaması: kârlılık vs. rahatlık

n

Disk tarafında iki parametreyi aynı anda düşünmelisiniz:

n

n
• TB başına maliyetiniz (NVMe/SATA, replikasyon, yedekleme politikaları)

n

• Müşterilerin tipik kullanım alışkanlıkları (WordPress + mail, e‑ticaret, dosya paylaşımı vb.)

n

n

DCHost tarafında gözlemimiz şu yönde:

n

n
• Sadece web sitesi (vitrin, blog): 1–3 GB arası rahat yeter.

n

• Web sitesi + hafif e‑posta kullanımı: 5–10 GB arası.

n

• WooCommerce / katalog + düzenli e‑posta: 10–20 GB arası.

n

n

Bu verilerle birlikte, reseller paketlerinizi şöyle tasarlayabilirsiniz:

n

n
• Starter: 2–3 GB disk, 50.000 inode

n

• Business: 5–10 GB disk, 100.000 inode

n

• Pro: 15–25 GB disk, 200.000 inode

n

n

Özellikle WooCommerce ve büyük medya arşivli sitelerde, daha yayımlamadan önce disk/içerik beklentisini konuşup disk ve inode planlama rehberimizdeki tablolara göre yol çizmek, sizi sonradan yaşanacak tatsız sürprizlerden korur.

nn

3) E‑posta disk kullanımını unutmayın

n

Gerçekte disk tüketiminin önemli kısmını bazen web sitesi değil, e‑postalar yapar. 10–15 kişilik bir şirket, arşiv temizliği yapılmadığında rahatlıkla 20–30 GB e‑posta kotasını doldurabilir. Bu nedenle:

n

n
• Web sitesi disk kotası ile e‑posta kotasını aynı havuzdan yediğini müşteriye iyi anlatın.

n

• cPanel içinde mail kotası uyarılarını aktif edin.

n

• Müşterilerinize düzenli arşiv/temizlik için cPanel e‑posta alanı yönetimi rehberimizi gönderin.

n

nn

E‑posta limitleri: kota, saatlik gönderim ve spam riski

n

Reseller paketlerinde en hassas konu genelde e‑postadır. Çünkü:

n

n
• Spam yapan tek bir müşteri, tüm IP itibarınızı riske atabilir.

n

• Yetersiz limitler ise bülten gönderen müşterilerinizi mutsuz eder.

n

n

DCHost tarafında izlediğimiz yaklaşımı biraz basitleştirerek paylaşayım; siz onu kendi iş modelinize göre daraltıp/genişletebilirsiniz.

nn

1) Saatlik gönderim limitleri

n

cPanel/Exim tarafında hesap bazlı saatlik gönderim limiti tanımlamak, spam riskini ciddi ölçüde azaltır. Öneri aralıklar:

n

n
• Standart kurumsal site: 100–200 mail/saat

n

• Küçük bülten gönderen müşteri: 300–500 mail/saat

n

• Yoğun pazarlama yapan, liste onaylı müşteri: 800–1000 mail/saat (mümkünse ayrı IP veya ayrı altyapı)

n

n

Reseller paketlerinde u201cStarteru201d müşterilere 100–200, u201cBusinessu201d müşterilere 300–500, u201cProu201d müşterilere 800 civarı üst sınır tanımlamak, hem IP itibarını korur hem de iş yapan müşterilerin elini kolunu bağlamaz.

nn

2) Mail kutusu başına kota planı

n

Mail hesabı başına kota verirken, web disk havuzunuzla çarpışmayacak mantıklı rakamlar seçin:

n

n
• Küçük ekipler: Kişi başı 1–2 GB

n

• Orta boy şirket: Kişi başı 2–5 GB

n

• Ağır arşivci müşteriler: 10 GB ve üzeri (veya harici arşiv çözümleri)

n

n

Burada kilit nokta, kalabalık ekipli müşterileri Pro pakete taşımak. 50 kişilik bir ekibin her birine 5 GB verdiğinizde, tek müşteri 250 GB tüketecektir; bu genellikle reseller mimarisinin üstüne çıkar ve ayrı çözümleri (VPS, dedicated, ayrı e‑posta altyapısı) konuşmak gerekir.

nn

3) Spam ve teslim edilebilirlik tarafını unutmayın

n

Limit tasarımı sadece rakamlardan ibaret değil. SPF, DKIM, DMARC, rDNS gibi kayıtların doğru kurulması, spam riskini azaltır ve teslim edilebilirliği artırır. Bu konuda adım adım bir kurulum yapmak isterseniz, SPF, DKIM ve DMARC rehberimizi temel check‑list olarak kullanabilirsiniz.

nn

Örnek senaryolar: küçük ajans, büyüyen bayi ve kaynak dağıtımı

n

Teoriyi biraz somutlaştıralım. DCHost üzerinde aşağıdaki gibi bir reseller altyapınız olduğunu varsayalım:

n

n
• 4 vCPU, 8 GB RAM

n

• 200 GB NVMe disk

n

• 1 milyon inode

n

nn

Senaryo 1: 10 siteli küçük ajans

n

Ajansınızda 10 müşteri var; hepsi WordPress tabanlı, WooCommerce yok. Çoğu kurumsal vitrinden oluşuyor.

n

n
• 8 siteyi Business pakete, 2 siteyi Startera alabilirsiniz.

n

n

Önerilen kaynak dağılımı:

n

n
• Starter (2 site): 0.25 vCPU, 512 MB RAM, 15 EP, 3 GB disk, 50.000 inode

n

• Business (8 site): 0.5 vCPU, 1 GB RAM, 25 EP, 5 GB disk, 100.000 inode

n

n

Teorik toplam:

n

n
• CPU: 2 × 0.25 + 8 × 0.5 = 4.5 vCPU (oversell var ama pratikte aynı anda tavan yapmazlar)

n

• Disk: 2 × 3 + 8 × 5 = 46 GB

n

• inode: 2 × 50.000 + 8 × 100.000 = 900.000 inode

n

n

Bu portföyde asıl risk inode tarafında; 1 milyonluk havuzun %90u2019ını tükettiniz. Burada iki tedbir işe yarar:

n

n
• İlk günden itibaren müşteriye düzenli temizlik ve arşiv politikasını anlatmak.

n

• Staging kopyaları, eski yedek dosyalarını aynı hosting içinde tutmak yerine harici yedeklere taşımak.

n

nn

Senaryo 2: 30 siteli büyüyen bayi (içinde WooCommerce de var)

n

Bu kez 30 cPanel hesabı yöneten daha büyük bir reseller düşünelim. Müşteri kırılımı şöyle olsun:

n

n
• 15 küçük vitrin/blog

n

• 10 kurumsal site (orta trafik)

n

• 5 WooCommerce / katalog sitesi

n

n

Bu tabloya şöyle yaklaşabilirsiniz:

n

n
• 15 küçük site → Starter

n

• 10 kurumsal site → Business

n

• 5 WooCommerce → Pro

n

n

Kaynak dağılımı (öneri):

n

n
• Starter: 0.25 vCPU, 512 MB RAM, 15 EP, 2 GB disk, 40.000 inode

n

• Business: 0.5 vCPU, 1 GB RAM, 25 EP, 5 GB disk, 80.000 inode

n

• Pro: 1 vCPU, 2 GB RAM, 40 EP, 20 GB disk, 200.000 inode

n

n

Teorik toplama bakalım:

n

n
• CPU: 15 × 0.25 + 10 × 0.5 + 5 × 1 = 3.75 + 5 + 5 = 13.75 vCPU

n

• Disk: 15 × 2 + 10 × 5 + 5 × 20 = 30 + 50 + 100 = 180 GB

n

• inode: 15 × 40.000 + 10 × 80.000 + 5 × 200.000 = 600.000 + 800.000 + 1.000.000 = 2.4 milyon

n

n

Burada iki şeyi fark etmiş olmalısınız:

n

n
1. CPU tarafında oldukça ciddi bir oversell var (4 vCPU havuza karşı 13.75 vCPU teorik). Fakat tüm sitelerin aynı anda tepeye vurma ihtimali düşük olduğu için, iyi önbellekleme (cache), CDN ve optimizasyon ile bu senaryo makul seviyede çalışabilir.

n

2. inode ve disk tarafında mevcut havuzunuzu aştınız; bu da ya daha büyük bir reseller planına, ya da parçayı VPS/dedicated tarafa kaydırmaya işaret ediyor.

n

n

Tam bu noktada, u201cBu kadar siteyi hâlâ reseller üzerinde mi tutmalıyım, yoksa artık VPS tabanlı ajans mimarisine geçmenin zamanı mı?u201d sorusu gündeme gelir. DCHost olarak genellikle şu eşikleri referans alıyoruz:

n

n
• Toplam 30–40 siteyi geçtiyseniz,

n

• İçlerinde trafik yoğun birkaç WooCommerce / kampanya sitesi varsa,

n

• inode ve disk planlaması sürekli u201ckırmızı alandau201d dolaşıyorsa,

n

n

Artık yönetilen bir VPS veya dedicated çözümü düşünmenin zamanı gelmiş demektir.

nn

Paketlendirme stratejisi: az sayıda, net segmentli paket

n

Reseller müşterilerinize sunacağınız alt paketleri tasarlarken, en yaygın hata 7–8 farklı paket çıkarmak oluyor. Sonuç: Hem siz hem de müşteri kafası karışık bir fiyat tablosu ile baş başa kalıyorsunuz. DCHostu2019ta gördüğümüz en sağlıklı model, 3 veya en fazla 4 segmentli yapı:

n

n
• Basic/Starter (küçük vitrin, kişisel bloglar)

n

• Business (kurumsal siteler, hafif formlar)

n

• Pro/E‑ticaret (WooCommerce, LMS, üyelik siteleri)

n

• (İsteğe bağlı) Özel/Enterprise (tamamen case bazlı, genelde artık VPS/dedicated tarafı)

n

n

Her paket için mutlaka tanımlayın:

n

n
• Kullanıcı başına minimum CPU, RAM, EP

n

• Disk ve inode limiti

n

• Mail kutusu sayısı ve toplam mail kotası

n

• Saatlik gönderim limiti

n

n

Bunları sözleşme ve fiyatlandırma sayfalarında net şekilde yazmak, ileride çıkabilecek çoğu tartışmayı en baştan engeller. Paket tasarımı ve limit yönetimi konusunda daha geniş bir çerçeve isterseniz, Reseller hosting yönetimi rehberimiz sizin için iyi bir tamamlayıcı olacaktır.

nn

İzleme, uyarı ve müşteriye şeffaf raporlama

n

İyi tasarlanmış limitler kadar, iyi izleme ve şeffaf raporlama da önemli. Aksi halde müşteri, u201cKaynak limitine takıldımu201d cümlesini her duyduğunda bunun bir bahane olduğunu düşünebilir.

n

Önerdiğimiz pratikler:

n

n
• cPanel istatistik ekranını müşteriye nasıl okuyacağını gösteren kısa bir doküman hazırlayın.

n

• CPU/EP tavan yaptığı anlarda DCHost tarafında tuttuğunuz grafiklerden ekran görüntüsü alıp müşteriye açıklamayla gönderin.

n

• inode ve disk kullanımı %80u2019i geçtiğinde, otomatik uyarı maili atan bir izleme kurgulayın.

n

• Kritik siteler için aylık u201cKaynak Kullanım Özetiu201d raporu, ajanslar açısından ciddi katma değer yaratır.

n

nn

Reseller’dan ne zaman VPS veya dedicated sunucuya geçmelisiniz?

n

Reseller çok verimlidir; özellikle 5–30 site arası portföyü olan ajanslar için ideal. Ancak belli bir ölçeğin üzerine çıktığınızda, reseller yapının doğası gereği bazı duvarlara toslarsınız:

n

n
• Toplam inode ve disk havuzu sürekli tıkanıyorsa,

n

• CPU/EP tarafında birkaç site tüm portföyü etkiliyorsa,

n

• Müşterilerinizin bir kısmı özel PHP eklentileri, Node.js uygulamaları, background işler talep ediyorsa,

n

n

Artık kendi VPS veya dedicated sunucunuza geçmek genelde daha mantıklı hale gelir. DCHost tarafında pek çok ajans, önce reseller ile başlıyor; sonrasında iş büyüdükçe yönetilen VPS, ileride de dedicated veya colocation mimarisine ilerliyor. Tam bu geçiş noktasını daha net görmek için, ajanslar için reseller mı VPS mi rehberimizi mutlaka okumanızı öneririm.

nn

Sonuç: Doğru limit tasarımı sizi hem korur hem büyütür

n

cPanel reseller paket tasarımı, sadece u201ckaç GB verelim, kaç site host edilsinu201d sorusundan ibaret değil. CPU, inode, disk ve e‑posta limitlerini bilinçli kurguladığınızda:

n

n
• Bir müşteri diğerlerini ezmeden, tüm portföy kararlı çalışır.

n

• Beklenmedik kaynak patlamalarında sorunu hızlı teşhis edip doğru pakete yönlendirebilirsiniz.

n

• Kendi maliyetinizi (disk, IOPS, CPU, IP, yedekleme) kontrol altında tutarak kârlı kalırsınız.

n

n

DCHost olarak bizim gördüğümüz en başarılı ajans ve bayiler, baştan itibaren net limit politikası koyan ve bunu müşterileriyle şeffaf paylaşanlar. Siz de reseller işinizi bir üst seviyeye taşımak istiyorsanız, önce mevcut portföyünüzü analiz edip:

n

n
• Kaç siteniz var, hangi profilde?

n

• Hangi siteler yoğun CPU/IO kullanıyor?

n

• inode ve disk tarafında kimler kırmızı alanda?

n

• E‑posta tarafında kimler saatlik limite yaklaşmış durumda?

n

n

gibi sorulara net cevaplar çıkarın. Ardından bu yazıdaki segmentasyon örneklerini kendinize uyarlayarak 3–4 net paket oluşturun. Eğer u201cReseller artık beni zorluyor, kendi sunucuma geçmek istiyorumu201d noktasındaysanız, DCHost üzerinde yönetilen VPS, dedicated ve colocation seçeneklerimizle aynı yaklaşımı daha esnek bir altyapıya taşıyabilirsiniz.

n

Doğru tasarlanmış bir cPanel reseller yapısı, hem müşterilerinizin web sitelerini güvenle barındırmanızı sağlar hem de size sürdürülebilir bir hosting iş modeli sunar. Adım adım ilerleyin, ölçün, iyileştirin ve limitleri kâğıt üzerinde değil gerçek kullanım verisine göre güncel tutun.

n”,
“focus_keyword”: “cPanel reseller paket tasarımı”,
“meta_description”: “cPanel reseller paket tasarımı için CPU, inode, disk ve e‑posta limitlerini nasıl belirleyeceğinizi adım adım anlatıyoruz. Ajans ve bayiler için pratik rehber.”,
“faqs”: [
{
“question”: “cPanel reseller paketinde overselling yapmak güvenli mi?”,
“answer”: “Tamamen u201csıfır oversellu201d çok güvenli ama ticari olarak verimsizdir; agresif oversell ise birkaç müşterinin tüm altyapıyı çökertmesine yol açabilir. Sağlıklı olan, CPU ve IO tarafında kontrollü oversell, disk ve inode tarafında ise daha muhafazakâr bir yaklaşım uygulamaktır. Örneğin 4 vCPU havuzuna teorik olarak 8–10 vCPU edecek limit tanımlamak genelde yönetilebilir; ancak disk ve inodeu201da fiziksel sınırı aşmayacak şekilde plan yapmalısınız. Anahtar nokta, iyi önbellekleme, izleme ve limit aşımlarında hızlı aksiyon almak; yani oversell oranınızı gerçek kullanım verisine bakarak sürekli ayarlamaktır.”
},
{
“question”: “Reseller müşterilerim için inode limitini kaçta tutmalıyım?”,
“answer”: “inode limiti, barındırdığınız sitelerin profilinden çok etkilenir. Basit vitrin ve blog siteleri için 40–60 bin inode genellikle yeterliyken, eklenti zengini WordPress kurulumları ve WooCommerce mağazalarında 100–200 bin inode seviyeleri daha gerçekçidir. Reseller seviyesinde pratik yaklaşım; Starter paketlerde 40–60 bin, Businessu201ta 80–120 bin, Pro/E‑ticarette ise 150–250 bin aralığında limitler tanımlamaktır. Ayrıca müşterilere düzenli temizlik, eski yedekleri kaldırma ve cache klasörlerini kontrol etme alışkanlığını kazandırmanız, inode baskısını ciddi biçimde azaltacaktır.”
},
{
“question”: “Ajansım için reseller mi, yoksa doğrudan VPS mi tercih etmeliyim?”,
“answer”: “5–30 site aralığındaki ajanslar için iyi tasarlanmış bir cPanel reseller paketi çoğu zaman en verimli başlangıç noktasıdır. Çünkü altyapı yönetimi, güvenlik güncellemeleri ve donanım tarafı DCHost ekibi tarafından yönetilir; siz projelere odaklanırsınız. Ancak 30–40 siteyi geçmeye, WooCommerce ve benzeri ağır projelerin sayısı artmaya ve kaynak limitleri sürekli zorlanmaya başladıysa, yönetilen VPS veya dedicated çözümler daha mantıklı hale gelir. Kısaca: Az sayıda hafif site → reseller; çok sayıda veya ağır site → kademeli olarak VPS/dedicated mimarisine geçiş stratejisi en sağlıklı yoldur.”
},
{
“question”: “Reseller paketinde e‑posta gönderim limitini nasıl belirlemeliyim?”,
“answer”: “E‑posta tarafında amaç, hem müşterilerin işini görmesi hem de IP itibarınızı korumaktır. Küçük kurumsal siteler için 100–200 mail/saat, biraz daha aktif bülten kullanan müşteriler için 300–500 mail/saat genellikle yeterlidir. Daha yüksek hacimli pazarlama gönderimlerinde 800–1000 mail/saat limitine çıkılabilir, fakat bu müşterileri mümkünse ayrı IP veya ayrı altyapıda tutmak daha güvenlidir. Ayrıca SPF, DKIM, DMARC ve rDNS kayıtlarını doğru kurmak ve şüpheli gönderimleri loglardan takip etmek, limitlerin tek başına çözemeyeceği spam risklerini ciddi oranda düşürür.”
},
{
“question”: “CPU ve Entry Processes limitleri düşüktür diye müşteri performans kaybı yaşar mı?”,
“answer”: “Tek başına u201cdüşük görünenu201d CPU veya Entry Processes (EP) rakamları, her zaman performans kaybı anlamına gelmez. İyi cache alan, CDN kullanan, veritabanı sorguları optimize edilmiş bir WordPress sitesi, 0.25–0.5 vCPU ve 15–25 EP ile oldukça akıcı çalışabilir. Performans problemleri çoğu zaman yetersiz önbellekleme, ağır eklentiler ve optimize edilmemiş sorgulardan kaynaklanır. Bu yüzden müşteri şikâyetlerinde sadece limiti yükseltmek yerine, önce uygulama düzeyinde optimizasyon yapmak; ardından gerekliyse paketi Business/Pro seviyesine taşımak çok daha sağlıklı ve sürdürülebilir bir yaklaşım olacaktır.”
}
]
}