چگونه عملکرد سرور را بهبود دهیم؟

وقتی سایت روی سرور کند می‌شود، اولین واکنش اکثر مدیرها این است که به سرویس‌دهنده پیام بدهند و پلن بالاتری بخواهند. اما در تجربه من، حدود نیمی از سرورهایی که مشتری می‌گفت «کم آورده»، با تنظیم مجدد همان پلن فعلی، بیست تا پنجاه درصد سریع‌تر شدند. بهبود عملکرد سرور (server performance optimization) یک مسئله تنظیم است پیش از یک مسئله خرید. در ادامه هفت لایه‌ای را می‌گویم که در پروژه‌های واقعی برای بهبود عملکرد سرور بازرسی می‌کنم.

لایه اول: تنظیمات هسته سیستم‌عامل

لینوکس با پیش‌فرض‌های محافظه‌کارانه می‌آید که برای سرورهای عمومی طراحی شده‌اند، نه برای سرور وب پرترافیک. سه تنظیم که در پروژه‌ها بیشترین اثر را داشته‌اند:

# /etc/sysctl.d/99-performance.conf
net.core.somaxconn = 1024
net.ipv4.tcp_max_syn_backlog = 2048
vm.swappiness = 10
fs.file-max = 100000

تنظیم vm.swappiness به مقدار پایین (مثل ۱۰) در سرورهای پر RAM، باعث می‌شود هسته تا جای ممکن از swap استفاده نکند. تنظیم somaxconn به وب‌سرور اجازه می‌دهد صف اتصالات بزرگ‌تری را مدیریت کند و در ساعات اوج ترافیک، خطای connection reset کمتر رخ دهد. هر یک از این تنظیمات را با sysctl -p اعمال کنید و قبل از تغییر، اسنپ‌شات بگیرید.

بهبود عملکرد سرور، پیش از آن‌که خرید منابع تازه باشد، پاک‌کردن گلوگاه‌های تنظیماتی است.

لایه دوم: وب‌سرور (Nginx یا Apache)

تفاوت Nginx و Apache در نحوه مدیریت اتصالات است؛ Nginx برای بار سنگین معمولاً کارآمدتر است چون معماری event-driven دارد، در حالی که Apache در حالت prefork برای هر اتصال یک پروسه می‌سازد. اگر روی Apache هستید و ترافیک بالاست، مهاجرت به Nginx یا انتقال Apache به حالت mpm_event می‌تواند جهش محسوسی در عملکرد بیاورد.

تنظیمات کلیدی که در هر دو باید برسی شوند:

• تعداد worker و worker_connections متناسب با CPU و RAM.
• فعال‌سازی compression (gzip یا brotli) برای فایل‌های متنی.
• تنظیم keep-alive با مقدار متعادل (مثلاً ۱۵ تا ۳۰ ثانیه).
• فعال‌سازی HTTP/2 یا HTTP/3 برای کاهش latency.
• کش فایل‌های استاتیک در سمت وب‌سرور.

لایه سوم: PHP و OPcache

اگر PHP-FPM اجرا می‌کنید، تنظیمات pool نقش اساسی دارند. مقادیر زیر نقطه شروع من است:

pm = dynamic
pm.max_children = 25
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 10
pm.max_requests = 500

مقدار pm.max_children را بیش از حد بالا نبرید؛ اگر تعداد پروسه‌ها از RAM موجود بیشتر شود، swap شروع می‌شود و کل سرور کُند می‌شود. قاعده: تعداد children × متوسط مصرف هر پروسه PHP نباید از ۸۰٪ RAM کل عبور کند. فعال بودن OPcache و تنظیم درست opcache.memory_consumption (حداقل ۱۲۸ مگابایت) نیز سرعت اجرای PHP را چند برابر می‌کند. اگر روی نسخه‌های جدید PHP هستید، تفاوت‌های عملکردی چشمگیری با نسخه‌های قبلی خواهید دید؛ مقایسه‌شان در تفاوت PHP 7 و PHP 8 آمده است.

لایه چهارم: دیتابیس

بیشتر اوقات، گلوگاه اصلی سرور، دیتابیس است. سه اقدام با بیشترین اثر:

1. ایندکس‌گذاری صحیح: اگر کوئری‌های کند دارید، با EXPLAIN ببینید ایندکس استفاده می‌شود یا نه. مفهوم ایندکس در ایندکس‌گذاری در MySQL آمده است.
2. تنظیم بافر دیتابیس: innodb_buffer_pool_size باید حدود ۷۰ درصد RAM اختصاصی دیتابیس باشد. اگر کم باشد، دیتابیس مدام از دیسک می‌خواند.
3. پاک‌سازی دوره‌ای: ترنزینت‌ها (transient)، لگ‌ها و ردیف‌های یتیم، به‌مرور دیتابیس را سنگین می‌کنند. روش‌های عملی در پاک‌سازی دیتابیس وردپرس آمده است.

برای سایت‌های وردپرسی، افزونه‌های سئو و ووکامرس به‌طور ویژه‌ای به کوئری‌های سنگین نیاز دارند. اگر سرور فروشگاهی دارید، بهینه‌سازی دیتابیس ووکامرس را جداگانه ببینید.

لایه پنجم: کش درون‌سروری

در سمت سرور، سه نوع کش مطرح است که هر کدام لایه متفاوتی را هدف می‌گیرند:

• کش صفحه: HTML آماده را ذخیره می‌کند. روی هر پلتفرمی، این بزرگ‌ترین برد است.
• کش آبجکت: نتایج کوئری‌های دیتابیس را نگه می‌دارد (Redis یا Memcached). روی سایت‌های داینامیک، تفاوت محسوس است.
• کش OPcache: برای PHP، که در لایه قبل اشاره کردم.

ترکیب این سه لایه کش، در تجربه من روی سایت‌های وردپرسی متوسط، بین ۴۰ تا ۷۰ درصد بهبود TTFB ایجاد می‌کند. اگر مطمئن نیستید از کجا شروع کنید، بهترین افزونه‌های کش وردپرس نقشه عملیاتی خوبی است. مفهوم TTFB و اهمیت آن هم در TTFB چیست و چگونه کاهش می‌یابد آمده است.

کش، جادو نیست؛ فقط اجازه می‌دهد همان منابع موجود، بیشترین کار را انجام دهند.

لایه ششم: I/O دیسک

دیسک، شایع‌ترین گلوگاه مخفی است. یک دیسک HDD قدیمی، حتی با CPU قوی، سرعت سایت را محدود می‌کند چون خواندن دیتابیس یا نوشتن لاگ، صدها بار کندتر از SSD است. اگر سرور شما روی HDD است و I/O بالای ۵۰٪ در پیک است، مهاجرت به SSD یا NVMe انقلابی در تجربه کاربر می‌سازد. اگر روی SSD هستید ولی I/O مصرفی بالاست، دو کار مفید: پاک‌سازی لاگ‌های قدیمی و انتقال پوشه‌های حجیم (uploads، بکاپ‌ها) به یک دیسک یا سرویس جدا (مثل object storage).

لایه هفتم: شبکه و تنظیمات TCP

لایه آخر، تنظیمات شبکه است. برخی از مهم‌ترین تنظیمات:

net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_tw_reuse = 1
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_congestion_control = bbr

فعال کردن الگوریتم BBR برای کنترل ازدحام TCP، در برخی مسیرهای شبکه ایران به خارج، تفاوت محسوسی در کیفیت اتصال ایجاد کرده است. تنظیم tcp_tw_reuse هم به سرور اجازه می‌دهد پورت‌های TIME_WAIT را سریع‌تر آزاد کند. قبل از اعمال این تغییرات، حتماً اسنپ‌شات بگیرید و در محیط تست بیازمایید؛ چون برخی از این تنظیمات در سناریوهای خاص می‌توانند اثر معکوس داشته باشند.

اندازه‌گیری قبل و بعد

هیچ بهبودی بدون اندازه‌گیری معتبر نیست. سه متریک کلیدی که در هر مرحله باید ثبت شوند:

قاعده طلایی من: در هر بار، فقط یک تغییر اعمال کنید و متریک را بگیرید. اگر سه تنظیم را هم‌زمان عوض کنید و نتیجه بهتر شد، نمی‌دانید کدام یک عامل موفقیت بود. اگر نتیجه بدتر شد، نمی‌دانید کدام را برگردانید. مقایسه ابزارهای تست سرعت در بهترین ابزارهای تست سرعت سایت آمده است.

پرسش‌های کوتاه

آیا ارتقای RAM و CPU همیشه لازم است؟ خیر. اگر سقف تنظیمات فعلی را بالا نبرده‌اید، ارتقای RAM فقط مسئله را به تعویق می‌اندازد. اول هفت لایه بالا را بررسی کنید.

آیا باید از LiteSpeed استفاده کنم؟ اگر سایت وردپرسی دارید و هاست شما پشتیبانی می‌کند، LiteSpeed با افزونه‌اش، تفاوت محسوسی در سرعت می‌سازد. اگر روی Nginx هستید و راضی هستید، نیازی به مهاجرت نیست.

تفاوت بهبود سرور با بهبود سرعت سایت چیست؟ بهبود سرور، لایه زیرین است که روی همه سرویس‌ها اثر می‌گذارد. بهبود سرعت سایت، مجموعه اقداماتی است که در بهینه‌سازی سرعت سایت توضیح داده شده و می‌تواند روی سرور، روی قالب یا روی محتوا اعمال شود. مسیر عیب‌یابی سرعت سایت در رفع مشکلات سرعت سایت آمده است.

سخن آخر

بهبود عملکرد سرور، یک پروژه یک‌مرحله‌ای نیست؛ مجموعه‌ای از تصمیم‌های کوچک در هفت لایه مختلف است که هر کدام کمی از بار را از سرور برمی‌دارد. تجربه من می‌گوید بیشترین بازدهی در همان لایه دیتابیس و کش آبجکت است، اما لایه‌های دیگر را نمی‌توان نادیده گرفت چون گاهی گلوگاه درست از همان لایه‌های نادیده می‌آید. اگر امروز فقط یک کار بکنید، فعال کردن OPcache و کش آبجکت (Redis) با بیشترین سود در کمترین زمان است. اگر ماه بعد فرصت داشتید، دیتابیس را بازرسی کنید و کوئری‌های کند را ایندکس کنید. باقی مسیر، تکرار همان چرخه اندازه‌گیری و اصلاح است.

اگر تجربه‌ای دارید که تغییر یک تنظیم کوچک، جهش بزرگی در عملکرد سرور ایجاد کرده، در دیدگاه‌ها بنویسید؛ این نوع نمونه‌ها، از هر مستند فنی برای نفر بعدی مفیدتر است. ⚙️