LiteSpeed در برابر Nginx و Apache برای سرور هاستینگ

مقایسه معماری LiteSpeed، Nginx و Apache برای سرور هاستینگ: مدل همزمانی، پشتیبانی htaccess، کش LSCache و هزینه مهاجرت از Apache.

وقتی یک سرور هاستینگ راه می‌اندازید، انتخاب وب‌سرور تصمیمی نیست که هر شش ماه عوضش کنید. معماری وب‌سروری که انتخاب می‌کنید تعیین می‌کند سرور زیر بار همزمانی بالا چطور رفتار کند، مشتری‌ها چقدر آزادی برای تنظیم سایت خودشان داشته باشند و شما چند تیکت پشتیبانی در هفته باز کنید. Apache، Nginx و LiteSpeed هر سه کارشان سرو کردن HTTP است، اما سه فلسفه کاملاً متفاوت دارند.

این مقایسه از دید کسی نوشته شده که یک سرور هاستینگ اشتراکی یا یک VPS با چند ده سایت را مدیریت می‌کند، نه از دید کسی که یک اپلیکیشن تک‌مستأجره روی سرور اختصاصی دارد. این تفاوت دید مهم است، چون بخش زیادی از مزیت‌ها و معایب فقط در سناریوی چند‌مشتری خودشان را نشان می‌دهند.

Apache: مدل پردازش به ازای هر اتصال

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

نتیجه‌اش قابل پیش‌بینی است: تا وقتی تعداد اتصال‌های همزمان پایین است همه‌چیز خوب کار می‌کند، اما با بالا رفتن همزمانی، مصرف رم تقریباً خطی بالا می‌رود. روی سروری که چند صد اکانت دارد و هر اکانت هم چند اتصال باز نگه می‌دارد، MaxRequestWorkers خیلی زود تبدیل به گلوگاه می‌شود. وقتی به سقف می‌رسید، درخواست‌های بعدی صف می‌شوند و کاربر تایم‌اوت می‌بیند، در حالی که CPU سرور شاید نصف هم مشغول نباشد.

می‌توانید وضعیت فعلی را همیشه با mod_status ببینید:

apachectl -M | grep -E 'mpm|status'
apachectl status

# مصرف رم به ازای هر پروسه apache
ps -ylC httpd --sort:rss | awk '{sum+=$8; n++} END {print sum/n/1024 " MB avg", n " procs"}'

در مقابل، دو چیز Apache را بعد از این همه سال زنده نگه داشته: اکوسیستم ماژول‌هایش و پشتیبانی از htaccess. تقریباً هر قابلیتی که فکرش را بکنید یک ماژول Apache دارد و تقریباً هر آموزش وردپرسی که مشتری شما در اینترنت پیدا می‌کند با یک قطعه کد htaccess تمام می‌شود.

Nginx: رویدادمحور و سریع، اما بی‌خیال htaccess

Nginx از ابتدا برای حل همان مشکل همزمانی نوشته شد. به جای یک پروسه به ازای هر اتصال، تعداد کمی worker process دارد که هرکدام هزاران اتصال را با یک event loop غیرمسدودکننده مدیریت می‌کنند. یک worker می‌تواند همزمان تعداد زیادی اتصال را با مصرف رم تقریباً ثابت نگه دارد، در حالی که در Apache همان تعداد اتصال به همان تعداد پروسه یا ترد و در نتیجه مصرف رمی که با همزمانی بالا می‌رود ترجمه می‌شود.

برای فایل استاتیک، ریورس‌پروکسی و ترمینیت کردن TLS واقعاً عالی است. اما یک تصمیم طراحی دارد که در هاستینگ اشتراکی دردسر می‌شود: Nginx فایل htaccess را نمی‌خواند و اصلاً قرار نیست بخواند. سازنده‌اش این را عمداً حذف کرده، چون خواندن فایل کانفیگ از دیسک در هر درخواست و در هر دایرکتوری مسیر، دقیقاً همان چیزی است که کارایی را پایین می‌آورد.

منطقی است، ولی معنی‌اش این است که هر قانون rewrite، هر redirect، هر محافظت از wp-login و هر تنظیم expires باید داخل کانفیگ اصلی Nginx بیاید و بعد از هر تغییر هم reload لازم است. روی سروری با یک سایت این هیچ مشکلی نیست. روی سروری با سیصد اکانت مشتری، یعنی مشتری دیگر نمی‌تواند تنظیمات خودش را عوض کند و هر تغییر کوچک تبدیل به یک تیکت برای شما می‌شود.

چرا در هاستینگ اشتراکی htaccess اهمیت دارد

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

• افزونه‌ها: بخش بزرگی از افزونه‌های امنیتی، کش و ریدایرکت وردپرس مستقیم داخل htaccess می‌نویسند. بدون آن، دکمه ذخیره افزونه کار می‌کند ولی هیچ اتفاقی نمی‌افتد.
• مهاجرت: مشتری که از یک هاست cPanel دیگر می‌آید، بکاپ خودش را با htaccess موجود ری‌استور می‌کند و انتظار دارد همان‌طور کار کند.
• حجم تیکت: هر قانونی که مشتری خودش نتواند اعمال کند، به یک درخواست پشتیبانی تبدیل می‌شود که شما باید دستی و با reload کل وب‌سرور انجامش بدهید.
• ریسک: ویرایش کانفیگ مرکزی برای یک مشتری یعنی یک syntax error می‌تواند سرویس همه مشتری‌ها را قطع کند.

راه‌حل‌های رایج هم هرکدام هزینه خودشان را دارند. یکی این است که Nginx را جلو بگذارید و Apache را پشت آن نگه دارید تا htaccess همچنان کار کند؛ این یعنی دو وب‌سرور برای نگهداری، دو لایه لاگ و مصرف رم Apache که همچنان سر جایش است. راه دیگر ابزارهای تبدیل خودکار htaccess به کانفیگ Nginx است که برای قوانین ساده جواب می‌دهد و روی قوانین پیچیده به‌سادگی چیزی را خراب می‌کند.

LiteSpeed: معماری رویدادمحور به‌علاوه سازگاری با Apache

LiteSpeed دقیقاً برای پر کردن همین شکاف ساخته شده. هسته‌اش مثل Nginx رویدادمحور است و تعداد کمی پروسه، تعداد زیادی اتصال همزمان را نگه می‌دارد. اما برخلاف Nginx، فایل htaccess را می‌خواند و بخش عمده دستورهای رایج Apache و همچنین mod_rewrite را می‌فهمد.

از دید عملیاتی این یعنی ساختار دایرکتوری‌ها، virtual hostها و فایل‌های htaccess مشتری‌ها همان‌طور که هستند می‌مانند و شما فقط لایه‌ای که درخواست را پردازش می‌کند عوض می‌کنید. برای یک سرور هاستینگ که سال‌هاست روی Apache می‌چرخد، این تفاوت بین «یک تغییر قابل برگشت در یک بازه نگهداری» و «یک پروژه مهاجرت چند هفته‌ای» است.

تفاوت دوم در نحوه اجرای PHP است. LiteSpeed از LSAPI استفاده می‌کند که هر اکانت را می‌تواند با یوزر خودش اجرا کند و پروسه‌های PHP هر مشتری از هم جدا بمانند. برای هاستینگ اشتراکی، این جداسازی هم از نظر امنیتی مهم است و هم برای اینکه یک سایت پرمصرف نتواند کل استخر PHP سرور را قفل کند.

LSCache در برابر افزونه‌های کش در سطح PHP

مهم‌ترین تفاوتی که در عمل خودش را نشان می‌دهد، جای کش است. یک افزونه کش معمولی وردپرس در سطح PHP کار می‌کند: درخواست به وب‌سرور می‌رسد، PHP بالا می‌آید، وردپرس لود می‌شود، افزونه کش تشخیص می‌دهد که نسخه کش‌شده وجود دارد و آن را برمی‌گرداند. یعنی حتی برای یک صفحه کاملاً کش‌شده هم مفسر PHP اجرا شده است.

در LiteSpeed کش داخل خود وب‌سرور است. درخواستی که به کش می‌خورد اصلاً به PHP نمی‌رسد و مثل یک فایل استاتیک از حافظه سرو می‌شود. روی یک سرور اشتراکی که ده‌ها سایت وردپرسی دارد، همین یک تفاوت باعث می‌شود اسپایک ترافیکی روی یک سایت، پروسه‌های PHP بقیه سایت‌ها را قحطی‌زده نکند.

افزونه LSCache روی وردپرس عملاً فقط نقش کنترل‌کننده دارد: به وب‌سرور می‌گوید کدام صفحه‌ها کش شوند، چه مدت، و چه زمانی باطل شوند؛ خود ذخیره و سرو کردن کار وب‌سرور است. همین باعث می‌شود پاک شدن کش بعد از انتشار پست یا آپدیت محصول درست کار کند، بدون اینکه هزینه بوت شدن وردپرس در هر درخواست را بدهید.

یک نکته کاربردی: هدرهای کش را همیشه چک کنید، چون تنظیم اشتباه باعث می‌شود صفحه‌های لاگین‌شده یا سبد خرید هم کش شوند.

curl -sI https://example.com/ | grep -i -E 'x-litespeed-cache|cache-control|vary'

# مقایسه زمان پاسخ کش‌خورده و کش‌نخورده
curl -o /dev/null -s -w 'ttfb: %{time_starttransfer}s\n' https://example.com/

مقایسه در یک نگاه

• مدل همزمانی: Apache پروسه/ترد به ازای اتصال؛ Nginx و LiteSpeed رویدادمحور با تعداد ثابت worker.
• htaccess: Apache بله، LiteSpeed بله، Nginx خیر.
• کش صفحه: Apache و Nginx به کش بیرونی یا افزونه PHP نیاز دارند؛ LiteSpeed کش را داخل خودش دارد.
• سازگاری با کانفیگ موجود: جابه‌جایی از Apache به LiteSpeed معمولاً بدون بازنویسی کانفیگ انجام می‌شود؛ رفتن به Nginx نیازمند بازنویسی قوانین است.
• هزینه: Apache و Nginx رایگان‌اند؛ LiteSpeed Enterprise لایسنس می‌خواهد.

اگر سرور هاستینگ شما روی cPanel است و می‌خواهید بدون تغییر ساختار مشتری‌ها به معماری رویدادمحور برسید، لایسنس LiteSpeed کوتاه‌ترین مسیر است؛ لایسنس روی آی‌پی سرور شما فعال می‌شود و آپدیت‌ها مستقیم از سرورهای خود LiteSpeed دریافت می‌شود.

هزینه مهاجرت از Apache

روی یک سرور cPanel، LiteSpeed به عنوان جایگزین Apache نصب می‌شود و همان فایل‌های کانفیگ cPanel را می‌خواند. یعنی virtual hostها، مسیر دایرکتوری‌ها، گواهی‌های SSL و htaccessها دست‌نخورده می‌مانند. سوییچ برگشت‌پذیر است و اگر مشکلی دیدید می‌توانید به Apache برگردید؛ همین برگشت‌پذیری است که ریسک را پایین می‌آورد.

با این حال چند نکته را قبل از تغییر بررسی کنید:

• ماژول‌های غیراستاندارد: اگر روی Apache ماژول خاصی نصب کرده‌اید، معادلش را در LiteSpeed چک کنید. ماژول‌های رایج مثل mod_security و mod_rewrite پشتیبانی می‌شوند، اما ماژول‌های نادر ممکن است معادل نداشته باشند.
• هندلرهای PHP: اگر از تنظیمات خاص PHP-FPM استفاده می‌کنید، بعد از سوییچ باید معادل LSAPI را بررسی کنید.
• افزونه‌های کش موجود: قبل از فعال کردن LSCache روی سایت‌ها، افزونه‌های کش قبلی باید غیرفعال شوند وگرنه دو لایه کش با هم تداخل می‌کنند.
• ساعت انجام کار: سوییچ کوتاه است اما بی‌وقفه نیست؛ آن را در کم‌ترافیک‌ترین بازه انجام دهید و قبلش از کانفیگ‌ها بکاپ بگیرید.

اگر هنوز در مرحله انتخاب سرور هستید و می‌خواهید قبل از اعمال تغییر روی سرور اصلی، سناریو را روی یک محیط تست بالا بیاورید، یک سرور مجازی ایران در دیتاسنتر رسپینا برای شبیه‌سازی همان استک کافی است و تحویل آن آنی است.

کدام را انتخاب کنید

اگر یک اپلیکیشن تک‌مستأجره دارید که کانفیگش را خودتان می‌نویسید و کش را در لایه بالاتر مدیریت می‌کنید، Nginx انتخاب کاملاً درستی است و دلیلی برای پرداخت هزینه لایسنس ندارید. اگر سروری دارید که تعداد کمی سایت روی آن است و بار همزمانی بالایی هم ندارد، Apache همچنان کار می‌کند و ساده‌ترین گزینه از نظر نگهداری است.

اما اگر سرور هاستینگ اشتراکی با چند ده تا چند صد اکانت دارید، مشتری‌ها وردپرس اجرا می‌کنند و انتظار دارند htaccess کار کند، و همزمان مصرف رم سرور شما را اذیت می‌کند، LiteSpeed دقیقاً همین ترکیب را هدف گرفته است. مزیت اصلی‌اش نه صرفاً سرعت خام، بلکه این است که مزیت معماری رویدادمحور را بدون شکستن انتظارات مشتری‌های Apache به شما می‌دهد.

در کنار وب‌سرور، بقیه استک سرور هاستینگ هم لایسنس می‌خواهد؛ فهرست کامل لایسنس‌های هاستینگ اشتراکی شامل CloudLinux برای محدودسازی منابع هر اکانت و JetBackup برای بکاپ‌گیری است که معمولاً کنار هم روی یک سرور استفاده می‌شوند.

جمع‌بندی

تفاوت این سه وب‌سرور به یک انتخاب معماری برمی‌گردد: Apache انعطاف‌پذیری و سازگاری را به قیمت مصرف منابع می‌دهد، Nginx کارایی را به قیمت کنار گذاشتن htaccess، و LiteSpeed سعی می‌کند هر دو را داشته باشد و برای همین لایسنس می‌خواهد. در محیط تک‌سایتی معمولاً Nginx کافی است؛ در هاستینگ اشتراکی، htaccess و کش داخل وب‌سرور دو چیزی هستند که مستقیماً روی حجم تیکت‌های پشتیبانی و پایداری سرور اثر می‌گذارند.

قبل از هر تغییری وضعیت فعلی سرور را اندازه بگیرید: مصرف رم پروسه‌های وب‌سرور، تعداد اتصال همزمان در ساعت اوج و اینکه چند درصد درخواست‌ها اصلاً به PHP می‌رسند. اگر گلوگاه شما اجرای PHP روی صفحه‌های تکراری است، بیشترین سود را از کش سطح وب‌سرور می‌گیرید. اگر گلوگاه رم است، مدل رویدادمحور جواب می‌دهد. برای سوال درباره لایسنس و فعال‌سازی روی آی‌پی سرور، پشتیبانی ۲۴ ساعته در شماره ۰۲۱-۷۹۷۰۳ در دسترس است.