آموزش پیدا کردن گلوگاه مصرف منابع در وردپرس

مدیریت یک سایت وردپرسی در کنار تمام مزایایی که دارد، چالشهای فنی خاص خود را نیز به همراه میآورد. یکی از رایجترین و فرسایندهترین چالشها برای مدیران سایت، مواجهه با کندی ناگهانی، افت شدید کارایی یا دریافت خطاهای محدودیت منابع است. اکثر کاربران زمانی که با این مشکلات مواجه میشوند، صرفا ظاهر ماجرا یعنی کندی لود صفحات را میبینند؛ اما ریشه این اختلالات همیشه یکسان نیست.
مشکل واقعی عملکردی میتواند ناشی از کمبود پردازنده، کمبود حافظه موقت، اختلال در پایگاه داده، کمبود پردازشگرهای PHP یا حتی کانفیگ نامناسب سرور باشد. برای حل ریشهای این بحرانها، نیاز به یک رویکرد مهندسی و متدولوژی مشخص برای عیبیابی داریم. در این راهنما، به صورت گامبهگام یاد میگیریم که چگونه گلوگاههای اصلی مصرف منابع را در سایتهای وردپرسی شناسایی و برطرف کنیم.
منظور از مصرف منابع در وردپرس چیست؟
قبل از اینکه به سراغ ابزارها و روشهای عیبیابی برویم، باید درک دقیقی از زیرساختهای سختافزاری و نرمافزاری هاست داشته باشیم. سروری که سایت شما روی آن میزبانی میشود، منابع محدودی دارد که فرآیندهای وردپرس برای پاسخگویی به هر درخواست کاربر، از آنها استفاده میکنند. این منابع اصلی شامل موارد زیر هستند:
- CPU: پردازشگر سرور که مسئولیت اجرای کدهای PHP، پردازش توابع وردپرس و اجرای دستورات سیستم را بر عهده دارد. هرچه کدهای سایت پیچیدهتر یا غیربهینهتر باشند، سیکلهای پردازشی بیشتری از سیپییو درگیر میشود.
- RAM: حافظه موقت سرور که دادههای در حال پردازش هسته وردپرس، افزونهها و قالب را به صورت موقت در خود نگه میدارد تا پردازنده بتواند سریعتر به آنها دسترسی داشته باشد.
- I/O: سرعت خواندن و نوشتن اطلاعات روی دیسک سرور است. فعالیتهایی مانند آپلود فایل، نوشتن لاگهای خطا یا خواندن فایلهای بزرگ PHP مستقیما این منبع را درگیر میکنند.
- Entry Process: تعداد اتصالات همزمانی است که وارد سایت شده و یک اسکریپت PHP را به صورت همزمان اجرا میکنند. این معیار با تعداد کاربران آنلاین متفاوت است و فقط پردازشهای فعال در یک ثانیه را ملاک قرار میدهد.
- PHP Worker: پردازشگرهای نرمافزاری هستند که درخواستهای ارسالی کاربران به سرور را دریافت کرده، کدهای PHP را اجرا و خروجی را به مرورگر کاربر تحویل میدهند.
یک نکته بسیار حیاتی که مدیران سایت باید به آن توجه کنند این است که افزایش ترافیک و بازدید ورودی، همیشه دلیل اصلی مصرف بالای منابع نیست. بارها دیده شده است که یک سایت با کمتر از ده کاربر آنلاین، به دلیل وجود یک افزونه خراب, کدهای غیراستاندارد یا یک حلقه تکرار بیانتهای پردازشی، کل منابع سرور را به طور کامل درگیر کرده و سایت را از دسترس خارج کرده است.
از کجا بفهمیم مشکل سایت از مصرف منابع است؟
سیستم مدیریت محتوای وردپرس هنگام مواجهه با کمبود منابع سختافزاری، علائم مشخصی از خود بروز میدهد. شناخت این علائم به شما کمک میکند تا در همان مراحل اولیه، متوجه بروز بحران زیرساختی شوید.
کند شدن ناگهانی و شدید لود صفحات، سفید شدن صفحه سایت یا همان خطای معروف مرگبار وردپرس، کندی شدید پنل مدیریت وردپرس و بروز خطای تایماوت از بارزترین نشانهها هستند. همچنین یکی از اصلیترین نشانههای اتمام منابع، دریافت خطای 503 یا خطاهای مربوط به Resource Limit است که نشان میدهد سرور دیگر توانایی پاسخگویی به درخواستهای جدید را ندارد. این وضعیت معمولا در زمانهای اوج بازدید یا هنگام اجرای پردازشهای سنگین در پسزمینه سایت رخ میدهد.
تفاوت کندی ناشی از هاست با کندی ناشی از قالب یا افزونه
تشخیص اینکه منشا اصلی مشکل کجاست، اولین قدم تخصصی در بهینهسازی است. اگر کندی سایت شما به صورت یکنواخت در تمام بخشها، حتی در یک صفحه استاتیک و بدون المانهای داینامیک وجود دارد، یا اگر در ساعات خاصی از شبانهروز بدون تغییر در آمار بازدید سایت دچار افت سرعت میشوید، احتمال بالا بودن بار سرور میزبانی یا اشتراکی بودن ضعیف منابع وجود دارد.
در مقابل، اگر بخش فرانتاند سایت کند است اما پنل مدیریت سرعت مناسبی دارد، یا اگر کندی صرفا در صفحات خاصی مانند صفحه محصول یا سبد خرید رخ میدهد، منشا مشکل قطعا ساختار قالب، لود بیش از حد اسکریپتها یا اجرای کوئریهای سنگین توسط افزونههای آن بخش است.
یک نکته بسیار حیاتی که مدیران سایت باید به آن توجه کنند این است که افزایش ترافیک و بازدید ورودی، همیشه دلیل اصلی مصرف بالای منابع نیست. بارها دیده شده است که یک سایت با کمتر از ده کاربر آنلاین، به دلیل وجود یک افزونه خراب, کدهای غیراستاندارد یا یک حلقه تکرار بیانتهای پردازشی، کل منابع سرور را به طور کامل درگیر کرده و سایت را از دسترس خارج کرده است.
بررسی مصرف CPU و RAM در وردپرس
پردازنده و حافظه موقت دو بال اصلی سرور برای اجرای وردپرس هستند. بالا رفتن مصرف سیپییو معمولا ناشی از اجرای کوئریهای سنگین در پایگاه داده، فعالیت شدید رباتهای جستجوگر و کراولرها، یا کدهای غیراستاندارد در افزونهها است. در طرف دیگر، مصرف بالای رم بیشتر به فعال بودن افزونههای متعدد، اجرای پردازشهای همزمان PHP و لود شدن توابع سنگین در حافظه مربوط میشود.
چه زمانی مصرف CPU خطرناک محسوب میشود؟
نوسانات موقت در مصرف سیپییو کاملا طبیعی است؛ مثلا هنگام انتشار یک پست جدید یا اجرای یک خروجی در دیتابیس، مصرف پردازنده ممکن است برای چند لحظه کوتاه بالا برود. اما خطر واقعی زمانی است که مصرف پردازنده به صورت پایدار و مداوم روی درصدهای بالا (نزدیک به صد درصد) باقی بماند. این وضعیت باعث ایجاد صف طولانی از درخواستهای معطل در سرور شده و در نهایت منجر به داون شدن سایت میشود؛ در این شرایط، مدیر سایت باید به سراغ مراحل عیبیابی باز نشدن سایت رفته و تمام بخشهای سرور میزبان را واررسی کند.
چرا بعضی سایتها با بازدید کم هم CPU بالایی دارند؟
این پارادوکس برای بسیاری از وبمسترها پیش میآید. علت اصلی این اتفاق، پردازشهای پسزمینه وردپرس است. وظایف زمانبندی شده یا همان کرونجابهای وردپرس که در پسزمینه اجرا میشوند (مانند بررسی بهروزرسانیها، ارسال ایمیلهای انبوه، یا افزونههای آمارگیر داخلی)، میتوانند بدون نیاز به بازدیدکننده واقعی، پردازنده را به شدت درگیر کنند. همچنین، حملات هکری و تلاش برای ورودهای مکرر به پیشخوان سایت نیز منابع پردازنده را به شدت مصرف میکند.
چگونه افزونههای سنگین وردپرس را شناسایی کنیم؟
افزونهها بزرگترین مزیت و در عین حال میتوانند بزرگترین نقطه ضعف یک سایت وردپرسی باشند. برای پیدا کردن افزونههایی که منابع سیستم را بلعیدهاند، نباید به صورت حدسی عمل کرد، بلکه باید از ابزارهای مانیتورینگ دقیق استفاده کنیم.
یکی از بهترین ابزارهای رایگان و تخصصی برای این کار، افزونه Query Monitor است. این ابزار به شما اجازه میدهد میزان مصرف حافظه، زمان اجرای کوئریها و درخواستهای پنهان هر افزونه را به تفکیک مشاهده کنید. افزونه Health Check نیز ابزار رسمی دیگری است که به عیبیابی بدون تاثیر روی تجربه کاربران کمک میکند. در سطوح پیشرفتهتر و سرورهای اختصاصی، ابزار New Relic جامعترین لاگها را ارائه میدهد. همچنین ابزار درونساختی Resource Usage در سیپنل یا دایرکتادمین، دید کلی خوبی از وضعیت کلی مصرف به شما میدهد.
هنگام بررسی افزونهها باید چهار فاکتور حیاتی را زیر نظر بگیرید: کوئریهای سنگین دیتابیس که توسط افزونه ایجاد میشوند، درخواستهای خارجی از طریق API به سایتهای دیگر که باعث معطلی پردازش میشوند، کرونجابهای غیراستاندارد و در نهایت میزان حافظه ثابتی که افزونه به محض فعال شدن در رم اشغال میکند.
افزونههای کش هم میتوانند باعث مصرف منابع شوند؟
پاسخ این سوال مثبت است. هرچند هدف افزونههای کش کاهش مصرف منابع است، اما کانفیگ اشتباه آنها تاثیر عکس دارد. مثلا قابلیت پیشبارگذاری یا همان Preload در افزونههای کش، اگر به صورت تهاجمی تنظیم شود، سعی میکند تمام صفحات سایت را به صورت همزمان در پسزمینه لود و کش کند؛ این فرآیند مصرف پردازنده و رم سرور را به شدت و به صورت ناگهانی افزایش میدهد.
بررسی دیتابیس؛ یکی از مهمترین گلوگاههای وردپرس
پایگاه داده قلب تپنده وردپرس است و هرگونه لود اضافه در آن، کل سیستم را با تاخیر مواجه میکند. دیتابیسهای بهینهسازی نشده معمولا به دلیل انباشت جدولهای سنگین ناشی از افزونههای حذف شده، حجم بالای دادههای خودکار لود شونده، تعداد بیش از حد رونوشتهای پستها، ترنزینتهای منقضی شده و کوئریهای کند، دچار افت عملکرد میشوند.
چگونه queryهای سنگین را پیدا کنیم؟
با فعال کردن افزونه مدیریت بررسی کوئریها (Query Monitor)، وارد هر صفحهای از سایت که شوید، میتوانید لیست تمام کوئریهای اجرا شده در دیتابیس را ببینید. کوئریهایی که با رنگ قرمز مشخص شدهاند یا زمان اجرای آنها بیش از چند میلیثانیه طول کشیده است، گلوگاههای اصلی شما هستند. این ابزار دقیقا نشان میدهد که کدام تابع از کدام افزونه، این درخواست سنگین را به پایگاه داده فرستاده است.
چرا دیتابیس بزرگ باعث کندی wp-admin میشود؟
پیشخوان وردپرس برای بالا آمدن نیاز دارد اطلاعات زیادی را از جدول گزینهها فراخوانی کند. اگر حجم دادههای خودکار لود شونده بالا باشد، دیتابیس مجبور است در هر بار لود پیشخوان، مگابایتها داده غیرضروری را جستجو و بارگذاری کند. این مساله مستقیما سرعت کار در پنل مدیریت را کاهش میدهد و لود صفحات مدیریتی را با تاخیر مواجه میکند.
PHP Worker چیست و چرا روی سرعت سایت تاثیر دارد؟
برای درک مفهوم ورکر PHP، سرور را مانند یک بانک و ورکرهای PHP را مانند باجههای پاسخگویی در نظر بگیرید. هر زمان که کاربری وارد سایتی میشود و درخواست لود یک صفحه داینامیک را میدهد، یک ورکر به کار گرفته میشود تا کدهای آن صفحه را پردازش کند. این ورکر تا زمان پایان پردازش و تحویل صفحه به کاربر، درگیر باقی میماند. اگر تعداد ورکرهای تخصیص یافته به سایت کم باشد، درخواستهای کاربران بعدی در صف انتظار قرار میگیرند.
به عنوان یک مثال واقعی، یک سایت فروشگاهی بزرگ را در نظر بگیرید که یک کمپین تخفیفاتی راهاندازی کرده است. در زمان کمپین، صدها کاربر به صورت همزمان وارد فرآیند خرید، افزودن به سبد خرید و تسویه حساب میشوند. از آنجایی که صفحات سبد خرید و تسویه حساب داینامیک هستند و نمیتوان آنها را کش کرد، هر کاربر مستقیما یک PHP Worker را اشغال میکند. اگر تعداد ورکرهای هاست محدود باشد، صف عظیمی شکل میگیرد، سایت به شدت کند شده و کاربران با خطای عدم دسترسی سرور مواجه میشوند، در حالی که ممکن است مصرف کلی سیپییو هنوز به سقف خود نرسیده باشد.
تاثیر کراولرها و رباتها روی مصرف منابع وردپرس
تمام ترافیک ورودی به سایت شما توسط انسانها ایجاد نمیشود. بخش عمدهای از درخواستهای ارسالی به سرور، متعلق به رباتها است. این رباتها شامل کراولرهای مفیدی مثل گوگلبات، رباتهای موتورهای جستجوی دیگر، رباتهای پایشگر هوش مصنوعی و متاسفانه رباتهای مخرب و هکرهایی هستند که حملات بروتفورس را روی سایت اجرا میکنند.
چگونه بفهمیم رباتها منابع سایت را مصرف میکنند؟
برای این کار باید به سراغ بررسی لاگهای دسترسی سرور بروید. ابزارهایی مانند بخش آمار سیپنل نشان میدهند که کدام آیپایها یا کدام شناسههای کاربری (User-Agent) بیشترین تعداد درخواست را به سایت فرستادهاند. اگر متوجه شدید رباتهای متفرقه یا ابزارهای پایش هوش مصنوعی در حال اسکن مداوم سایت شما هستند، باید دسترسی آنها را محدود کنید.
محدود کردن XML-RPC و wp-login
فایل XML-RPC در وردپرس برای ارتباطات از راه دور استفاده میشود، اما امروزه به یکی از اهداف اصلی حملات داس و بروتفورس تبدیل شده است. هکرها میتوانند با ارسال صدها درخواست همزمان به این فایل، پردازنده سرور را کاملا فلج کنند. غیرفعال کردن این قابلیت در صورت عدم استفاده و همچنین محدود کردن نرخ درخواستها به صفحه ورود سایت از طریق ابزارهایی مانند کلودفلر، گام مهمی در کاهش مصرف منابع هدر رفته است.
کش وردپرس چگونه مصرف منابع را کاهش میدهد؟
سیستم کش با ذخیره کردن پاسخ درخواستها، نیاز به پردازش مجدد کدهای PHP و فراخوانیهای پایگاه داده را از بین میبرد. انواع مختلفی از کش وجود دارد که فعالسازی درست آنها بار سرور را به شکل چشمگیری کاهش میدهد. کش صفحه، صفحات داینامیک را به فایلهای استاتیک تبدیل میکند. سیستمهای کش آبجکت دادههای پرتکرار دیتابیس را در حافظه رم نگه میدارند و سیستم کش اپکد نیز کدهای کامپایل شده PHP را ذخیره میکند تا سرعت اجرا بالا برود. بهرهگیری از ابزارهایی نظیر ردیس و لایتاسپید کش نمونههای موفقی از این فناوریها هستند.
چرا بعضی سایتها با وجود کش هنوز کند هستند؟
این مشکل معمولا زمانی رخ میدهد که کش سایت برای کاربران لاگین شده (مثل مدیران یا مشتریان فروشگاه) غیرفعال است و به دلیل عدم استفاده از کش آبجکت، درخواستهای بخش مدیریت یا سبد خرید مستقیما سرور را درگیر میکنند. همچنین، در صورت وجود کدهای مخرب یا تداخل در ساختار قالب، ممکن است سیستم کش مدام منقضی شده و سرور مجبور به بازسازی دایمی فایلهای کش شود که خود این فرآیند مصرف منابع را بالاتر میبرد.
چه زمانی مشکل واقعا از هاست است؟
گاهی اوقات پس از روزها تلاش، بهینهسازی کدهای قالب، حذف افزونههای سنگین و اصلاح ساختار دیتابیس، همچنان مشکل کندی و پر شدن منابع پابرجا میماند. در این سناریو، مشکل دیگر به نرمافزار یا وردپرس مربوط نمیشود، بلکه ریشه در لایه زیرساخت و کیفیت سرویس میزبانی دارد.
بسیاری از شرکتهای میزبانی نامعتبر، برای سودآوری بیشتر دست به اقداماتی مانند بیشفروشی میزنند؛ یعنی روی یک سرور واحد، بیش از حد استاندارد سایت میزبانی میکنند. این کار باعث میشود منابع اشتراکی ضعیف سرور بین صدها سایت تقسیم شود و فعالیت یک سایت دیگر روی سرور، مستقیما روی کارایی سایت شما تاثیر منفی بگذارد. محدودیتهای شدید اعمال شده روی پردازنده، استفاده از دیسکهای قدیمی و کند به جای درایوهای پرسرعت، عدم استفاده از وبسرورهای بهینه مانند لایتاسپید و تخصیص تعداد بسیار کمی PHP Worker، از دلایل اصلی ضعف زیرساخت هاست هستند.
چگونه بفهمیم هاست بیش از حد شلوغ است؟
معیار اصلی برای سنجش این وضعیت، زمان پاسخگویی اولیه سرور یا همان فرکانس تاخیر اولیه است. اگر متوجه شدید که این زمان حتی روی یک صفحه کاملا خالی یا یک فایل متنی ساده استاتیک نیز بسیار بالا است، یا اگر سرعت سایت شما در ساعات مختلف روز بدون تغییر در میزان بازدید خودتان نوسان شدیدی دارد، سرور میزبانی شما تحت بار شدید ناشی از سایتهای همسایه قرار دارد که در این حالت مهاجرت به سرور اختصاصی که به طور کامل منابع یک سرور فیزیکی را در اختیار وبسایت خدمات شما میگذارد میتواند بهترین و منطقیترین حرکت باشد. با مهاجرت به این پلن میزبانی نگرانی از بابت مصرف منابع توسط سایتهای همسایه نیستید به این دلیل که منابع سرور میزبان به طور کامل در اختیار شماست.
آیا ارتقای هاست واقعاً مشکل را حل میکند؟
اگر مطمئن شدهاید که کدهای سایت بهینه هستند و دیتابیس شما در سلامت کامل قرار دارد، بله؛ ارتقای سرویس تنها راهکار منطقی است. انتقال به یک زیرساخت قدرتمندتر به شما منابع اختصاصیتر و پایداری بالاتری میدهد. اگر زیرساخت فعلی پاسخگوی نیازهای پردازشی سایت نباشد، خرید هاست وردپرس با کانفیگ اختصاصی، هارد دیسکهای فوق سریع و تعداد مناسب ورکر، خط پایانی بر تمام خطاهای محدودیت منابع و افت سرعتهای ناگهانی خواهد بود.
چکلیست کامل پیدا کردن گلوگاه وردپرس
برای اینکه عیبیابی را به صورت علمی و بدون سردرگمی پیش ببرید، این چکلیست مرحلهای را به ترتیب اجرا کنید:
- بررسی مصرف CPU: مانیتورینگ میزان درگیری پردازنده از طریق پنل هاست در بازههای زمانی مختلف.
- بررسی RAM: سنجش میزان فضای اشغال شده حافظه موقت و پر شدن لایه بالایی آن.
- تست افزونهها: غیرفعالسازی موقت افزونههای مشکوک و سنجش تغییرات سرعت.
- بررسی Query Monitor: تحلیل دقیق زمان اجرای کوئریها، درخواستهای بیرونی و تداخلات تکراری.
- تست کش: اطمینان از کارکرد صحیح سیستم کش صفحه و کش آبجکت در صفحات داینامیک و استاتیک.
- بررسی دیتابیس: پاکسازی جدول گزینهها و حذف دادههای بدون استفاده افزونههای قدیمی.
- بررسی رباتها: آنالیز فایلهای لاگ سرور برای شناسایی و مسدودسازی کراولرهای مخرب و جاسوس.
- تست TTFB: سنجش زمان پاسخگویی اولیه سرور در موقعیتهای جغرافیایی مختلف.
- بررسی لاگ خطاها: مطالعه دقیق فایل لاگ خطاهای وردپرس برای پیدا کردن توابع معیوب و اخطارهای PHP.
- بررسی منابع هاست: تطبیق نیازهای واقعی سایت با محدودیتهای پکیج میزبانی فعلی.
اشتباهات رایج هنگام عیبیابی مصرف منابع
در مسیر حل مشکلات کارایی، تصمیمات عجولانه و بدون تحلیل فنی معمولا اوضاع را وخیمتر میکنند. یکی از بزرگترین اشتباهات، حذف یا غیرفعال کردن تصادفی و فلهای افزونهها بدون اندازهگیری تاثیر دقیق آنها است؛ این کار ممکن است دیتای حیاتی سایت را از بین ببرد بدون اینکه مشکل منابع حل شود.
اشتباه رایج دیگر، نصب همزمان چند افزونه کش به امید کسب سرعت بیشتر است. این اقدام عملا باعث ایجاد تداخل شدید در بازنویسی فایلها، ایجاد حلقههای پردازشی بیپایان و در نهایت قفل شدن کامل دیتابیس و پردازنده سرور میشود. استفاده از قالبهای سنگین و چندمنظوره که برای هر ویژگی کوچک نیاز به لود دهها اسکریپت دارند، نادیده گرفتن اهمیت بهینهسازی دیتابیس و در نهایت تست کردن تغییرات و کدهای جدید مستقیما روی سایت اصلی بدون استفاده از محیط استیجینگ، از دیگر خطاهای استراتژیکی است که فرآیند رفع مشکل را با تاخیر مواجه میکند.
راهکار نهایی برای مدیریت بهینه زیرساخت وردپرس
مهندسی کارایی وردپرس یک فرآیند مداوم است و نیاز به پایش مستمر دارد. همانطور که بررسی کردیم، ریشه خطاهای کمبود منابع و کندی سایت همیشه به حجم بازدید بالا ختم نمیشود؛ بلکه در بسیاری از موارد، اختلال در عملکرد یک افزونه، کوئریهای بهینهنشده پایگاه داده یا هجوم رباتهای مخرب، عاملان اصلی اشغال پردازنده و رم سرور هستند.
با استفاده از ابزارهای مانیتورینگ و دنبال کردن یک چکلیست اصولی، میتوان به راحتی منشا دقیق گلوگاهها را پیدا کرد. در نهایت، کیفیت و کانفیگ لایه میزبانی نقش تعیینکنندهای دارد و انتخاب یک هاست مناسب با منابع واقعی و کانفیگ اختصاصی برای سایتهای وردپرسی پربازدید، حیاتیترین گام برای تضمین پایداری و سرعت تجارت آنلاین شما است.
سوالات متداول
این خطاها زمانی رخ میدهند که وبسرور یا هاست شما به دلیل اتمام منابع سختافزاری مانند پردازنده، رم یا پر شدن سقف پردازشهای همزمان، دیگر قادر به پاسخگویی به درخواستهای جدید نباشد. کدهای غیراستاندارد، افزونههای سنگین، تداخلات شیوه ذخیرهسازی کش و هجوم رباتهای مخرب از دلایل اصلی آن هستند.
دقیقترین روش استفاده از ابزارهای مانیتورینگ است، اما به عنوان یک تست اولیه میتوانید افزونهها را تکتک غیرفعال کرده و تغییرات سرعت لود یا میزان مصرف منابع را در پیشخوان هاست بسنجید. افزونههایی که پردازشهای پسزمینه مداوم یا آمارگیر داخلی دارند معمولا متهمان اول هستند.
خیر؛ تعداد افزونهها بی تاثیر نیست اما ساختار و کیفیت کدهای آنها اهمیت بیشتری دارد. فعال بودن یک افزونه غیراستاندارد با پردازشهای سنگین یا اجرای همزمان اسکریپتهای پیاچپای بدون محدودیت حافظه میتواند بسیار بیشتر از ده افزونه سبک و بهینه، رم سرور را اشغال کند.
وقتی دیتابیس شلوغ و بهینهنشده باشد، هر کوئری برای پیدا کردن اطلاعات مورد نظر باید حجم عظیمی از دادههای بیهوده مانند رونوشتها یا ترنزینتهای منقضی شده را جستجو کند. این جستجوهای طولانی مستقیما سیکلهای پردازشی سیپییو را درگیر کرده و مصرف آن را بالا میبرد.
پهنای باند مربوط به حجم کل دادههای تبادل شده بین سایت و کاربران است، در حالی که پردازنده و رم منابع پردازشی سرور هستند. یک سایت ممکن است پهنای باند زیادی مصرف نکند، اما به دلیل یک کد مخرب یا حلقه تکرار خطادار، پردازنده هاست را به طور کامل درگیر و پر کند.
































شما میتوانید دیدگاه خود را در مورد این مطلب با ما با اشتراک بگذارید.