https://virgool.io/feed/@alighasempoor3 fa 2026-07-08 00:41:59 https://files.virgool.io/upload/users/68699/avatar/Emltb1.jpg?height=120&width=120 https://virgool.io/@alighasempoor3 https://virgool.io/codenevis/%D8%A7%D8%AC%D8%B1%D8%A7%DB%8C-php-%D8%AA%D9%88%D8%B3%D8%B7-application-server-kdrkokbnie0n در سال‌های اخیر، اجرای PHP وارد فاز جدیدی شده و با ظهور application serverهایی مانند FrankenPHP، مسیر اجرای کد PHP به‌صورت مستقیم و مستقل از وب‌سرورهای سنتی ممکن شده است. application serverها برخلاف مدل‌های سنتی که PHP فقط نقش مفسر سمت سرور را دارد، یک لایه‌ی ترکیبی بین وب‌سرور، زبان برنامه‌نویسی و مدیریت درخواست‌ها فراهم می‌کنند. در این مدل، خود application server توانایی دریافت درخواست HTTP، اجرای کد PHP و ارسال پاسخ را بدون وابستگی به Apache یا Nginx دارد.در روش سنتی، وب‌سرور مسئول دریافت درخواست و forward کردن آن به مفسر PHP است، اما در application server، همه‌چیز به‌شکل یکپارچه اجرا می‌شود. این یکپارچگی مزایایی مانند راه‌اندازی ساده‌تر، latency پایین‌تر، و قابلیت‌های داخلی برای هندل درخواست‌ها، static file serving، و حتی hot reload را فراهم می‌کند.از نظر معماری، application serverها معمولاً با الگوی multi-threaded طراحی می‌شوند، به این معنا که به‌جای ایجاد process جداگانه برای هر درخواست (مانند PHP-FPM)، از چندین thread درون یک process مشترک استفاده می‌شود. این مدل باعث کاهش چشمگیر مصرف منابع و افزایش سرعت پاسخ‌گویی به درخواست‌های هم‌زمان می‌شود، چرا که ایجاد و مدیریت thread بسیار سبک‌تر از process است و امکان اشتراک حافظه و منابع بین threadها نیز وجود دارد.سرور همه‌کاره FrankenPhp برای اجرای PHPسرور Franken PHP نسل جدیدی از سرورهای اجرای PHP است که برای ساده‌سازی فرایند اجرای برنامه‌های PHP طراحی شده. برخلاف روش‌های سنتی که به نصب و تنظیم جداگانه‌ی PHP، وب‌سرور (مانند Apache یا Nginx) و PHP-FPM نیاز دارند، FrankenPHP همه‌ی این اجزا را به‌صورت یکپارچه در یک فایل باینری واحد ترکیب کرده است. این باینری شامل PHP به‌شکل embed شده، وب‌سرور Caddy و پشتیبانی داخلی از HTTPS است؛ در نتیجه می‌توان تنها با اجرای یک فایل، یک محیط کامل برای اجرای PHP در اختیار داشت.هدف FrankenPHP کاهش پیچیدگی در راه‌اندازی، افزایش کارایی و تسهیل deployment است، به‌خصوص در محیط‌هایی مثل Docker که سادگی و سبکی اهمیت بالایی دارد. با اجرای مستقیم کد PHP درون process سرور، نیازی به ایجاد یا مدیریت processهای خارجی (مثل PHP-FPM) نیست و زمان پاسخ‌دهی به درخواست‌ها کاهش می‌یابد. این ابزار همچنین با پشتیبانی از قابلیت‌هایی مثل Hot Reload و اجرای background taskها، خود را به‌عنوان یک گزینه‌ی آینده‌دار و جذاب در اکوسیستم PHP معرفی کرده است.Blocking vs non-blocking processدر مدل blocking مانند PHP-FPM، هر درخواست توسط یک process جداگانه پردازش می‌شود و تا زمانی که اجرای آن تمام نشود، آن process نمی‌تواند درخواست دیگری را بپذیرد؛ بنابراین اگر تعداد درخواست‌ها بیشتر از تعداد processهای موجود شود، درخواست‌ها در صف انتظار قرار می‌گیرند. اما در مدل non-blocking مثل FrankenPHP که معمولاً بر پایه‌ی event loop و معماری multi-thread یا async طراحی شده، یک thread یا process می‌تواند چندین درخواست را به‌صورت هم‌زمان (concurrently) مدیریت کند. این باعث می‌شود منابع بهتر استفاده شوند و تأخیر در پاسخ‌دهی به درخواست‌ها (latency) به‌شدت کاهش یابد، مخصوصاً در اپلیکیشن‌هایی با تعداد بالای اتصال یا عملیات I/O زیاد.نتیجه‌گیریدر این مقاله، با نگاهی دقیق به مسیر اجرای کد PHP از طریق روش‌های مختلف از جمله CLI، وب‌سرورها و application serverها، درک بهتری از چرخه‌ی حیات یک اسکریپت PHP پیدا کردیم. در نهایت، انتخاب بهترین روش اجرای PHP بستگی به نوع پروژه، حجم ترافیک، منابع سخت‌افزاری و نیازمندی‌های خاص توسعه‌دهنده دارد. اما دانستن اینکه PHP در پشت صحنه دقیقاً چگونه اجرا می‌شود، به ما کمک می‌کند انتخاب‌های بهتری داشته باشیم، مشکلات را سریع‌تر دیباگ کنیم و نهایت بهره‌وری را از زبان PHP بگیریم. علی قاسم پور علی قاسم پور Fri, 23 May 2025 11:41:57 +0330 https://virgool.io/@alighasempoor3/%D8%A7%D8%AC%D8%B1%D8%A7%DB%8C-php-%D8%AA%D9%88%D8%B3%D8%B7-web-server-tb1uzitd6m5b اجرای PHP به‌صورت ماژول در Apacheیکی از روش‌های اجرای PHP در وب‌سرور Apache، استفاده از ماژولی به‌نام mod_php است. این ماژول، PHP را مستقیماً درون پروسه‌ی Apache بارگذاری می‌کند و اجازه می‌دهد فایل‌های PHP بدون نیاز به راه‌اندازی پردازش خارجی، به‌صورت داخلی تفسیر و اجرا شوند. در این روش، زمانی که Apache یک فایل با پسوند .php را دریافت می‌کند، پردازش آن را مستقیماً به Zend Engine (از طریق mod_php) می‌سپارد.زمانی که از mod_php استفاده می‌شود، هر درخواست HTTP که به Apache می‌رسد، توسط یک process مستقل از Apache هندل می‌شود؛ به این معنا که PHP دقیقاً درون همان process اجرا شده و خروجی تولید می‌شود. این مدل، عملکردی سریع و یکپارچه دارد، زیرا سربار ارتباط با process یا سرور خارجی وجود ندارد. اما همین یکپارچگی باعث می‌شود که هر process آپاچی مصرف حافظه‌ی بیشتری داشته باشد، چرا که هم منابع Apache و هم PHP را در خود نگه می‌دارد.در این روش، mod_php به‌تنهایی نمی‌تواند PHP را اجرا کند؛ بلکه تنها یک واسط است که PHP را به Apache متصل می‌کند. بنابراین، برای کارکرد صحیح این ماژول، باید پکیج کامل PHP روی سیستم نصب شده باشد.ماژول mod_php از فایل‌های باینری PHP، کتابخانه‌ها و تنظیمات پیکربندی مانند php.ini استفاده می‌کند. به عبارت دیگر، این ماژول نقش یک پل را بین Apache و محیط اجرایی PHP ایفا می‌کند.اجرای PHP با استفاده از PHP-CGIاستاندارد CGI یک استاندارد قدیمی و عمومی برای اجرای برنامه‌های خارجی توسط وب‌سرورهاست. براساس این استاندارد، وب‌سرور می‌تواند برنامه‌هایی مانند php-cgi را اجرا کند و اطلاعات مربوط به درخواست HTTP را از طریق ورودی استاندارد (stdin) به آن‌ها منتقل کند. سپس برنامه‌ی CGI موظف است پاسخ را از طریق خروجی استاندارد (stdout) به وب‌سرور برگرداند. این مکانیزم امکان ارتباط بین وب‌سرور و زبان‌های برنامه‌نویسی را بدون نیاز به ماژول داخلی فراهم می‌سازد.در زمان اجرای یک درخواست، وب‌سرور متغیرهایی مانند REQUEST_METHOD, SCRIPT_FILENAME, QUERY_STRING, CONTENT_TYPE, و CONTENT_LENGTH را به php-cgi ارسال می‌کند. این مقادیر اطلاعات ضروری برای تحلیل و پردازش درخواست هستند. در پاسخ، php-cgi باید ابتدا هدرهای HTTP (مانند Content-Type) را از طریق stdout ارسال کند و سپس محتوای اصلی (body) پاسخ را بنویسد.نکته‌ی مهم در استفاده از PHP-CGI این است که حتی اگر فقط قصد اجرای php-cgi را داشته باشید، باید پکیج php-cli نیز روی سیستم نصب باشد. دلیل این وابستگی آن است که فایل‌های runtime و برخی ابزارهای جانبی مورد نیاز برای اجرای صحیح اسکریپت‌ها، در پکیج CLI قرار دارند. این مسئله نشان می‌دهد که CGI با این که یک php binary مستقل است، همچنان برای عملکرد صحیح نیازمند زیرساخت کامل PHP می باشد.اجرای PHP با PHP-FPMروش PHP-FPM یک روش مدرن و بهینه‌شده برای اجرای PHP است که به‌جای اجرای یک process جدید برای هر درخواست، از یک مجموعه‌ی پایدار از processها استفاده می‌کند. این رویکرد نه‌تنها کارایی بالاتری دارد، بلکه مصرف منابع را به‌شکل مؤثری کنترل می‌کند. PHP-FPM به‌طور خاص برای هماهنگی با وب‌سرورهایی مانند Nginx طراحی شده که خودشان توانایی اجرای مستقیم PHP را ندارند.روند اجرای درخواست به این شکل است: ابتدا Nginx بررسی می‌کند که درخواست به فایلی با پسوند .php مربوط است، سپس متوجه می‌شود که این فایل باید توسط PHP پردازش شود. در این مرحله، Nginx از طریق پروتکل FastCGI، درخواست را به PHP-FPM ارسال می‌کند و اطلاعاتی مانند مسیر کامل فایل (SCRIPT_FILENAME) و سایر متغیرهای مرتبط را همراه آن می‌فرستد.روش PHP-FPM خود شامل یک یا چند process pool است که هر pool مجموعه‌ای از processهای PHP را مدیریت می‌کند. یکی از این processها فایل PHP مورد نظر را از روی دیسک می‌خواند، آن را پردازش می‌کند و نتیجه را (شامل header و body) به Nginx بازمی‌گرداند. سپس Nginx این خروجی را به‌صورت یک پاسخ HTTP استاندارد به کلاینت ارسال می‌کند.در مدل PHP-FPM، فرایندها به‌صورت Long-lived ایجاد می شوند؛ به این معنا که پس از ایجاد، برای مدت زیادی فعال باقی می‌مانند و به درخواست‌های متعدد پاسخ می‌دهند. این برخلاف روش‌هایی مثل PHP-CGI است که در آن هر درخواست باعث ایجاد یک process جدید می‌شود و بلافاصله پس از پایان اجرا، آن process از بین می‌رود. Long-lived بودن processها در PHP-FPM باعث بهینه‌سازی قابل توجهی در performance سیستم می‌شود، چون سربار راه‌اندازی و بستن مداوم processها حذف می‌شود و منابع سیستم به شکل بهینه تری مورد استفاده قرار می‌گیرند.مشاهده بخش بعدی مقاله علی قاسم پور علی قاسم پور Fri, 23 May 2025 11:29:30 +0330 https://virgool.io/@alighasempoor3/%D8%A8%D8%B1%D8%B1%D8%B3%DB%8C-%D8%AD%D8%A7%D9%84%D8%AA-%D9%87%D8%A7%DB%8C-%D8%A7%D8%AC%D8%B1%D8%A7%DB%8C-php-%D8%A7%D8%B2-cli-%D8%AA%D8%A7-application-server-%D9%82%D8%B3%D9%85%D8%AA-%D8%AF%D9%88%D9%85-z540bgceac3g بررسی محتوای فایل deb (پکیج نصب php)زمانی که دستور نصب PHP را در توزیع‌های مبتنی بر دبیان اجرا می‌کنیم (apt install php)، پشت‌صحنه مجموعه‌ای از پکیج‌های مختلف و وابسته به‌صورت سلسله‌مراتبی نصب می‌شوند. این ساختار به ما امکان می‌دهد که بخش‌های مختلف PHP را به‌صورت جداگانه نصب یا حذف کنیم و تنها ماژول‌ها و قابلیت‌هایی را که واقعاً نیاز داریم، روی سیستم نگه داریم. این رویکرد باعث بهینه‌شدن فضای دیسک و کاهش پیچیدگی سیستم می‌شود.پکیج اصلی که با نام ساده‌ی php شناخته می‌شود، درواقع یک Meta Package است. این نوع پکیج‌ها فایل باینری یا اسکریپت خاصی ندارند، بلکه صرفاً برای مدیریت مجموعه‌ای از پکیج‌های مرتبط طراحی شده‌اند. پکیج php معمولاً به آخرین نسخه‌ی پایدار PHP ارجاع می‌دهد (مثلاً php8.4) و وابستگی‌هایی مانند php-cli، php-fpm، و php-common را نصب می‌کند. نقش meta package‌ها این است که کار نصب را ساده کنند و یک نقطه‌ی مرکزی برای مدیریت نسخه‌ها و اجزای وابسته فراهم آورند.در کنار پکیج اصلی، تعداد زیادی Sub-package وجود دارند که هر کدام وظیفه‌ی خاصی را بر عهده دارند؛ مانند php-mysql برای اتصال به دیتابیس، php-curl برای درخواست‌های HTTP. این پکیج‌ها معمولاً به‌شکل ماژول‌های قابل بارگذاری توسط PHP طراحی شده‌اند و هنگام بارگذاری در فایل پیکربندی (php.ini) فعال می‌شوند. با بررسی ساختار یک فایل .deb از این پکیج‌ها، می‌توان binary file ها ، extension ها، فایل‌های پیکربندی، و لیست وابستگی‌ها را مشاهده کرد که همگی با فرمت استاندارد بسته‌بندی دبیان طراحی شده‌اند.اجرای php توسط CLIزبان PHP دارای یک محیط اجرای خط فرمان است که به توسعه‌دهندگان اجازه می‌دهد اسکریپت‌های PHP را مستقیماً از ترمینال اجرا کنند. در این حالت، برنامه‌ی php به‌عنوان یک برنامه‌ی مستقل فراخوانی می‌شود و اسکریپت موردنظر به‌صورت آرگومان به آن داده می‌شود، مانند: php script.php. این نوع اجرا بیشتر در اسکریپت‌های بک‌اند، ابزارهای مدیریتی، برنامه‌های زمان‌بندی‌شده (cron jobs)، و تست کدها کاربرد دارد.در اجرای CLI، برخلاف حالت وب، خبری از درخواست HTTP، سرور وب یا متغیرهای مربوط به مرورگر نیست. محیط اجرا کاملاً مستقل از HTTP است و متغیرهایی مانند $_SERVER['REQUEST_METHOD'] یا $_GET مقداردهی نمی‌شوند. با این حال، توسعه‌دهنده می‌تواند ورودی‌هایی از طریق آرگومان‌های خط فرمان ($argv) دریافت کند و خروجی را نیز مستقیماً به ترمینال ارسال نماید.یکی از مزایای بزرگ اجرای CLI، سرعت و سادگی آن است؛ زیرا نیازی به بارگذاری وب‌سرور یا ساختار پیچیده‌ی درخواستی ندارد. همچنین بسیاری از ابزارها مانند Composer، PHPUnit یا Laravel Artisan نیز بر پایه‌ی همین CLI ساخته شده‌اند. در زمان اجرا، CLI همان چرخه‌ی پردازش استاندارد PHP را طی می‌کند (از parsing تا اجرای opcode در Zend Engine) اما در بستری سبک‌تر و بدون سربار ارتباط با وب سرور.تفاوت اجرای PHP در محیط CLI و Web Serverبرخلاف برخی زبان‌ها مانند Go یا JavaScript (Node.js) که قابلیت سرو کردن درخواست‌های HTTP به‌صورت Built-in دارند، PHP برای این منظور به یک وب‌سرور خارجی مانند Apache یا Nginx نیاز دارد. این وب‌سرورها وظیفه‌ی دریافت درخواست HTTP از سمت کاربر و ارسال آن به PHP را بر عهده دارند.نحوه‌ی اجرای PHP در حالت CLI با حالت Web Server تفاوت‌های اساسی دارد. در CLI، اسکریپت مستقیماً از طریق خط فرمان اجرا می‌شود و معمولاً هیچ محدودیتی برای زمان اجرای آن وجود ندارد. خروجی‌ها با echo یا print مستقیماً به ترمینال ارسال می‌شوند، و خبری از متغیرهای مرتبط با درخواست HTTP مانند $_GET، $_POST، یا $_SERVER['REQUEST_METHOD'] نیست.در مقابل، زمانی که PHP از طریق وب‌سرور اجرا می‌شود، با محدودیت‌های خاصی مواجه است. به‌طور معمول، برای جلوگیری از فشار زیاد روی سرور، زمان اجرای اسکریپت در فایل php.ini محدود می‌شود. و همچنین، echo برای نوشتن در body پاسخ HTTP استفاده میشود. متغیرهای $_GET، $_POST، و سایر متغیرهای سوپرگلوبال در دسترس هستند و اطلاعات مربوط به درخواست را شامل می‌شوند.در وب سرور header های پیش‌فرض برای HTTP message وجود دارند که به پاسخ‌ HTTP اضافه می‌شوند، مگر اینکه به‌صورت صریح php آن ها را غیرفعال کند و یا تغییر دهد. مشاهده بخش بعدی مقاله علی قاسم پور علی قاسم پور Fri, 23 May 2025 11:10:37 +0330 https://virgool.io/@alighasempoor3/%D8%A8%D8%B1%D8%B1%D8%B3%DB%8C-%D8%AD%D8%A7%D9%84%D8%AA-%D9%87%D8%A7%DB%8C-%D8%A7%D8%AC%D8%B1%D8%A7%DB%8C-php-%D8%A7%D8%B2-cli-%D8%AA%D8%A7-application-server-j5y9pjusriwe زبان PHP طی سال‌ها توسعه و به‌روزرسانی، حالت‌های متنوعی برای اجرای کدهای خود ارائه کرده است. از اجرای اسکریپت‌ها توسط خط فرمان گرفته تا تعامل با وب‌سرورها و حتی اجرای کد در بستر application server ها. هرکدام ویژگی‌ها و محدودیت‌های خاص خود را از لحاظ performance، امنیت، scalability و … دارند. درک درست از این حالت‌های اجرا، به توسعه‌دهندگان کمک می‌کند تا انتخاب‌ درست تری برای محیط اجرای پروژه‌های خود داشته باشند.برای درک بهتر این حالت‌ها، آشنایی با چرخه‌ی حیات اجرای کد PHP ضروری است. این چرخه با راه‌اندازی فرایند اجرا آغاز می‌شود و از مراحلی نظیر تحلیل واژگانی (lexing)، تجزیه‌ی نحوی (parsing) و تبدیل به کد میانی (opcode) عبور می‌کند تا در نهایت با استفاده از Zend Engine، خروجی مناسب تولید شود.در این مقاله، ابتدا اجرای PHP به‌وسیله‌ی CLI و وب‌سرورها بررسی می‌شود. سپس به سمت کاربردهای مدرن‌تر مانند اجرای PHP در بستر application serverها حرکت می‌کنیم و نمونه‌هایی نظیر FrankenPHP را بررسی خواهیم کرد. در کنار این‌ها، مفاهیم پایه‌ای مرتبط مثل process و thread نیز برای ایجاد درک کامل‌تر، به صورت مختصر معرفی خواهند شد. هدف نهایی این مقاله، ارائه‌ی تصویری جامع از مسیرهای مختلف اجرای PHP و انتخاب مناسب‌ترین روش بر اساس نیاز پروژه است.چرخه‌ی اجرای اسکریپت PHP1. Run php binaryاین مرحله آغاز اجرای اسکریپت است. بسته به نوع اجرا (CLI یا Web)، فایل php binary با مسیر فایل php به عنوان ورودی فراخوانی می‌شود تا پردازش آغاز گردد.2. Loading Configدر این مرحله فایل پیکربندی php.ini خوانده می‌شود. تنظیمات مربوط به حافظه، ماژول‌ها، سطح گزارش خطا و سایر تنظیمات اصلی PHP در این فایل قرار دارند که قبل از اجرای کد بارگذاری می‌شوند.3. Load Extensionsبر اساس تنظیمات موجود در php.ini، اکستنشن‌های مورد نیاز مانند PDO، curl، mbstring و دیگر کتابخانه‌های بومی یا سفارشی در حافظه بارگذاری می‌شوند.اکستنشن‌ها در php به‌صورت کتابخانه‌های داینامیک (Shared Libraries) طراحی شده‌اند که در زمان اجرا (Runtime) به برنامه متصل می‌شوند و مستقیماً در حافظه‌ی همان process اصلی PHP قرار می‌گیرند. برخلاف اجرای جدا یا ساخت subprocess، این اتصال کاملاً درون process اتفاق می‌افتد. مکانیزم این اتصال در سطح سیستم‌عامل معمولاً با استفاده از تابع dlopen انجام می‌شود، که اجازه می‌دهد فایل‌های .so (در لینوکس) به‌صورت داینامیک بارگذاری شوند. این قابلیت انعطاف‌پذیری بالایی ایجاد می‌کند، چرا که می‌توان اکستنشن‌هایی را بدون نیاز به Recompile کردن PHP، در هر زمان به سیستم اضافه کرد و مورد استفاده قرار داد.4. Read PHP File from Diskمحتوای فایل PHP مشخص‌شده از دیسک خوانده شده و به صورت رشته (string) در حافظه ذخیره می‌شود تا وارد مراحل پردازش زبان شود.5. Lexing and Parsingدر این مرحله، ابتدا کد به توکن‌های معنایی (lexing) تجزیه می‌شود و سپس این توکن‌ها با قواعد نحوی زبان (parsing) بررسی شده و به یک ساختار درختی نحوی (AST - Abstract Syntax Tree) تبدیل می‌شوند.6. Compiling to Opcodeساختار AST به مجموعه‌ای از دستورالعمل‌های میانی به نام opcode یا operation code کامپایل می‌شود. این opcodeها مستقل از معماری CPU هستند و توسط Zend Engine اجرا می‌شوند.منظور از «مستقل از معماری CPU» یعنی opcode ها به گونه‌ای تولید می‌شوند که وابسته به نوع سخت‌افزار یا معماری خاص CPU (مثل x86، ARM یا غیره) نیستند. opcodeها در سطحی عمومی و انتزاعی ایجاد می‌شوند که می‌توانند روی هر پلتفرم یا سیستمی که Zend Engine روی آن اجرا می‌شود، کار کنند. این ویژگی باعث می‌شود کد PHP قابل حمل (portable) باشد و بدون نیاز به تغییر یا بازنویسی، روی سیستم‌های مختلف اجرا شود، به شرطی که Zend Engine در آن سیستم پشتیبانی شود.اکستنشن رسمی OPcach که با هدف افزایش کارایی، نتیجه‌ی مرحله‌ی کامپایل (یعنی opcode) را در RAM ذخیره می‌کند تا در درخواست‌های بعدی نیازی به parse و compile مجدد اسکریپت نباشد. در حالت عادی، PHP هر بار که یک فایل اجرا می‌شود، باید آن را از دیسک بخواند، تجزیه (parse) کند، به opcode تبدیل کند و سپس اجرا کند. اما با فعال بودن OPcache، این مراحل فقط یک‌بار انجام می‌شود و نتیجه‌ی آن در RAM باقی می‌ماند. این یعنی زمان اجرای فایل کاهش می‌یابد و بار پردازشی سرور نیز کم‌تر می‌شود، خصوصاً در اپلیکیشن‌هایی با درخواست‌های زیاد و فایل‌های پرتکرار.7. Run Opcode on Zend Engineماشین مجازی Zend Engine، دستورالعمل‌های opcode را یکی پس از دیگری اجرا کرده و خروجی نهایی را تولید می‌کند. این مرحله همان‌جایی‌ست که منطق برنامه واقعاً اجرا می‌شود.8. Return to STDOUTنتیجه‌ی اجرای اسکریپت (مثل HTML یا خروجی‌های متنی) به خروجی استاندارد ارسال می‌شود. در اجرای CLI این خروجی مستقیماً در ترمینال نمایش داده می‌شود و در حالت وب، به مرورگر کاربر ارسال می‌شود.9. Garbage Collectorدر پایان، PHP حافظه‌ی اختصاص‌داده‌شده به متغیرهای بدون استفاده را از طریق مکانیزم Garbage Collection آزاد می‌کند تا منابع سیستم بهینه باقی بمانند.مفهوم Process در سیستم‌عاملدر سیستم‌عامل، هر بار که یک برنامه اجرا شود (یک فایل باینری run شود)، یک Process جدید ایجاد می‌شود. Process به‌طور ساده، نماینده‌ی یک برنامه‌ی در حال اجراست که شامل کد اجرایی، حافظه‌ی اختصاصی، پشته (stack)، داده‌های سراسری (heap) و منابعی مثل فایل‌ هاست. سیستم‌عامل با استفاده از مفهومی به‌نام Process می‌تواند چندین برنامه را هم‌زمان اجرا کند و منابع را به‌شکل جداگانه بین آن‌ها مدیریت کند.در زمینه‌ی PHP، هر بار که فایل باینری PHP اجرا می‌شود، یک process جدید ساخته می‌شود. این process مسئول اجرای چرخه‌ی حیات فایل PHP است؛ از خواندن فایل و پیکربندی، تا اجرای opcode و بازگرداندن خروجی. در اجرای خط فرمان (CLI)، هر اجرای دستی شما از دستور php file.php دقیقاً یک process مستقل می‌سازد.شناخت مفهوم process به ما کمک می‌کند تا درک بهتری از اجرای هم‌زمان، مصرف منابع، محدودیت‌های حافظه و رفتار برنامه در شرایط مختلف داشته باشیم. همچنین، در حالت‌هایی که برنامه روی معماری‌های مقیاس‌پذیر اجرا می‌شود و یا تعداد درخواست ها بالا رود، مدیریت صحیح process ها نقش مهمی در performance و پایداری سیستم ایفا می‌کند.مشاهده بخش بعدی مقاله علی قاسم پور علی قاسم پور Fri, 23 May 2025 10:41:11 +0330