چرا New Relic برای پروفایلینگ وردپرس انتخاب حرفه‌ای‌هاست؟
New Relic عملکرد وردپرس را در سطح سرور، دیتابیس و کد PHP رصد می‌کند. چرا برای سایت‌های پرترافیک، ابزارهای محلی کافی نیستند؟
سال‌ها پیش، وقتی برای اولین بار یک سایت وردپرسی با ترافیک بالا را روی یک VPS (Virtual Private Server) تحویل گرفتم، مشکل «کندی» گزارش شد. TTFB (Time to First Byte) روی ۴ ثانیه بود، اما هیچ‌کس نمی‌توانست بگوید گلوگاه کجاست. Query Monitor نشان می‌داد ۸۷ کوئری اجرا می‌شود، اما مجموع زمان کوئری‌ها کمتر از ۴۰۰ میلی‌ثانیه بود. بعد از نصب New Relic، در عرض چند دقیقه مشخص شد یک افزونه امنیتی، یک درخواست HTTP خارجی به سروری در اروپا می‌زند که ۲.۸ ثانیه طول می‌کشد و هیچ کشی هم ندارد. چیزی که هیچ ابزار سطح افزونه‌ای نمی‌توانست فاش کند. این تجربه، تفاوت بنیادین بین «دیدن کوئری‌ها» و «دیدن تمام مسیر اجرا» را برای من روشن کرد.
چرا New Relic برای پروفایلینگ وردپرس انتخاب حرفه‌ای‌هاست؟
بیشتر ابزارهای پروفایلینگ وردپرس در سطح PHP (Hypertext Preprocessor) کار می‌کنند: Query Monitor کوئری‌ها را می‌شمارد، Debug Bar هوک‌ها را لاگ می‌کند، و Xdebug مسیر اجرا را در محیط توسعه ردیابی می‌کند. اما هیچ‌کدام از این‌ها به‌تنهایی نمی‌توانند پاسخ دهند به سوالی مثل: «چرا صفحه محصول فلان دسته‌بندی، فقط برای کاربران لاگین‌کرده، در ساعت ۹ شب کند می‌شود؟»
New Relic این شکاف را پر می‌کند. PHP Agent آن به‌عنوان یک Extension (افزونه) در سطح موتور PHP نصب می‌شود و هر Transaction را — از لحظه ورود درخواست به index.php تا ارسال آخرین بایت — به‌صورت یک Span (بازه) زمان‌بندی‌شده ثبت می‌کند. این یعنی نه فقط کوئری دیتابیس، بلکه تمام تماس‌های HTTP خارجی، اجرای کدهای PHP، و حتی زمان انتظار برای پاسخ سرورهای شخص ثالث در یک نمای واحد قابل مشاهده است. اگر با مفهوم API و کاربرد آن در وب آشنا باشید، این سطح از ردیابی دقیقاً همان چیزی است که برای عیب‌یابی تماس‌های API خارجی در وردپرس به آن نیاز دارید.
«تفاوت بین Query Monitor و New Relic، تفاوت بین نگاه‌کردن به کاپوت ماشین و نشستن پشت فرمان با تمام داشبورد فعال است.»
از منظر معماری، New Relic سه لایه را پوشش می‌دهد که برای یک سایت وردپرسی حیاتی‌اند: APM (Application Performance Monitoring) که کد PHP و وردپرس را ردیابی می‌کند، Infrastructure که سرور (CPU، RAM، دیسک، شبکه) را مانیتور می‌کند، و Browser (RUM) که تجربه واقعی کاربر را از سمت مرورگر اندازه‌گیری می‌کند. این یکپارچگی سه‌لایه یعنی وقتی سایت کند می‌شود، می‌توانید در یک Timeline ببینید که کندی از سرور بوده، از کد PHP، یا از شبکه کاربر. این سطح از همبستگی (Correlation) در هیچ ابزار اختصاصی وردپرس وجود ندارد.
New Relic چگونه در وردپرس کار می‌کند؟
وقتی PHP Agent نصب می‌شود، یک .so (Shared Object) به موتور PHP تزریق می‌شود. این Extension با استفاده از مکانیزم Zend Engine Hooks (قلاب‌های موتور Zend) هر تابع PHP را قبل و بعد از اجرا زمان‌بندی می‌کند. این یعنی نه فقط توابع وردپرس، بلکه هر تابع PHP در مسیر اجرا — از mysqli_query() تا file_get_contents() — قابل ردیابی است. این سطح از Instrumentation (ابزارگذاری) به Agent اجازه می‌دهد تا چیزی را ببیند که در سطح وردپرس قابل مشاهده نیست: هزینه واقعی اجرای کد در سطح Runtime.
در گام بعد، Agent داده‌ها را به‌صورت دوره‌ای (معمولاً هر ۶۰ ثانیه) به سرورهای New Relic ارسال می‌کند. هر Transaction به یک Trace (ردیاب) تبدیل می‌شود که شامل زمان شروع، مدت اجرا، کوئری‌های دیتابیس، تماس‌های خارجی و خطاهای PHP است. اگر می‌خواهید درک عمیق‌تری از نحوه تعامل این لایه‌ها با یکدیگر داشته باشید، مطالعه سرور چیست و چگونه کار می‌کند نقطه شروع خوبی است.
WordPress Hooks و Instrumentation
New Relic از نسخه ۵.۳ به بعد، به‌صورت پیش‌فرض تنظیم newrelic.framework.wordpress.hooks را فعال می‌کند. این تنظیم باعث می‌شود Agent توابع Dispatch وردپرس — یعنی apply_filters()، apply_filters_ref_array()، do_action() و do_action_ref_array() — را به‌عنوان نقاط اندازه‌گیری بشناسد و زمان صرف‌شده در هر Hook و هر Callback را گزارش دهد. این یعنی می‌توانید ببینید که مثلاً Hook init چند میلی‌ثانیه طول کشیده و کدام افزونه بیشترین سهم را در آن داشته است.
از نسخه ۱۰.۱۶ به بعد، تنظیم newrelic.framework.wordpress.hooks.options اضافه شده که سه حالت دارد:
| حالت | توضیح | سطح Overhead |
|---|---|---|
all_callbacks |
تمام Callbackها (هسته + افزونه + قالب) Instrument می‌شوند | بالاترین دقت، بالاترین Overhead |
plugin_callbacks |
فقط Callbackهای افزونه‌ها و قالب (پیش‌فرض نسخه ۱۰.۲۰) | تعادل بین دقت و Overhead |
threshold |
فقط Hookهایی که از newrelic.framework.wordpress.hooks.threshold (پیش‌فرض ۱ms) عبور کنند |
کمترین Overhead، مناسب محیط تولید پربازدید |
انتخاب بین این حالت‌ها یک تصمیم معماری است. در محیط Staging که هدف پیدا کردن گلوگاه است، all_callbacks مناسب است. در Production پربازدید که Overhead اهمیت دارد، threshold با آستانه‌ای مثل ۵ms یا ۱۰ms انتخاب هوشمندانه‌تری است.
نصب و پیکربندی PHP Agent
نصب New Relic روی وردپرس، برخلاف افزونه‌های معمولی، در سطح سیستم‌عامل انجام می‌شود. پیش‌نیازها شامل دسترسی root، PHP نسخه ۷.۲ یا بالاتر، و معماری x86_64 یا aarch64 است. برای اکثر توزیع‌های لینوکس، روش RPM یا DEB توصیه می‌شود:
# Import GPG key (rotated in 2026)
sudo rpm --import https://download.newrelic.com/php_agent/NEWRELIC_RPM_BD2E199C.public
# Install agent
sudo newrelic-install install
# Restart web server
sudo systemctl restart php-fpm nginxپس از نصب، فایل پیکربندی newrelic.ini در مسیر /etc/php/{version}/mods-available/ قرار می‌گیرد. مهم‌ترین پارامترها برای یک سایت وردپرسی:
newrelic.appname = "My WordPress Site"
newrelic.license = "YOUR_LICENSE_KEY"
newrelic.framework.wordpress.hooks = true
newrelic.framework.wordpress.hooks.options = "threshold"
newrelic.framework.wordpress.hooks.threshold = 5
newrelic.transaction_tracer.threshold = 500ms
newrelic.transaction_tracer.slow_sql = trueپارامتر transaction_tracer.threshold تعیین می‌کند که چه Transactionهایی به‌عنوان «کند» علامت‌گذاری شوند. مقدار پیش‌فرض apdex_f (چهار برابر آستانه Apdex) است، اما برای یک سایت وردپرسی معمولاً ۵۰۰ms تا ۱ ثانیه تنظیم می‌شود. پارامتر slow_sql فعال‌سازی ردیابی کوئری‌های SQL کند را کنترل می‌کند و در صورت فعال بودن، کوئری‌هایی که از آستانه newrelic.transaction_tracer.explain_threshold عبور کنند نیز ثبت می‌شوند.
بعد از نصب PHP Agent، نصب Infrastructure Agent و MySQL Integration توصیه می‌شود تا داده‌های سرور و دیتابیس نیز در همان Dashboard قابل مشاهده باشند. این یکپارچگی، به‌خصوص در عیب‌یابی مشکلاتی که ریشه در تأثیر دیتابیس بر سرعت سایت دارند، حیاتی است.
متریک‌های اختصاصی وردپرس در New Relic
وقتی Agent وردپرس را تشخیص می‌دهد، یک Tab اختصاصی در رابط کاربری New Relic ظاهر می‌شود. این Tab چهار نوع متریک اصلی را نمایش می‌دهد:
Hooks: زمان صرف‌شده در هر Hook وردپرس. این متریک از توابع Dispatch محاسبه می‌شود و نشان می‌دهد کدام Action یا Filter بیشترین زمان اجرا را دارد. اگر با هوک‌های وردپرس و نحوه کار آن‌ها آشنایی داشته باشید، می‌دانید که یک Hook می‌تواند ده‌ها Callback از افزونه‌های مختلف داشته باشد. New Relic این Callbackها را تفکیک می‌کند و دقیقاً نشان می‌دهد کدام افزونه مسئول کندی است.
Plugins and Themes: زمان صرف‌شده در هر افزونه و قالب. این متریک فقط زمانی تولید می‌شود که hooks.options روی all_callbacks یا plugin_callbacks تنظیم شده باشد. در یک سایت با ۳۰ افزونه فعال، این Tab می‌تواند در چند ثانیه نشان دهد که کدام افزونه ۴۰٪ زمان اجرا را می‌بلعد — حتی اگر آن افزونه در ظاهر «سنگین» به نظر نرسد.
Slow Transactions: لیست کندترین Transactionها با قابلیت Drill-down. با کلیک روی هر Transaction، یک Waterfall Chart (نمودار آبشاری) باز می‌شود که دقیقاً نشان می‌دهد زمان در کدام لایه مصرف شده: PHP، MySQL، External HTTP، یا Memcached/Redis. این نمای آبشاری ابزار اصلی عیب‌یابی در New Relic است.
Errors: خطاهای PHP که در حین پردازش درخواست‌ها رخ داده‌اند. این بخش نه فقط Error Message، بلکه Stack Trace و Transaction مربوطه را نیز نشان می‌دهد. برای سایت‌هایی که با خطای سفید شدن صفحه وردپرس مواجه می‌شوند، این Tab می‌تواند دقیقاً بگوید کدام فایل و کدام خط خطا داده است.
«در یک پروژه، یک افزونه ترجمه که ظاهراً کم‌مصرف بود، در New Relic مشخص شد که در هر بارگذاری صفحه، ۱۲۰ تماس HTTP به سرور ترجمه می‌زند. Query Monitor این را نشان نمی‌داد چون کوئری دیتابیس نبود.»
گردش کار پروفایلینگ: از Symptom تا Root Cause
New Relic یک ابزار «ببین و بفهم» است، نه یک جادوگر. بدون یک روش‌شناسی مشخص، داشبورد پر از نمودار می‌تواند گیج‌کننده باشد. گردش کاری که در پروژه‌های واقعی جواب داده، این مسیر را دنبال می‌کند:
گام اول: تعریف Symptom و Baseline
قبل از هر چیز، باید بدانید «کندی» یعنی چه. آیا TTFB بالاست؟ آیا LCP (Largest Contentful Paint) بد است؟ آیا فقط در ساعات خاصی سایت کند می‌شود؟ New Relic یک نمای Historical دارد که می‌توانید Baseline تعریف کنید. اگر میانگین TTFB در ۷ روز گذشته ۸۰۰ms بوده و امروز ۲.۵ ثانیه شده، این یک انحراف قابل اندازه‌گیری است. برای درک بهتر این معیارها، مطالعه TTFB چیست و چگونه آن را کاهش دهیم توصیه می‌شود.
گام دوم: شناسایی Transaction کند
در Tab Transactions، روی «Slowest Transactions» تمرکز کنید. یک Transaction مثل /product/xyz/ که ۴ ثانیه طول می‌کشد، نقطه شروع است. با کلیک روی آن، Waterfall باز می‌شود.
گام سوم: تحلیل Waterfall
Waterfall سه لایه را نشان می‌دهد: زمان PHP، زمان MySQL، و زمان External Calls. اگر بیشترین سهم در External Calls باشد، یعنی یک تماس HTTP خارجی (مثلاً به API یک درگاه پرداخت یا سرویس ترجمه) گلوگاه است. اگر در MySQL باشد، باید کوئری کند را پیدا کنید. اگر در PHP باشد، باید Callbackهای Hook را بررسی کنید. این دقیقاً همان روشی است که در رفع کندی شدید سایت وردپرس نیز دنبال می‌شود.
گام چهارم: Drill-down به Hook یا Plugin
از Tab WordPress Hooks، می‌توانید ببینید که کدام Hook بیشترین زمان را دارد. سپس با کلیک روی آن Hook، لیست Callbackها و افزونه‌های مربوطه نمایش داده می‌شود. اینجاست که مشخص می‌شود یک افزونه خاص، در Hook init، یک حلقه foreach روی هزاران رکورد می‌زند.
گام پنجم: تأیید و رفع
بعد از رفع مشکل، باید همان Transaction را دوباره در New Relic بررسی کنید. اگر TTFB از ۲.۵ ثانیه به ۹۰۰ms کاهش یافت، رفع مشکل تأیید می‌شود. اگر نه، باید لایه بعدی را بررسی کنید. این چرخه «اندازه‌گیری → تغییر → اندازه‌گیری» همان چیزی است که در عیب‌یابی مشکل سرعت سایت نیز باید رعایت شود.
مقایسه با Query Monitor، Blackfire و Datadog
هیچ ابزاری جایگزین کامل دیگری نیست. New Relic در کنار Query Monitor، Blackfire و Datadog قرار می‌گیرد، نه به‌جای آن‌ها. جدول زیر تفاوت‌های کلیدی را نشان می‌دهد:
| ویژگی | New Relic | Query Monitor | Blackfire | Datadog |
|---|---|---|---|---|
| نوع ابزار | APM سطح سرور | افزونه وردپرس | Profiler PHP | Unified Observability |
| Overhead در Production | پایین (با تنظیم threshold) | بالا | نزدیک به صفر | پایین |
| ردیابی Hook وردپرس | بومی (Native) | بومی | محدود | محدود |
| مانیتورینگ سرور | بله (Infrastructure) | خیر | خیر | بله (بسیار عمیق) |
| RUM (Real User Monitoring) | بله | خیر | خیر | بله |
| هزینه | ۱۰۰GB رایگان، سپس $0.40/GB | رایگان | پولی | پولی |
نکته کلیدی این است: Query Monitor برای محیط توسعه است، New Relic برای محیط تولید. Query Monitor وقتی فعال باشد، خودش Overhead قابل‌توجهی اضافه می‌کند و در Production می‌تواند گمراه‌کننده باشد. New Relic با تنظیم threshold می‌تواند Overhead بسیار پایینی داشته باشد و به‌صورت پیوسته در پس‌زمینه کار کند. ترکیب این دو — Query Monitor برای دیباگ لحظه‌ای، New Relic برای روند بلندمدت — یک استراتژی متداول در تیم‌های حرفه‌ای است.
Blackfire تمرکز عمیقی روی Profiling سطح کد دارد و Flame Graph آن بسیار دقیق‌تر از New Relic است. اما Blackfire به‌اندازه New Relic در مانیتورینگ پیوسته و یکپارچگی با زیرساخت قوی نیست. Datadog در زمینه Log Management و Alerting انعطاف‌پذیرتر است، اما New Relic در ردیابی Hookهای وردپرس یکپارچگی بومی (Native) دارد که Datadog ندارد.
هزینه، Overhead و بهینه‌سازی پیکربندی
New Relic مدل قیمت‌گذاری بر اساس حجم داده (Data Ingest) دارد. پلن رایگان شامل ۱۰۰GB در ماه است. برای یک سایت وردپرسی با ترافیک متوسط، این مقدار معمولاً کافی است. اما برای سایت‌های پربازدید، هزینه می‌تواند به سرعت بالا برود. هر Transaction اضافه، داده بیشتری تولید می‌کند و هرچه hooks.options روی all_callbacks باشد، حجم داده بیشتر می‌شود.
Overhead PHP Agent در نسخه‌های قدیمی حدود ۳۵٪ بود، اما در نسخه‌های مدرن به حدود ۴٪ کاهش یافته است. با این حال، این عدد به تنظیمات و ترافیک بستگی دارد. برای کاهش Overhead در Production:
hooks.optionsرا رویthresholdتنظیم کنید و آستانه را روی ۵ms یا ۱۰ms بگذارید.transaction_tracer.thresholdرا روی ۵۰۰ms تنظیم کنید تا فقط Transactionهای واقعاً کند ثبت شوند.slow_sqlرا فقط در صورت نیاز فعال کنید.- Sampling Rate را کاهش دهید اگر حجم داده بیش از حد است.
توجه داشته باشید که New Relic روی Shared Hosting معمولاً قابل نصب نیست، چون نیاز به دسترسی root دارد. اگر روی هاست اشتراکی وردپرس هستید، Query Monitor گزینه واقع‌بینانه‌تری است. اگر روی VPS یا سرور اختصاصی هستید، New Relic پتانسیل کامل خود را نشان می‌دهد.
«هزینه New Relic یک تصمیم مهندسی است، نه یک هزینه مالی. اگر یک ساعت Downtime فروشگاه، ده برابر هزینه ماهانه New Relic ضرر بزند، تصمیم روشن است.»
اشتباهات رایج در استفاده از New Relic
اشتباه اول و رایج‌ترین: فعال گذاشتن New Relic با تنظیمات پیش‌فرض در Production. پیش‌فرض all_callbacks در نسخه‌های قبلی، حجم داده و Overhead را بالا می‌برد. باید صریحاً روی threshold تنظیم شود.
اشتباه دوم: نصب همزمان New Relic و Query Monitor و Debug Bar در یک محیط. این ابزارها همدیگر را Instrument می‌کنند و زمان‌بندی‌ها را تحریف می‌کنند. در یک زمان فقط یک Profiler باید فعال باشد.
اشتباه سوم: تفسیر نادرست Hooks Tab. زمان صرف‌شده در یک Hook لزوماً به معنای مشکل در آن Hook نیست. ممکن است Hook init زمان زیادی ببرد چون یک افزونه در آن، یک فایل حجیم را از دیسک می‌خواند. باید Callbackهای داخل Hook را تفکیک کرد.
اشتباه چهارم: نادیده گرفتن External Calls. در Waterfall، بخش «External» گاهی بیشترین سهم را دارد اما چون در Query Monitor نمایش داده نمی‌شود، مورد غفلت قرار می‌گیرد. تماس‌های HTTP به APIهای خارجی — از درگاه پرداخت تا سرویس‌های ایمیل — باید به‌عنوان گلوگاه بالقوه بررسی شوند.
اشتباه پنجم: نصب Agent روی محیط توسعه و انتظار رفتار مشابه Production. Overhead Agent در محیط توسعه که ترافیک پایین است، متفاوت از Production است. پروفایلینگ واقعی باید روی Staging یا Production با ترافیک واقعی انجام شود.
اگر می‌خواهید درک دقیق‌تری از نحوه تعامل این ابزارها با یکدیگر داشته باشید، مطالعه افزونه‌های وردپرس چگونه روی سرعت سایت اثر می‌گذارند می‌تواند مفید باشد.
پرسش‌های پرتکرار درباره New Relic و وردپرس
آیا New Relic روی Shared Hosting قابل نصب است؟
در بیشتر موارد خیر. نصب PHP Agent نیاز به دسترسی root و امکان تزریق Extension در سطح PHP دارد. برخی هاست‌های مدیریت‌شده مثل Kinsta و WP Engine یکپارچگی New Relic را به‌صورت آماده ارائه می‌دهند، اما روی هاست اشتراکی معمولی باید از Query Monitor یا ابزارهای سطح افزونه استفاده کنید.
تفاوت New Relic با Blackfire در پروفایلینگ وردپرس چیست؟
Blackfire یک Profiler سطح کد است که Flame Graph دقیق‌تری ارائه می‌دهد و Overhead آن نزدیک به صفر است. New Relic یک APM کامل است که مانیتورینگ پیوسته، هشداردهی، و یکپارچگی با زیرساخت را نیز پوشش می‌دهد. Blackfire برای بهینه‌سازی یک تابع خاص بهتر است؛ New Relic برای درک اینکه چرا سایت در Production کند می‌شود.
آیا New Relic روی سرعت سایت تأثیر منفی می‌گذارد؟
Overhead Agent در نسخه‌های مدرن حدود ۴٪ است، اما با تنظیمات نامناسب می‌تواند بیشتر شود. با تنظیم hooks.options = threshold و transaction_tracer.threshold = 500ms، Overhead به حداقل می‌رسد. مهم‌تر از Overhead، حجم داده‌ای است که Agent به سرورهای New Relic ارسال می‌کند که می‌تواند هزینه را افزایش دهد.
چگونه بفهمم کدام افزونه وردپرس کندی را ایجاد می‌کند؟
در Tab WordPress Plugins and Themes، هر افزونه با زمان صرف‌شده نمایش داده می‌شود. اگر یک افزونه ۳۰٪ زمان اجرا را ببلعد، آن افزونه مشکوک اصلی است. سپس در Tab Hooks، می‌توانید ببینید آن افزونه در کدام Hookها فعال است و دقیقاً کدام Callback کند است.
آیا می‌توان از New Relic برای مانیتورینگ WooCommerce استفاده کرد؟
بله. New Relic به‌صورت بومی Transactionهای WooCommerce را تشخیص می‌دهد و می‌توانید صفحات محصول، سبد خرید و Checkout را تفکیک کنید. این موضوع در عیب‌یابی مشکلاتی مثل خطای پرداخت ووکامرس بسیار مفید است، چون می‌توانید ببینید کندی در کدام مرحله از Checkout رخ می‌دهد.
New Relic با WordPress Multisite چگونه کار می‌کند؟
به‌صورت پیش‌فرض، داده‌های همه سایت‌های یک شبکه Multisite در یک Application تجمیع می‌شوند. برای تفکیک داده‌ها بر اساس هر سایت، باید از تابع newrelic_set_appname() در فایل vip-config.php یا مشابه آن استفاده کنید. بدون این تنظیم، نمی‌توانید بفهمید کدام سایت در شبکه کند است.
سخن پایانی
New Relic برای وردپرس یک ابزار «خوب برای همه» نیست. برای یک وبلاگ شخصی با ترافیک پایین، Query Monitor کافی است. برای یک سایت شرکتی با ترافیک متوسط، شاید Blackfire یا ابزارهای ساده‌تر اقتصادی‌تر باشند. اما برای سایت‌های پربازدید، فروشگاه‌های اینترنتی جدی، و پروژه‌هایی که Downtime هزینه واقعی دارد، New Relic یک ضرورت مهندسی است. تفاوت آن با ابزارهای دیگر در این است که به‌جای «چه اتفاقی افتاده»، به «چرا اتفاق افتاده» پاسخ می‌دهد — و این تفاوت، همان چیزی است که یک مهندس ارشد به آن نیاز دارد.
دیدگاه مهندسی پیشرفته
از منظر معماری سیستم‌های توزیع‌شده، New Relic PHP Agent یک نمونه جالب از Instrumentation در سطح Runtime است که با استفاده از Zend Engine Hooks، بدون نیاز به تغییر کد اپلیکیشن، Observability را تزریق می‌کند. چالش اصلی این معماری، مدیریت Overhead در سیستم‌های با Throughput بالا است: هر Hook اضافه، یک Function Call Instrumented اضافه به معنای هزینه CPU و حافظه است. تنظیم threshold یک مکانیزم Sampling تطبیقی (Adaptive Sampling) است که فقط رویدادهای معنادار را ثبت می‌کند. در مقیاس بسیار بالا — مثلاً یک شبکه Multisite با هزاران سایت — حتی این Sampling نیز ممکن است کافی نباشد و باید به سمت OpenTelemetry Collector و پردازش لبه‌ای (Edge Processing) حرکت کرد. New Relic در نسخه‌های اخیر از OpenTelemetry پشتیبانی می‌کند و این مسیر، آینده Observability در وردپرس را به سمت استانداردهای باز سوق می‌دهد.
اگر این مشکل را در یک پروژه واقعی تجربه کرده‌اید، برای من جالب است بدانم کدام بخش آن بیشترین زمان را از شما گرفت. تجربه خودتان را در دیدگاه‌ها بنویسید؛ به‌خصوص اگر راه‌حل دیگری پیدا کرده‌اید که می‌تواند برای خواننده بعدی مفید باشد. 🔍
همچنین اگر می‌خواهید در مورد ابزارهای دیگر مانیتورینگ وردپرس بیشتر بدانید، پیشنهاد می‌کنم مانیتورینگ سرور و خطای افزایش مصرف CPU در وردپرس را مطالعه کنید. برای درک عمیق‌تر بهینه‌سازی کوئری‌های وردپرس نیز می‌تواند مکمل خوبی باشد.