NGINX یا آپاچی را بر اساس برنامه، شیوهٔ مدیریت و بار واقعی انتخاب کنید. وب‌سرور نرم‌افزاری است که درخواست HTTP را دریافت و پاسخ را ارائه یا به برنامهٔ پشت‌صحنه منتقل می‌کند. هر دو گزینه می‌توانند بخشی از زیرساخت یک سایت باشند و هیچ‌کدام برای تمام شرایط برندهٔ قطعی نیست.
NGINX یا آپاچی؛ تفاوت معماری
طبق راهنمای NGINX، یک فرایند اصلی و چند فرایند worker وجود دارد و پردازش از مدل رویدادمحور استفاده می‌کند. توصیف کل NGINX به‌عنوان یک رشتهٔ منفرد، تصویر دقیقی از معماری آن نمی‌دهد.
آپاچی نیز فقط مدل «یک فرایند برای هر درخواست» ندارد. ماژول‌های MPM روش مدیریت کار را تعیین می‌کنند؛ برای مثال event MPM بخشی از کار اتصال‌ها را به رشته‌های شنونده منتقل می‌کند تا workerها درخواست‌های دیگر را پردازش کنند. مقایسه باید پیکربندی واقعی را مشخص کند.
تنظیمات و htaccess
در Apache، فایل htaccess می‌تواند تنظیمات مجاز را در سطح پوشه اعمال کند؛ اجازهٔ آن با AllowOverride و تنظیمات مرتبط تعیین می‌شود. این قابلیت برای برخی محیط‌های اشتراکی و برنامه‌های موجود مهم است، اما همهٔ دستورها در آن مجاز نیستند.
NGINX فایل htaccess را اجرا نمی‌کند. قواعد بازنویسی، دسترسی و مسیر برنامه باید به تنظیم سازگار آن منتقل شوند. کپی کردن فایل جوملا یا وردپرس به سرور NGINX به‌تنهایی معادل انتقال قواعد نیست. تعداد فایل‌های تنظیم نیز همیشه دو فایل یا کمتر نیست و به ساختار include وابسته است.
اجرای PHP و برنامه‌های پویا
NGINX می‌تواند درخواست را از طریق FastCGI به PHP-FPM بدهد یا به سرور برنامه پراکسی کند. Apache نیز با ماژول مناسب یا پردازشگر بیرونی کار می‌کند. بنابراین Apache بدون پیکربندی، مفسر داخلی تمام زبان‌های برنامه‌نویسی نیست.
mod_proxy آپاچی قابلیت پراکسی و همراه ماژول‌های مرتبط، توزیع بار را فراهم می‌کند. پراکسی معکوس فقط ویژگی NGINX نیست؛ محل استقرار و دسترسی سرویس پشتی نیز باید در طراحی شبکه مشخص شود.
مقایسه برای پروژهٔ واقعی
| شرایط | نکتهٔ تصمیم |
|---|---|
| وابستگی به htaccess | در Apache قواعد مجاز را بررسی کنید؛ در NGINX تبدیل و آزمون لازم است |
| برنامهٔ PHP | نسخه، تعداد workerهای PHP-FPM و محدودیت حافظه مهم‌اند |
| پراکسی جلوی برنامه | هر دو قابلیت مرتبط دارند؛ تنظیم و مهارت تیم تعیین‌کننده است |
| کنترل‌پنل میزبانی | پیکربندی پشتیبانی‌شدهٔ پنل را مبنا قرار دهید |
عملکرد را چگونه بسنجیم؟
روی محیط مجاز، همان برنامه، منابع و شرایط کش را مقایسه کنید. زمان پاسخ، نرخ خطا، مصرف CPU و حافظه را در کنار تعداد درخواست موفق ثبت کنید. نتیجهٔ یک فایل استاتیک را به کل فروشگاه یا صفحهٔ پویا تعمیم ندهید.
ادعای «همیشه ۲٫۵ برابر سریع‌تر» بدون روش آزمون معتبر نیست. همچنین نام وب‌سرور به‌تنهایی رتبهٔ گوگل را بهتر نمی‌کند. اگر مشکل از کوئری پایگاه داده یا اسکریپت مرورگر باشد، تعویض وب‌سرور ممکن است اثر اندکی داشته باشد.
برای مهاجرت، مسیرها، ریدایرکت‌ها، فایل‌های خصوصی، HTTPS و پاسخ‌های خطا را پیش از انتقال نهایی آزمایش کنید. سازگاری و نگهداری قابل اتکا از انتخاب بر اساس یک نمودار قدیمی مهم‌تر است.
مطالعهٔ مرتبط
بازبینی فنی: ۱۳ آبان ۱۴۰۵. تاریخ انتشار اولیه و نشانی قبلی حفظ شده‌اند.
