A2 لاگ عملکرد

مسئله تجاری

درخواست‌های سبد، جست‌وجو و افزودن به سبد به‌صورت متناوب کند بودند، و «متناوب» همان قسمت سخت ماجراست. استیجینگ نمی‌توانست بازتولیدش کند چون ماشه‌اش ترافیک واقعی روی کاتالوگ واقعی بود. هر پروفایلری که همه‌ی درخواست‌ها را ثبت کند خودش تبدیل به مسئله‌ی کارایی می‌شود، پس لاگر باید روی درخواست‌های سالم ارزان می‌بود و فقط روی ناسالم‌ها پرجزئیات.

آنچه تحویل دادم

• a2-perf-logger.php، یک افزونه‌ی MU چهارصدوپنجاه‌وهشت‌خطی نسخه‌ی ۱.۲.۰ که در یک فایل لاگ چرخشی با سقف ۵ مگابایت می‌نویسد.
• سیاست ثبت پله‌ای: هرچه از ۸۰۰ms رد شود لاگ می‌شود، هرچه از ۲٫۵ ثانیه رد شود ثبت عمیق می‌گیرد و بقیه با نرخ ۵٪ نمونه‌برداری می‌شوند.
• انتساب کوئری کند: کوئری‌های بالای ۲۵۰ms همراه استک فراخوان ثبت می‌شوند، تا یک کوئری به افزونه‌ای که صادرش کرده گره بخورد نه اینکه به شکل یک رشته‌ی SQL برهنه گزارش شود.
• دسته‌بندی درخواست، طوری که مسیرهای سبد، جست‌وجو و افزودن به سبد صرف‌نظر از زمان‌بندی همیشه لاگ می‌شوند و اسِت‌ها و ۴۰۴ها نادیده گرفته می‌شوند.
• خروجی کران‌دار در هر سطح: حداکثر ۶ کوئری کند، ۱۰ مالک کوئری، ۸ فراخوان، ۱۰ جدول، ۸ فریم استک و ۱۲ خطا در هر رکورد.
• ثبت کوکی، هدر و نشانه‌های بات، که همان چیزی است که یک درخواست کند از مشتری لاگین‌شده را از یک درخواست کند خزنده جدا می‌کند.

رویکرد فنی

• تصمیم به لاگ‌کردن در shutdown گرفته می‌شود، وقتی مدت واقعی معلوم است، پس یک درخواست سریع هرگز هزینه‌ی ماشین‌آلات ثبت را نمی‌پردازد.
• لاگ کوئری در نخستین هوکی که اجرا می‌شود روشن می‌شود تا کوئری‌های سایر افزونه‌های MU از دست نروند، و در چند هوک بعدی دوباره تلاش می‌شود تا اگر چیزی خاموشش کرد جبران شود.
• مسیر لاگ به یک محل اصلی resolve می‌شود و به uploads برمی‌گردد، و دایرکتوری اگر نباشد ساخته می‌شود؛ لاگری که روی نصب تازه بی‌صدا شکست بخورد از نبودنش بدتر است.
• هر فهرست با یک ثابت صریح سقف دارد نه اینکه موقع نوشتن بریده شود، که مانع می‌شود یک درخواست بیمار یک مگابایت لاگ تولید کند.
• کلاس‌های حساس حتی وقتی سریع‌اند همیشه ثبت می‌شوند، چون دانستن اینکه «عادی» روی مسیر پرداخت چه شکلی است همان چیزی است که یک نقطه‌ی پرت را خوانا می‌کند.

نتیجه و شواهد

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

اهمیت برای کارفرما

بیشتر توصیه‌های کارایی ووکامرس کلی‌اند چون بیشتر آدم‌ها دارند حدس می‌زنند. داشتن شواهد به‌ازای هر درخواست از سایت زنده همان چیزی است که کار را محدود نگه داشت، و اصلاح‌های محدود همان‌هایی هستند که حادثه نمی‌سازند.