چگونه به PHP-FPM رسیدیم؟

تخصص DevOps، مفاهیم جالب و جذابی را در بردارد که گاهی بسیاری از توسعه دهندگان علاقه مند به مطالعه ی برخی مطالب آن می شوند. یکی از این مفاهیم، PHP-FPM است. در مورد مفهوم و استفاده از PHP-FPM یک سردرگمی ای وجود دارد که باعث شد ما بخواهیم برخی از مفاهیم اساسی آن را بررسی کرده و در اختیار علاقه مندان قرار دهیم. در این مقاله قصد داریم روندی که طی شد تا به PHP-FPM برسیم را برایتان شرح دهیم.

دانش پایه

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

وب سرور (Web Server)

وب سرور نرم افزار و سخت افزاری است که با استفاده از HTTP (Hypertext Transfer Protocol) و سایر پروتکل ها برای پاسخ به درخواست های مشتری که از طریق شبکه جهانی وب انجام می شود، استفاده می کند. وظیفه اصلی یک وب سرور نمایش محتوای وب سایت از طریق ذخیره سازی، پردازش و تحویل صفحه های وب به کاربران است. جهت آشنایی کامل با وب سرور، می توانید به آموزش آشنایی با وب سرور و نحوه عملکرد آن، در سکان آکادمی مراجعه نمایید.

Worker

در وب سرور آپاچی سه ماژول پردازش موازی وجود دارد که بر اساس رویکردهای چند پردازه ای (multi-process) و چند رشته ای (multi-threaded) کار می کنند. این ماژول ها نمی توانند به صورت همزمان فعال باشند و فقط یکی از آن ها می تواند فعال باشد یکی از این ماژول ها Worker نام دارد. پیشنهاد می کنیم برای آشنایی بیشتر با worker ها، مقاله ی ماژول های پردازش موازی در وب سرور آپاچی که در سکان آکادمی وجود دارد را مطالعه فرمایید.

ماژول PHP برای وب سرور

mod_php، به عنوان یک ماژول برای وب سرور آپاچی است. با این ماژول PHP در وب سرور، ادغام می شود. بنابراین هیچ PHP-Process اضافی وجود ندارد که تفسیر PHP را مدیریت کند. در عوض همه چیز توسط پردازش های آپاچی مدیریت می شود.

شرح ماجرا

زمانی که مرورگر، درخواستی را به یک سرور ارسال می کند، این PHP نیست که نقطه اول تماس را تشکیل می دهد؛ بلکه، سرور HTTP است، که اصلی ترین آن ها Apache و Nginx هستند. "سرورهای وب" باید تصمیم بگیرند که چگونه به PHP وصل شوند و نوع درخواست، داده ها و هدر ها را به آن منتقل کنند.

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

بنابراین، هر زمان که یک درخواست دریافت می شد، سرور یک فرایند جدید را شروع می کرد، که به طور خودکار شامل PHP بود و آن را اجرا می کرد. این روش mod_php (PHP as a module به معنی "PHP به عنوان یک ماژول") نامیده می شد. این روش محدودیت هایی داشت که وب سرور با PHP-FPM بر آن غلبه کرد. در ادامه به این می پردازیم که چه شده که از mod_php به FPM رسیدیم

CGI

Common Gateway Interface (CGI)، پروتکلی برای اتصال و انتقال اطلاعات برنامه های خارجی به سرورهای وب است. برنامه های CGI در پردازش های جداگانه ای اجرا می شوند که در ابتدای هر درخواست پردازش ایجاد و در پایان حذف می شوند. مدل "یک پردازش (Process) جدید برای هر درخواست"، اجرای برنامه های CGI را بسیار ساده کرده، اما کارایی و مقیاس پذیری را محدود می کند.

در اصل روشی برای اجرای یک اسکریپت سمت سرور (PHP، Perl، Python) است، وقتی اسکریپ سمت سرور، PHP باشد، با عنوان PHP-CGI خوانده می شود.

نحوه ی کار CGI

اجرای PHP به عنوان یک CGI به این معنی است که شما به وب سرور خودتان، محل فایل اجرایی PHP را می گویید و سرور آن فایل اجرایی را اجرا می کند و هر بار که از صفحه ای بازدید می کنید اسکریپتی را که فراخوانی کرده اید به آن می دهد. یعنی هر بار که صفحه ای را بارگذاری می کنید، PHP باید php.ini را بخواند و تنظیمات آن را انجام دهد و باید تمام برنامه های افزودنی خود را بارگیری کند، سپس کار تجزیه اسکریپت را شروع کند. در حقیقت کارهای تکراری زیادی وجود دارد که باید انجام دهد.

در واقع با استفاده از CGI می توان به ازای هر درخواست یک اسکریپت php جداگانه تعریف کرد و تمام تنظیمات و افزودنی ها را از آن جدا کرد. از این قابلیت در هاست های اشتراکی که در آن محصولات مختلف می خواهند با ورژن های مختلفی از PHP کار کنند استفاده می شود.

یکی از مزایای اجرای برنامه ها بر روی CGI این است که اجرای کد را جدا از وب سرور نگه می دارد که برخی از مزایای امنیتی دیگری را نیز شامل می شود. برای مثال، یک اسکریپت PHP مخرب که از طریق PHP-CGI اجرا می‌شود، نمی‌تواند امنیت سایر فایل های خارج از دامنه ای را که در آن میزبانی می‌شود، خراب کند یا بر آن تاثیر بگذارد. همچنین به این معنی است که مفسر PHP فقط در صورت نیاز فراخوانی می‌شود، در نتیجه به محتوای استاتیک اجازه می‌دهد که فقط توسط وب سرور ارائه شود.

ناکارآمدی CGI

مزیت اصلی استفاده از CGI، جداسازی کامل کد وب سرور اجرا کننده و کد PHP است. با این که امنیت CGI بهتر است چون اجرای کد PHP از وب سرور جدا شده است اما نقص هایی دارد زیرا در load های بالا، سربار سیستم عامل برای ایجاد و تخریب پردازش، قابل توجه می شود. همچنین، مدل فرآیند CGI، روش‌های استفاده مجدد (Reusability) از منابع را محدود می‌کند، مانند استفاده مجدد از اتصالات پایگاه داده، کش در حافظه و غیره.

ناکارآمدی اجرای PHP با پشتیبانی CGI از آن جا ناشی شد که نیاز بود یک پردازش جدید در هر بار اجرای هر کد PHP، ایجاد شود. همان طور که می توانید تصور کنید، در سایت های شلوغ تر یا برنامه های کاربردی مبتنی بر PHP می تواند منابع بسیار زیادی را درگیر کند.

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

سربار درگیر در ایجاد و تخریب پردازش CGI را می توان با روش هایی کاهش داد که یکی از آن ها FastCGI می باشد.

FastCGI

همان طور که پیش تر توضیح دادیم، CGI، محدودیت هایی دارد. برای رفع کاستی های مقیاس پذیری CGI، پروتکلی به نام FastCGI را توسعه داده شد.

FastCGI یک پیاده سازی PHP است که حاوی مزایای امنیتی CGI است اما مانند mod_php نیز کارآمد است. در این جا ما یک پردازش PHP جدید را برای هر درخواست شروع نمی‌کنیم، در عوض از نمونه های مفسر PHP آماده، استفاده می‌کنیم که فقط فایل‌های PHP را دریافت می‌کنند تا مدیریت شوند.

هدف اصلی FastCGI کاهش هزینه های سربار مربوط به رابط بین وب سرور و برنامه های CGI است و به سرور اجازه می دهد تا درخواست های صفحه های وب بیشتری را در واحد زمان انجام دهد.

FastCGI بعد از مدتی توسط چندین سازنده وب سرور دیگر نیز پیاده سازی شد. ماژول های Apache HTTP Server مانند mod_perl و mod_php تقریبا در همان زمان ظاهر شدند و به سرعت محبوبیت یافتند

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

PHP-FPM

FPM در PHP مخفف FastCGI Process Manager است و مدیریت پردازش های FastCGI را بر عهده دارد. تفاوت عملیاتی زیادی بین آن و FastCGI وجود ندارد و فقط برای آسان کردن اجرای آن است.

وب سایت هایی که برای استفاده از PHP-FPM پیکربندی شده اند می توانند حجم بیشتری از ترافیک وب سایت را مدیریت کنند در حالی که از منابع سرور کمتری نسبت به سایر کنترل کننده های PHP استفاده می کنند. این کار، مدیون معماری و ویژگی های PHP-FPM است.

PHP-FPM الگوی کاری بسیار خوبی دارد که از نظر بارگذاری و جمع آوری داده ها از پایگاه های داده و سایت هایی با ترافیک سنگین و شلوغ، بسیار مفید است.

عملکرد PHP-FPM

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

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

همان طور که PHP-FPM یک اتصال پروکسی دریافت می کند، یک worker آزاد PHP-FPM، درخواست وب سرور را می پذیرد. سپس PHP-FPM اسکریپت PHP را کامپایل و اجرا می کند و خروجی را به وب سرور ارسال می کند. هنگامی که یک worker PHP-FPM رسیدگی به یک درخواست را تمام کرد، سیستم، worker را آزاد می کند و منتظر درخواست های جدید می ماند.

توجه داشته باشید، همیشه (حداقل) یک پردازش گر PHP-FPM که به صورت موازی با پردازش های دیگر رفتار می کند داریم که تفسیر PHP را مدیریت می کند. پردازش های FPM که همان Worker ها هستند به استخر های (pools) مختلف گروه بندی می شوند. در این استخرها معمولا چند پردازش ایجاد می شود که تفسیر PHP را برای یک صفحه ی وب خاص انجام می دهد.

نتیجه

PHP-FPM، یک روش کارآمد در مورد چگونگی به حداقل رساندن مصرف حافظه و افزایش عملکرد وب سایت های دارای ترافیک زیاد است. این روش به طور قابل توجهی سریع تر از روش های سنتی مبتنی بر CGI در محیط های PHP چند کاربر است. بنابراین، می توان نتیجه گرفت که PHP-FPM از نظر نقض داده، ایمن است.

به دلیل انعطاف پذیری و سازگاری به عنوان یک ویژگی، همه منابع را به طور کارآمد مدیریت می کند. اگر هدف اصلی شما از میزبانی برنامه وب، دستیابی به عملکرد و امنیت مطلوب است، PHP-FPM، راه پیش روی شما است.

در مقاله های بعدی درباره ی نحوه ی نصب و استفاده از FPM ، آموزش خواهیم داد.