نصب کش APC بر روی دایرکت ادمین

اگر دنبال نصب کش APC روی دایرکت‌ادمین هستید، پاسخ کوتاه این است: دیگر لازم نیست و در عمل هم ممکن نیست. اکستنشن APC از زمان PHP 5.5 کنار گذاشته شد و جای آن را OPcache گرفت که از همان نسخه به‌صورت داخلی داخل خود PHP قرار دارد؛ فقط باید فعال و تنظیم شود. تنها بازمانده‌ی APC هم APCu است که صرفاً کش داده‌های کاربر است، نه کش کد.

فعال‌سازی کش کد PHP در دایرکت‌ادمین

کش opcode اصلاً چه کار می‌کند؟

هر بار که یک اسکریپت PHP اجرا می‌شود، مفسر باید فایل را بخواند، تجزیه کند و به کد میانی (opcode) تبدیل کند و بعد اجرا کند. در سایتی مثل وردپرس که هر درخواست ده‌ها فایل را include می‌کند، این مرحله‌ی کامپایل بخش قابل‌توجهی از زمان پاسخ و مصرف CPU را می‌بلعد.

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

چرا دیگر APC نصب نمی‌شود

APC در دوره‌ی PHP 5.2 و PHP 5.3 ابزار استانداردی بود، اما توسعه‌اش متوقف شد و هرگز نسخه‌ی پایداری برای PHP 5.5 به بعد منتشر نکرد. اگر امروز دستور pecl install apc یا کامپایل دستی APC-3.1.13.tgz را روی سروری با PHP 8.x اجرا کنید، در مرحله‌ی make با خطای کامپایل متوقف می‌شوید. پس هر آموزشی که هنوز مسیر no-debug-non-zts-20060613 و خط extension=apc.so را پیشنهاد می‌دهد، مربوط به یک دهه قبل است. مستندات خود دایرکت‌ادمین هم صراحتاً توصیه می‌کند هرجا ممکن است به‌جای APC و APCu از OPcache استفاده کنید.

روی سرویس‌های اشتراکی این کار اصلاً به عهده‌ی شما نیست؛ مثلاً هاست لینوکس ایران با کنترل پنل cPanel ارائه می‌شود و تنظیمات سطح سرور را مدیر سرور انجام می‌دهد و شما از نتیجه‌اش استفاده می‌کنید. مراحل زیر برای کسی است که روی سرور خودش دسترسی root دارد.

فعال‌کردن OPcache در دایرکت‌ادمین

دایرکت‌ادمین PHP را با CustomBuild می‌سازد، بنابراین هیچ‌وقت اکستنشن را دستی کامپایل نکنید؛ اولین آپدیت PHP آن را پاک می‌کند. در نسخه‌های امروزی، CustomBuild از طریق دستور da build فراخوانی می‌شود:

da build update
da build set php_opcache yes
da build php_opcache

اگر روی سروری هنوز نسخه‌ی قدیمی CustomBuild را دارید، معادل همین کار cd /usr/local/directadmin/custombuild و سپس ./build است؛ اما روی نصب‌های به‌روز، da build شکل درست و پشتیبانی‌شده است. این نکته برای کسانی که روی سرور ابری ایران یا هر سرور مدیریت‌نشده‌ی دیگری پنل را خودشان به‌روز نگه می‌دارند مهم است، چون آموزش‌های قدیمی هنوز فقط شکل ./build را نشان می‌دهند.

پس از نصب، فایل تنظیمات اکستنشن داخل پوشه‌ی /usr/local/php83/lib/php.conf.d/ ساخته می‌شود (شماره‌ی نسخه را با نسخه‌ی PHP خودتان جایگزین کنید). برای اینکه مقادیر دلخواهتان با آپدیت بعدی بازنویسی نشود، آن‌ها را در یک فایل با شماره‌ی بالا مثل 99-custom.ini در همان پوشه بنویسید.

تنظیمات معقول برای شروع

opcache.enable=1
opcache.enable_cli=0
opcache.memory_consumption=192
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.validate_timestamps=1
opcache.revalidate_freq=2

چند نکته درباره‌ی همین مقادیر: memory_consumption بر حسب مگابایت است و باید از مجموع حجم فایل‌های PHP سایت‌هایتان بیشتر باشد، وگرنه کش مدام خودش را خالی می‌کند. max_accelerated_files باید از تعداد فایل‌های PHP سرور بیشتر باشد؛ یک وردپرس با چند افزونه به‌راحتی از چند هزار فایل عبور می‌کند. validate_timestamps را روی سرور اشتراکی و در حال توسعه روشن بگذارید؛ خاموش‌کردنش سریع‌تر است اما بعد از هر تغییر فایل باید سرویس PHP را ریستارت کنید.

درباره‌ی JIT در PHP 8 هم واقع‌بین باشید: برای بارهای کاری معمول وب که وقتشان صرف دیتابیس و I/O می‌شود، سود محسوسی ندارد و در بعضی موارد باعث بروز رفتار غیرمنتظره می‌شود. اگر دلیل مشخصی ندارید، آن را روشن نکنید.

بعد از تغییر تنظیمات، بسته به وب‌سروری که استفاده می‌کنید سرویس را ریستارت کنید — مثلاً systemctl restart httpd برای آپاچی، systemctl restart lsws برای لایت‌اسپید، و در حالت PHP-FPM دستور systemctl restart php-fpm83.

بررسی اینکه واقعاً فعال شده

ساده‌ترین راه، خروجی خط فرمان است:

php -v
php -i | grep -i opcache.enable

در خروجی php -v باید خط with Zend OPcache دیده شود. توجه کنید که تنظیمات CLI با تنظیمات وب یکی نیستند؛ برای اطمینان نهایی یک فایل موقت با phpinfo() از طریق مرورگر باز کنید و بعد حتماً حذفش کنید. برای سنجش تأثیر واقعی هم زمان پاسخ سرور را قبل و بعد مقایسه کنید؛ ابزار چکاپ سلامت سایت زمان تا اولین بایت را گزارش می‌دهد و برای همین مقایسه‌ی ساده کار راه‌انداز است.

APCu کجا هنوز به کار می‌آید؟

APCu همان بخش «کش داده‌ی کاربر» APC است که جدا شد و هنوز نگهداری می‌شود. برخلاف OPcache، در فهرست اکستنشن‌های آماده‌ی CustomBuild نیست و باید برای هر نسخه‌ی PHP جداگانه کامپایل شود: با phpize همان نسخه، سپس ./configure به‌همراه سوئیچ --with-php-config و در پایان make و make install. بعد هم یک فایل مثل 90-apcu.ini در پوشه‌ی php.conf.d بسازید و خط extension=apcu.so را در آن قرار دهید. در کد با توابعی مثل apcu_store() و apcu_fetch() استفاده می‌شود و کاربرد رایجش object cache روی یک سرور تکی است.

محدودیت‌هایش را بدانید: حافظه‌اش بین سرورها مشترک نیست، با ریستارت سرویس PHP خالی می‌شود و هر pool در PHP-FPM سگمنت خودش را دارد. اگر بیش از یک سرور دارید یا به کش پایدار و قابل اشتراک نیاز دارید، Redis یا Memcached انتخاب درست‌تری است.

تفاوت با کش صفحه و ریورس‌پروکسی

این سه لایه را با هم اشتباه نگیرید. OPcache فقط کامپایل PHP را حذف می‌کند و خروجی HTML را ذخیره نمی‌کند. کش صفحه‌ی کامل مثل LSCache خروجی نهایی را پیش از رسیدن به موتور PHP تحویل می‌دهد، یعنی برای درخواست‌های بعدی نه PHP اجرا می‌شود و نه کوئری دیتابیس؛ طبق جدول پلن‌های لایسنس لایت‌اسپید این ماژول روی همه‌ی نسخه‌ها رایگان است. ریورس‌پروکسی یا CDN هم یک لایه جلوتر می‌ایستد و بار را قبل از رسیدن به وب‌سرور کم می‌کند.

بیشترین نتیجه وقتی به دست می‌آید که این لایه‌ها روی هم سوار شوند: OPcache برای کد، یک کش صفحه برای بازدیدکننده‌های مهمان، و کش شیء برای کوئری‌های سنگین. نصب APC در این معماری هیچ جایی ندارد.