بهینه سازی وب سرور آپاچی

(1381 مجموع کلمات موجود در متن)
(9545 بار مطالعه شده است)  

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

بسیاری از مدیران سیستم یا شبکه (sys/net admin) توجه چندانی به وب سرور نصب شده برروی شبکه خود ندارند و پس از نصب و راه اندازی اولیه آن را به حال خود رها می‌کنند. از آنجایی که این سرویس دهنده وب به عنوان یکی از سرویس دهندگان محبوب برای پروژه‌هایمختلف اوپن سورس استفاده می شود و بسیاری از کاربران لینوکسنیاز به نصب آن برروی شبکه‌های خود دارند، بر آن شدیم تا مقاله‌ای درباره‌ی روش بهینه سازی وب سرور آپاچی را تهیه و تقدیمتان کنیم.

1. تنطیم آپاچی

سرور وب آپاچی دارای قابلیت تنطیم‌پذیری بسیار بالایی است، ماژول‌های بسیار زیاد و قابلیت‌های فراوان باعث شده تا آپاچی به برنامه‌ای با لیست تنطیمات بسیار زیاد تبدیل شود، این موضوع از سویی مزیت و از سویی می‌تواند در صورت کم توجهی در تنطیمات به خطری برای منابع سیستم مانند حافظه و پردازنده تبدیل شود.

آپاچی سیستمی ماژولار دارد، شما می‌توانید ماژول‌های مختلف را اضافه ویا حذف کنید. هر ماژول امکاناتی را به هسته‌ی اصلی آپاچی اضافه می‌کند. آنچه این قابلیت ماژولار بودن را برای آپاچی فراهم می‌کند MPM یا Multi-Processing Modules نام دارد. MPM اتصالات شبکه را کنترل و درخواست‌های مربوطه را مدیریت می‌کنند. در حال حاضر سه MPM مهم برای آپاچی موجود هستند که زمان کامپایل یا نصب باید یکی از این MPMها را فعال کنید. علاوه بر این آپاچی در هر زمان می‌تواند تنها یکی از این MPMها را فعال کند و نمی‌توانید همزمان دو MPM را فعال کنید.

مدل قدیمی‌تر MPMها «prefork» نام دارد که به ازای هر درخواست یک پروسه (process) ایجاد می‌کند. نوع جدیدتر که از thread ها استفاده می‌کند «worker» نام دارد که از پروسه‌های متعدد یا multiple processها استفاده می‌کند که هر کدام از آن‌ها برای دستیابی به بازدهی بالاتر از تعدادی thread استفاده می‌کنند این کار باعث استفاده هر چه کمتر از منابع سیستم می‌شود. و سومین MPM نیز «event» است که هنوز در مرحله‌ی آزمایش و توسعه است، در این روش از یک مخزن برای threadهایی با کاربردهای مختلف استفاده می‌شود. برای آنکه بدانید آپاچی شما از mpmای استفاده می‌کنید می‌توانید از دستور httpd -l یا apache2 -l استفاده کنید.

انتخاب یک MPM صحیح به فاکتورهای بسیاری وابسته است. این که از چه ماژول‌هایی استفاده می‌کنید، آیا به Threadها نیاز دارید یا خیر، سخت افزار شما و فاکتورهای دیگر می‌تواند در انتخاب شما تاثیر گذار باشد. انتخاب event MPM می‌تواند انتخابی میان fork و thread باشد و با توجه به آزمایشی بودن این mPM برای کارهای عملیاتی نمی‌ةوان چندان از آن بهره برد. اگر به PHP برای سرویس‌هایتان نیاز دارید یکی از بهترین انتخاب‌ها همان MPM قدیمی اما کارامد Prefork است، چرا که Worker در برخی تست‌ها نتایج عجیب و غریبی از خود به جای می‌گذارد. البته در برخی توزیع‌های گنو/لینوکس نصب PHP منوط به نصب apache همراه با Prefork MPM است.

مستقل از MPMای که انتخاب می‌کنید بسیار مهم است که این MPM را چگونه تنطیم می‌کنید. تنطیم نمودن MPM به این معناست که شما از آپاچی می‌خواهید با درخواست‌های متعدد چگونه رفتار کند. در جدول شماره یک می‌توانید لیستی از گزینه‌های مهم در تنطیم Prefork MPM را مشاهده کنید:

StartServers 50 MinSpareServers 15 MaxSpareServers 30 MaxClients 225 MaxRequestsPerChild 4000

جدول شماره ۱

در مدل Prefork به ازای هر درخواست آمده برای آپاچی، یک پروسه ایجاد می‌شود. سروس آپاچی به محض راه اندازی تعدادی پروسه را ایجاد و به صورت idle نگهداری می‌کند تا درخواست‌های آمده از سوی شبکه را بلادرنگ پاسخگویی کند. تعداد این پروسه‌ها در تنطیمات بالا ۵۰ پروسه تعیین شده است. مقدار نهایی این پروسه‌ها در MaxClients نگهداری می‌شود. (این مقدار مقدار hard limit است) بر اساس آنچه در جدول ۱ آمده است آپاچی پروسه‌های بعد از ۴۰۰۰ را قطع می‌کند. (kill) اینکار باعث می‌شود تا از کمبود حافظه یا مصرف شدن ناگهانی حافظه جلوگیری به عمل آید.

برای تنطیم MPMهای بر اساس threadها نیز تئوری همین است و تنها کافیست که بدانید بر اساس حجم شبکه‌ی شما چه تعدادی Thread و Process نیازمند هستید و می‌توانید پاسخگویی کنید. مهم‌ترین مقدار MaxClients است که تعیین می‌کند Worker چه تعداد Thread و پروسه را اجرا کند تا سیستم شما نیازمند استفاده از swap نشود.

در صورتی که مقدار MaxClients بسیار بالا باشد تمام سرویس‌گیرنده‌ها با سرعت پایینی سرویس دهی خواهند شد. کاهش سرعت به این سبب است که آپاچی برای پاسخ‌گویی به تمام درخواست‌های ارسال شده سعی می‌کند یک پروسه را swap کند و سپس برای پروسه‌ی بعدی اجازه‌ی اجرا صادر کند، بدین ترتیب در صورت انتخاب مقدار بسیار بالایی برای MaxClient تمام درخواست‌ها به صورت Swap در آمده و پاسخگویی تنها به پروسه‌های نهایی ممکن خواهد بود و به سایر درخواست‌ها به کندی پاسخ داده خواهد شد.

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

در رابطه با مقادیری که برای سایر گزینه‌ها مانند حداقل و حداکثر تعداد Spare ها تعیین می‌کنید نیز باید این موضوع را مد نظر بگیرید که منابع سیستم شما (پردازنده و حافظه) به چه صورتی مورد استفاده قرار می‌گیرند؟ در صورتی که سرور وب شما (آپاچی) به تنهایی در حال اجرا است می‌توانید از تعداد Spare سرورهای بیشتری استفاده کنید اما در صورتی که از پایگاه‌داده‌ یا سرویسدهنده‌های دیگری نیز استفاده می‌کنید بهتر است تعداد Spare سرورها را محدود کنید.

2. بهره‌وری از قابلیت Override در آپاچی

درخواست‌هایی که برای آپاچی ارسال می شوند در یک چرخه‌ی بسیار پیچیده از تصمیمات قرار می‌گیرند، شما می‌توانید با وضع قوانین ختلف دسترسی به فایل‌ها، دایرکتوری‌ها و یا لیست‌کردن محتویات دایرکتوری‌ها را بر اساس آدرس‌های IP یا فاکتورهای دیگر محدود یا مجاز سازید. علاوه بر این می‌توانید مشخص کید که یک نوع خاص از فایل‌ها چگونه عمل کند. (برای نمونه فایل‌های PHP یا Jpeg ) تمام این تنطیمات در فایل httpd.conf ذخیره می شوند که ممکن است در توزیع‌های مختلف لینوکس و یا نسخه‌های مختلف آپاچی نام آن تغییر کند، برای نمونه در توزیع‌های برپایه‌ی دبیان گنو/لینوکس این فایل apache2.conf یا apache.conf نام دارد. این تنطیمات در مقادیری به نام Container ذخیزه می‌شوند برای نمونه در جدول شماره ۲ کانتینر directory را می‌بینیم:

<Directory /> AllowOverride None Options FollowSymLinks </Directory>

جدول شماره ۲

همان‌طور که در نمونه‌ی مذکور نیز مشاده می‌کنید Container پس از اتمام به صورت Drirectory/ خاتمه می‌یابد. در نمونه‌ی ذکر شده مقدار FollowSymLinks فعال شده است که به سرویس دهنده آپاچی این امکان را می‌دهد تا SoftLinkها یا لینک‌های سمبلیک ^[2] را پیگیری کرده و محتویات آنها را نمایش دهد حتی اگر لینک به محلی خارج از دایرکتوری ریشه یا RootDirectory سرویس دهنده اشاره کند. این بدان معناست که اگر فایلی به مسیر etc/passwd/ اشاره کند قادر خواهد بود از طریق سرور وب به این فایل دسترسی پیدا کند که این می‌تواند مشکل ساز باشد. با استفاده از گزینه FollowSymLinks- می‌توانید جلوی پیگیری لینک‌ها را بگیرید. جلوگیری از این امر نیز خود می‌تواند باعث از دست دادن تعدادی از قابلیت‌ها شود.