هاست سایت پرترافیک؛ از Capacity و SLO تا Load Test

پنجاه‌هزار بازدید ماهانه ممکن است روی یک سرویس کوچک آرام اجرا شود؛ پانصد Checkout هم‌زمان می‌تواند معماری ظاهراً «ابری» را در چند ثانیه متوقف کند. بازدید ماهانه نمی‌گوید Traffic در چه زمانی می‌رسد، چند Request می‌سازد، چه مقدار Cache می‌شود یا Database و درگاه چند عملیات هم‌زمان تحمل می‌کنند. به همین دلیل نسخه عمومی «۴ هسته و ۸ گیگ رم» برای سایت پرترافیک قابل‌دفاع نیست.

انتخاب هاست سایت پرترافیک از خرید سرور بزرگ‌تر شروع نمی‌شود؛ از Workload contract، Critical journey، SLO، ظرفیت اندازه‌گیری‌شده و Failure budget شروع می‌شود. در این راهنما، مسیر Edge→Origin→App→Database→Dependency را مدل می‌کنیم، Bottleneck را با Load test پیدا می‌کنیم و سپس Managed WordPress، VPS، Cloud VM، PaaS/Container، Dedicated یا Cluster را با TCO و شواهد ایران مقایسه می‌کنیم.

مرزبندی؛ این راهنما درباره Capacity engineering است

برای تعریف Shared، Managed WordPress، VPS، Cloud و Dedicated و انتخاب عمومی آن‌ها، راهنمای انتخاب هاست Pillar اصلی است. این مقاله مسئله بعدی را مالک می‌شود: وقتی Growth، کمپین، خبر فوری یا فروش ویژه بار بالا و Failure costly می‌سازد، چگونه ظرفیت و معماری را طراحی کنیم؟

«پرترافیک» عدد ثابت نیست

High traffic یعنی Demand نسبت به Capacity و SLO شما ریسک معنادار ساخته است. یک سایت محتوایی با Cache hit بالا ممکن است میلیون‌ها Pageview را در Edge پاسخ دهد؛ فروشگاه کم‌بازدید اما Dynamic با Search، Cart، Inventory، Payment و Cron می‌تواند زودتر Database را اشباع کند.

Traffic shape مهم‌تر از میانگین است

میانگین روزانه برای Capacity تصمیم خوبی نیست. Peak یک‌دقیقه‌ای، Burst ده‌ثانیه‌ای، Ramp کمپین، Cache purge، Bot crawl، Feed import و Retry storm را جدا ثبت کنید. Traffic ممکن است Predictable باشد—مثلاً شروع فروش ساعت ۱۰—یا ناگهانی مانند خبر و Mention شبکه اجتماعی.

Workload contract سایت پرترافیک

فرمول‌های ساده، نه ماشین‌حساب جادویی

Concurrency ≈ Requests per second × Average request duration

Origin RPS ≈ Total eligible RPS × (1 - Cache hit ratio)

Monthly transfer ≈ Responses × Average transferred bytes

Headroom = Tested sustainable capacity - Expected peak load

برای Tail از Average استفاده نکنید؛ Duration در p95/p99، Retry و Cache-miss burst را جدا مدل کنید. Hit ratio نیز باید براساس Route و Cohort باشد. عدد ۹۵٪ در کل سایت ممکن است Checkout صفر درصد و Origin-critical باشد.

Critical journey و SLO را قبل از CPU تعریف کنید

«سایت بالا است» معیار عملیاتی کافی نیست. صفحه اصلی می‌تواند ۲۰۰ باشد اما Login یا Checkout شکست بخورد. برای هر Journey، SLI و Window تعریف کنید:

SLO با SLA فرق دارد. SLA قرارداد جبران و Exclusion دارد؛ SLO هدف مهندسی و Error budget تیم است. ۹۹٫۹٪ Availability در Window سی‌روزه حدود ۴۳ دقیقه Budget نظری می‌دهد، اما فقط اگر تعریف Event، Probe، Journey و Exclusion دقیق باشد.

قبل از مهاجرت، Bottleneck را اندازه بگیرید

خرید RAM مشکل Query بد، External API کند یا Cache stampede را حل نمی‌کند. مسیر درخواست را به لایه‌ها بشکنید:

Metric بدون Trace/Correlation فقط نشان می‌دهد «چیزی کند است». راهنمای Observability وب‌سایت مسیر User journey تا Signal، SLO و Incident را کامل می‌کند.

اول Work per request را کم کنید

Capacity فقط افزودن Resource نیست. اگر هر Pageview ده‌ها Query تکراری، تصویر بزرگ، API blocking یا Plugin سنگین می‌سازد، Scale هزینه همان اتلاف را بزرگ می‌کند. راهنمای رسمی WordPress برای Optimization Hosting، Theme/Plugin، Cache، Object cache، Content offloading، Database و افزودن Server را اجزای جدا می‌داند.

1. Critical route و expensive query/plugin را Profile کنید؛
2. Page/object/opcode/browser/edge cache را با Contract بسازید؛
3. Image/asset و Delivery را بهینه و offload کنید؛
4. Cron، Import، Email و Report را از Web request جدا کنید؛
5. DB index/query/connection/lock را اصلاح کنید؛
6. Timeout، retry و concurrency Dependency را محدود کنید؛
7. سپس Baseline جدید را Load test و Capacity را انتخاب کنید.

Optimization بی‌پایان نیز خطاست. اگر تیم ساعت‌ها برای صرفه‌جویی جزئی کار می‌کند اما Managed platform با SLO بهتر TCO پایین‌تری دارد، معماری را عوض کنید. تصمیم باید Cost of engineering را ببیند.

Cache؛ اهرم ظرفیت و منبع Failure

مستند Cache در WordPress Page، Browser، Object و Server caching را جدا می‌کند. Cache hit مناسب، Origin work را به‌شدت کم می‌کند؛ اما Cache اشتباه می‌تواند Price، Cart، Account یا محتوای خصوصی را به کاربر نادرست نشان دهد.

Cache-miss storm را تست کنید

بعد از Deploy، Purge یا Expiry هم‌زمان، هزار Edge/Client ممکن است یک Resource را از Origin بخواهند. Request coalescing، Tiered cache/origin shield، jittered TTL، stale-while-revalidate و warmup کنترل‌های احتمالی‌اند. مستند Tiered Cache کلادفلر توضیح می‌دهد چگونه لایه بالاتر تعداد درخواست مستقیم به Origin را کم می‌کند؛ محصول و تناسب را با Provider خود بررسی کنید.

Database معمولاً دیر یا زود مرز را نشان می‌دهد

• Query: p95/p99، execution plan، index، scan و N+۱ را ببینید؛
• Connection: Worker بیشتر می‌تواند Connection storm بسازد؛ Pool و سقف لازم است؛
• Lock: Checkout/Inventory/Session ممکن است روی Rowهای داغ رقابت کنند؛
• I/O: NVMe label جای اندازه‌گیری Latency/IOPS/queue depth را نمی‌گیرد؛
• Replica: Read replica ظرفیت Read را زیاد می‌کند، اما Lag و read-after-write correctness دارد؛
• Backup: Replica Backup نیست و اشتباه منطقی را نیز تکثیر می‌کند؛
• Maintenance: Index/Schema change باید زیر Load و با rollback آزموده شود.

«Database را جدا کنیم» فقط وقتی مفید است که Network latency، failure domain، connection و عملیات آن طراحی شده باشد. برای سایت تراکنشی، Consistency و correctness از Throughput خام مهم‌تر است.

گزینه‌های میزبانی برای بار بالا

Dedicated ذاتاً سریع‌ترین یا امن‌ترین نیست؛ Architecture، Software، Patch، Segmentation و Operations نتیجه را می‌سازند. VPS نیز منابع «کاملاً بی‌اثر از همسایه» را فقط در محدوده Contract/Hypervisor/Storage/Network ارائه می‌کند. Cloud label به‌تنهایی HA یا Autoscaling نمی‌دهد.

Serverless را برای Component بسنجید

Image job، Webhook، Queue consumer یا API متغیر ممکن است Serverless مناسب باشد، در حالی که Core WordPress روی Managed stack بماند. مقاله Serverless یا Server-based Quota، Cold start، Event semantics، TCO و Pilot این Placement را پوشش می‌دهد.

Vertical یا Horizontal scale؟

Vertical scaling اغلب بهترین گام کوتاه‌مدت است؛ «ابتدایی» یا بد نیست. Horizontal زمانی ارزش دارد که Single-node capacity، Availability target، Deployment isolation یا رشد آن را توجیه کند. برای آن، Session و Upload باید Shared/external یا Sticky behavior عمداً طراحی شوند.

Load Balancer فقط برای «ترافیک عظیم» نیست

Load balancer می‌تواند برای Redundancy، Maintenance بدون قطعی، Canary و Health-based routing پیش از رسیدن به سقف بزرگ‌ترین سرور مفید باشد. اما وجود آن HA را تضمین نمی‌کند.

• Health check باید Readiness واقعی Journey را بسنجد، نه فقط Process alive؛
• Connection draining و graceful shutdown در Deploy/scale لازم است؛
• Timeout، retry و idle connection میان Client/LB/App هم‌راستا باشند؛
• Session stickiness ممکن است توزیع را نامتوازن و Failover را دشوار کند؛
• TLS، client IP، header trust و WAF boundary باید روشن باشند؛
• خود LB/DNS/Control plane نیز Failure domain و quota دارد.

Autoscaling آنی نیست؛ Headroom لازم است

Autoscaler پس از مشاهده Metric تصمیم می‌گیرد، Instance/Container آماده می‌شود و Health check را می‌گذراند؛ در این فاصله Burst باید با Warm capacity، Queue، cache یا rate control تحمل شود. راهنمای Elasticity گوگل کلاد برای Peakهای شناخته‌شده Scale-up پیش‌دستانه و برای Demand غیرمنتظره Autoscaling متریک‌محور را پیشنهاد می‌کند.

AWS Well-Architected نیز بر Headroom برای Burst تا آماده‌شدن Resource و انتخاب Scaling metric از Load test تأکید دارد. CPU همیشه Metric درست نیست؛ Queue age، concurrency، request latency، worker saturation یا DB capacity ممکن است محدودکننده باشند.

Downstream را قربانی Scale نکنید

افزایش App replica بدون سقف می‌تواند Database، Redis، Payment یا SMS را از پا بیندازد. Max concurrency، queue، admission control، timeout، retry budget، circuit breaker و graceful degradation باید ظرفیت پایین‌دست را حفظ کنند. در Overload، حفظ Checkout و Login ممکن است مهم‌تر از Recommendation یا گزارش باشد.

CDN برای ایران؛ با Cache hit و مسیر واقعی تصمیم بگیرید

CDN می‌تواند Static asset و در برخی موارد HTML را نزدیک‌تر پاسخ، Origin load را کم، حمله را جذب و Egress را تغییر دهد؛ اما Dynamic checkout، Cache miss و Origin failure باقی می‌مانند. راهنمای انتخاب CDN برای ایران ISP probe، Cache، Purge، Security، Cost و Pilot را جدا بررسی می‌کند.

برای هر ISP/شهر/ساعت، DNS، connect، TLS، TTFB و Download را روی hit/miss و authenticated/anonymous بسنجید. «نزدیک‌ترین دیتاسنتر» یا «سرور داخل همیشه سریع‌تر است» میانبر نیست؛ Peering، routing، congestion و Dependency path تعیین‌کننده‌اند.

معماری WordPress پرترافیک

User → DNS/WAF/CDN → Load Balancer/Reverse Proxy
     → Web/PHP workers → Object Cache → Database
     → Queue/Cron workers → Payment/SMS/Search/Email
     → Object Storage/Media → Observability

این دیاگرام نسخه اجباری نیست. ابتدا ساده‌ترین Stackی را انتخاب کنید که SLO را پاس می‌کند. نقاط مهم WordPress:

• Full-page cache برای Anonymous و Bypass دقیق برای Login/Cart/Checkout؛
• Persistent object cache با hit/eviction و Failure behavior؛
• PHP worker/concurrency و queueing، نه فقط CPU/RAM؛
• Plugin/theme profile، autoloaded options و expensive query؛
• WP-Cron به Scheduler/Worker کنترل‌شده برای بار سنگین؛
• Upload مشترک یا Object storage در چند Web node؛
• Session/cart state سازگار با horizontal scale؛
• Cache purge پس از Publish/Price/Stock با blast radius محدود؛
• Admin/API/Search/Checkout workload جدا در Dashboard؛
• Backup سازگار با Database+Media و Restore test.

Load test نماینده؛ نه رکورد RPS بی‌معنا

راهنمای Load testing در AWS Well-Architected بر شرایط نماینده و محیط Production-scale تأکید دارد. Test باید Outcome و Bottleneck را نشان دهد، نه فقط تعداد Request موفق به یک صفحه Cache‌شده.

Traffic mix و داده آزمون

Anonymous hit، anonymous miss، logged-in، Search، Cart، Checkout، API، Admin، Bot و Background job را با نسبت واقع‌گرایانه ترکیب کنید. Product/catalog size، Query distribution و Session نیز نماینده باشند. Payment/SMS واقعی را بدون هماهنگی Flood نکنید؛ Sandbox یا Stub با Latency/Error contract بسازید. Test تولیدی محدود باید Guardrail، Owner و Stop condition داشته باشد.

High Availability و Disaster Recovery جدا هستند

دو Web node روی یک Database، یک Region و یک DNS هنوز چند Single point دارد. HA قطعی‌های معمول را در RTO کوتاه هدف می‌گیرد؛ DR سناریوی بزرگ‌تر و بازیابی داده/خدمت را. Multi-zone/region هزینه، Consistency، deployment و عملیات اضافه دارد و باید از BIA و SLO بیاید.

Backup بدون Restore evidence امنیت روانی است. راهنمای Backup، RPO/RTO و Runbook بازیابی سایت طراحی Data set، Restore drill، DNS و Failover را پوشش می‌دهد.

Security و Abuse capacity

• WAF و DDoS scope/limit/SLA را از Contract بگیرید؛
• Bot، Scraper، hotlink، Login brute force و expensive search را در Capacity ببینید؛
• Rate limit براساس Identity/route/risk باشد، نه IP کور؛ کاربران پشت NAT/VPN را حذف نکند؛
• Origin را در برابر دورزدن Edge محدود و Header trust را سخت‌گیرانه کنید؛
• Admin، SSH، Control panel و Cloud IAM با MFA/least privilege/log محافظت شوند؛
• Autoscaling و Egress می‌تواند Cost-abuse بسازد؛ Budget alert و سقف لازم است؛
• Patch/dependency/secret و Incident ownership در Managed contract نیز باقی است.

ملاحظات سایت پرترافیک ایرانی

برای کمپین ملی، Warm capacity و ارتباط با Provider/CDN/درگاه را پیش از شروع هماهنگ کنید. مسیر جایگزین، Status page و پیام عملیاتی فارسی آماده باشد. Location را با Probe و Dependency end-to-end انتخاب کنید، نه برچسب «ایران» یا «خارج».

TCO؛ هزینه Idle و Incident را کنار Compute بگذارید

High-traffic hosting TCO =
Compute + Storage + DB + Cache + LB + CDN/WAF
+ Egress + Backup + Logs/Traces + Support
+ Engineering + On-call + Security + Migration/Exit
+ Expected incident and business-loss exposure

هزینه کمینه، محتمل و Peak را با FX، Egress، Log volume، Warm headroom و Support بسازید. سپس Cost per successful order/search یا per eligible request را مقایسه کنید. مقاله TCO دامنه و هاست Procurement، Renewal، قرارداد و Exit مالی را عمیق‌تر توضیح می‌دهد.

از Provider چه مدرکی بگیریم؟

Knockout و Scorecard انتخاب

ابتدا Knockoutها: Eligibility، Data requirement، ضروریات Runtime، RPO/RTO، ظرفیت آزموده‌شده، Payment و Exit. گزینه‌ای که شرط غیرقابل‌مذاکره را نمی‌گذراند با امتیاز قیمت برنمی‌گردد.

وزن‌ها نمونه‌اند؛ براساس Business impact تنظیم کنید. Score بروشور با Score حاصل از PoC برابر نیست. هر امتیاز Owner، تاریخ، Source و Confidence داشته باشد.

Pilot و مهاجرت کم‌ریسک

1. Baseline فعلی و Bottleneck را ثبت کنید؛
2. معماری هدف و Capacity/SLO contract بنویسید؛
3. Environment نماینده با داده Sanitized بسازید؛
4. Load/soak/spike/cache-cold/failure/recovery test اجرا کنید؛
5. Content/data sync و DNS/CDN/LB را با TTL برنامه‌ریزی کنید؛
6. Shadow یا سهم کوچک Traffic را Canary کنید؛
7. Outcome/SLO/Cost/Error را با Baseline مقایسه کنید؛
8. Rollback و Restore را پیش از Cutover Drill کنید؛
9. Ramp مرحله‌ای و Post-migration observation انجام دهید.

Kill criteria نمونه

• Checkout correctness یا Error budget خارج Threshold؛
• p95/p99 یا queue age پس از Ramp پایدار نشود؛
• DB/cache/dependency saturation از Guardrail عبور کند؛
• Cost per successful outcome از Baseline بدتر شود؛
• Observability یا Incident ownership ناکافی باشد؛
• Restore/rollback یا Provider escalation Drill شکست بخورد.

Runbook کمپین و Traffic event

فقط Uptime dashboard داخل زیرساخت کافی نیست. Probe خارج از شبکه و Journey واقعی لازم است؛ راهنمای مانیتورینگ Uptime Status code، Content check، چندمکان، Alert و false positive را پوشش می‌دهد.

چک‌لیست هاست سایت پرترافیک

• High traffic با RPS/Peak/Burst/Concurrency تعریف شده است؛
• Critical journey و Outcome از Pageview جداست؛
• Cache hit/miss و authenticated/anonymous جدا اندازه‌گیری شده‌اند؛
• p50/p95/p99 Duration و Saturation curve وجود دارد؛
• Worker/CPU/RAM/I/O/DB/cache/queue/dependency Signal دیده می‌شوند؛
• Query، Plugin، Autoload، Cron و Asset پیش از Scale Profile شده‌اند؛
• SLO، Error budget، RPO و RTO روشن‌اند؛
• Shared/Managed/VPS/Cloud/Dedicated با RACI مقایسه شده‌اند؛
• Vertical قبل از Distributed complexity بررسی شده است؛
• Horizontal scale برای Session/Media/Deploy/DB آماده است؛
• LB health، draining، timeout و session behavior تست شده‌اند؛
• Autoscaling headroom، lag، min/max و quota دارد؛
• Max concurrency از DB و Dependency محافظت می‌کند؛
• Cache purge/miss/stampede و warmup آزموده شده‌اند؛
• Load/soak/spike/stress/failure/recovery test نماینده اجرا شده‌اند؛
• Security/bot/DDoS/cost abuse در Capacity دیده شده‌اند؛
• ISP/شهر/ساعت/درگاه/SMS ایران Probe شده‌اند؛
• TCO شامل Egress/Log/Support/Ops/Incident/Exit است؛
• Provider claim با Contract/PoC/Drill اثبات شده است؛
• Pilot، Canary، Kill criteria، Rollback و Event runbook آماده‌اند.

جمع‌بندی؛ Capacity را بخرید، برچسب را نه

سایت پرترافیک با «میلیون بازدید» یا «۸ گیگ RAM» تعریف نمی‌شود. Traffic shape، Cacheability، Concurrent dynamic work، Database/Dependency capacity و SLO تعیین می‌کنند چه چیزی لازم است. Managed WordPress می‌تواند از VPS خام بهتر باشد؛ Vertical scale می‌تواند از Cluster پیچیده عاقلانه‌تر باشد؛ و Cloud بدون طراحی Failure/Autoscaling فقط صورت‌حساب متفاوتی است.

از Journey و Baseline شروع کنید، Work per request را کم کنید، Bottleneck را زیر Load نماینده پیدا کنید و Headroom را تا Scale-up بسازید. سپس گزینه را با Failure/restore drill، مسیر ایران، TCO و Exit بسنجید. بهترین زیرساخت آن است که در روز کمپین Outcome درست را حفظ کند و تیم بتواند هنگام شکست آن را بفهمد، محدود و بازیابی کند.

سؤالات متداول هاست سایت پرترافیک

برای ۵۰ هزار بازدید ماهانه چند CPU و RAM لازم است؟

از بازدید ماهانه قابل‌محاسبه نیست. Peak RPS، Request per page، Cache hit، Login/Cart/Checkout، Duration، Plugin/query و Background job ظرفیت را می‌سازند. Baseline بگیرید و با Traffic mix نماینده Load test کنید؛ سپس CPU/RAM/worker و Headroom را از Saturation curve انتخاب کنید.

برای سایت پرترافیک VPS بهتر است یا Cloud؟

VPS/Managed VPS برای بار قابل‌پیش‌بینی و تیم کوچک می‌تواند ساده‌تر و کم‌هزینه‌تر باشد. Cloud برای API-driven scaling و Managed service گزینه بیشتری می‌دهد، اما HA و Autoscaling خودکار نیست و TCO/Complexity دارد. هر دو را با SLO، Load/failure test، RACI، مسیر ایران و TCO مقایسه کنید.

چه زمانی Load Balancer لازم است؟

فقط بعد از پرشدن بزرگ‌ترین سرور نیست. وقتی Availability، Maintenance بدون قطعی، Canary یا Capacity چند Node نیاز دارید، مفید است. اما Health check، draining، session/state، timeout، TLS و Failure خود Load balancer باید طراحی و آزمون شوند.

آیا سرور داخل ایران برای کاربران ایرانی همیشه سریع‌تر است؟

خیر. فاصله تنها عامل نیست؛ Routing/Peering، ISP، ساعت، CDN hit/miss، crawler و مسیر درگاه/SMS/API مؤثرند. از چند ISP و شهر روی Journey واقعی Probe بگیرید و Eligibility، Data، Payment، Support و Exit را نیز بسنجید. پاسخ ممکن است داخل، خارج یا Hybrid باشد.

چگونه برای فروش ویژه از قطعی جلوگیری کنیم؟

Forecast و Traffic mix بسازید؛ Load/spike/cache-cold/failure test کنید؛ quota و Provider/درگاه را هماهنگ، Warm capacity و Cache را آماده، DB/Dependency را با concurrency cap محافظت و Runbook/Owner/Status/Rollback تعیین کنید. روز رویداد Journey SLI و Outcome را کنار Saturation و Cost مانیتور کنید.