وب‌سرور چیست و کدام یکی برای سایت شما مناسب است؟
وب‌سرور اولین برنامه‌ای است که درخواست کاربر به آن می‌رسد. انتخاب و تنظیم درست آن، یکی از کم‌هزینه‌ترین راه‌های بهبود زمان پاسخ است.
وب‌سرور دقیقاً چه می‌کند؟
وقتی کاربر آدرسی را باز می‌کند، درخواست او ابتدا به وب‌سرور می‌رسد. وب‌سرور تصمیم می‌گیرد که پاسخ را از فایل ثابت بدهد، از کش بردارد، یا آن را به مفسر برنامه (مثلاً PHP) بسپارد و نتیجه را برگرداند.
همین جملهٔ آخر مهم‌ترین نکتهٔ این مقاله را در خود دارد: برای صفحه‌ای که باید توسط PHP ساخته شود، وب‌سرور فقط پیام‌رسان است. زمانی که کاربر منتظر می‌ماند، عمدتاً در PHP و دیتابیس می‌گذرد، نه در وب‌سرور.
مقایسهٔ سه گزینهٔ رایج
| وب‌سرور | نقطهٔ قوت | نکته |
|---|---|---|
| Nginx | مصرف حافظهٔ کم و رسیدگی خوب به اتصال‌های هم‌زمان زیاد | برای برخی تنظیمات به پیکربندی دستی بیشتری نیاز دارد. |
| LiteSpeed | سازگاری با تنظیمات Apache و لایهٔ کش داخلی | نسخهٔ تجاری آن لایسنس دارد. |
| Apache | انعطاف بالا و اکوسیستم ماژول بسیار گسترده | در اتصال‌های هم‌زمان زیاد معمولاً حافظهٔ بیشتری می‌گیرد. |
نام‌ها متعلق به سازندگانشان است و اینجا توصیفی به کار رفته‌اند.
چیزی که بیشتر از نام وب‌سرور اثر دارد
تیم‌ها معمولاً وب‌سرور را عوض می‌کنند و انتظار جهش می‌کشند و نمی‌گیرند. دلیلش این است که در بیشتر سایت‌های کند، گلوگاه جای دیگری است:
| لایه | چرا معمولاً مهم‌تر است |
|---|---|
| کش صفحه | صفحه‌ای که از کش جواب می‌گیرد اصلاً به PHP و دیتابیس نمی‌رسد. بزرگ‌ترین بهبود ممکن، تقریباً همیشه همین‌جاست. |
| کوئری‌های دیتابیس | یک کوئری بدون ایندکس می‌تواند کل صفحه را کند کند، مستقل از اینکه کدام وب‌سرور جلوی آن است. |
| تعداد فرایندهای PHP | اگر همهٔ فرایندها مشغول باشند، درخواست بعدی در صف می‌ماند. این عدد باید با حافظهٔ واقعی سرور هماهنگ باشد. |
| وب‌سرور | وقتی سه مورد بالا درست باشند، تفاوت وب‌سرورها در اتصال‌های هم‌زمان بسیار زیاد خودش را نشان می‌دهد. |
پس کِی تعویض ارزش دارد؟
- وقتی تعداد اتصال‌های هم‌زمان بالاست و سرور زیر فشار حافظه است — اینجا معماری وب‌سرور واقعاً تفاوت می‌سازد.
- وقتی به قابلیتی نیاز داری که فقط یکی دارد: لایهٔ کش داخلی، یک ماژول خاص، یا سازگاری با پیکربندی موجود.
- وقتی سرور زیادی از منابعش را صرف خودِ وب‌سرور می‌کند و می‌خواهی آن را به اپلیکیشن برگردانی.
و کِی ارزش ندارد: یک هفته مانده به کمپین فروش. تعویض وب‌سرور یعنی همهٔ قواعد بازنویسی، گواهی‌ها و تنظیمات کش دوباره آزمایش شوند. قبل از کمپین وقت تثبیت است، نه تغییر.
بعد از هر تغییر، این چند چیز را ببین
- صفحه‌های غیرکش‌شده هنوز درست کار می‌کنند؟ سبد خرید و صفحهٔ حساب کاربری را دستی باز کن.
- قواعد بازنویسی و ریدایرکت‌ها منتقل شده‌اند؟ آدرس‌های قدیمی هنوز باید به همان‌جای قبلی بروند.
- گواهی SSL روی همهٔ دامنه‌ها و زیردامنه‌ها سر جایش است؟
- لاگ خطا را چند ساعت اول بخوان. مشکلات این دسته معمولاً در همان اولین ساعت‌ها دیده می‌شوند.
مطالب مرتبط
این مطلب بخشی از راهنمای مدیریت سرور است.
