لگ سرور MTA همیشه به معنی ضعیفبودن VPS نیست. ممکن است پردازنده سرور قدرت کافی داشته باشد، اما یک اسکریپت غیربهینه، کوئری کند دیتابیس، ارسال بیشازحد اطلاعات یا مشکل شبکه باعث اختلال شود.
برای رفع لگ سرور MTA ابتدا باید نوع اختلال مشخص شود. افزایش منابع سرور بدون پیداکردن علت اصلی ممکن است فقط مشکل را برای مدتی پنهان کند و هزینه پروژه را افزایش دهد.
منظور از لگ سرور MTA چیست؟
کاربران معمولاً هرگونه کندی، پرش تصویر یا تأخیر را لگ مینامند؛ اما این مشکلات ممکن است دلایل متفاوتی داشته باشند.
- تأخیر در اجرای دستورات گیممود
- کندشدن بازشدن پنلها
- با تأخیر ثبتشدن شلیک یا برخورد
- پرش بازیکنان و خودروها
- افزایش ناگهانی پینگ
- کندشدن ورود یا ذخیره اطلاعات کاربران
- افت فریم بازی روی سیستم بازیکن
- توقف موقت یا ریاستارتشدن سرور
هرکدام از این نشانهها مسیر عیبیابی متفاوتی دارند. برای مثال، افت FPS یک بازیکن ممکن است از اسکریپت کلاینت یا سیستم شخصی او باشد، درحالیکه تأخیر همزمان برای همه کاربران بیشتر به سرور، دیتابیس یا شبکه مربوط میشود.
انواع لگ در سرور MTA
لگ پردازشی سرور
در این حالت پردازنده نمیتواند محاسبات گیممود را بهموقع انجام دهد. ممکن است اجرای فرمانها، تایمرها، رویدادها و سیستمهای مختلف با تأخیر همراه شوند.
لگ شبکه
پینگ بالا، نوسان پینگ، Packet Loss یا کمبود پهنای باند میتواند باعث پرش بازیکنان، تأخیر در همگامسازی و قطع اتصال شود.
لگ دیتابیس
کوئریهای کند یا اجرای همزمان درخواستهای زیاد میتواند ورود کاربران، ذخیره اطلاعات، دریافت موجودی و سیستمهای وابسته به دیتابیس را کند کند.
لگ سمت کلاینت
برخی Resourceها روی سیستم بازیکن اجرا میشوند. کد سنگین، رابط گرافیکی غیربهینه، تصاویر بزرگ یا اجرای عملیات زیاد در هر فریم میتواند FPS بازیکن را کاهش دهد، حتی اگر خود سرور مشکلی نداشته باشد.
لگ ناشی از کمبود حافظه
افزایش مداوم مصرف رم، باقیماندن Elementهای غیرضروری، تایمرهای حذفنشده یا نشت حافظه میتواند به کندی، استفاده از Swap یا توقف سرور منجر شود.
اولین قدم برای رفع لگ سرور MTA
قبل از تغییر تنظیمات، زمان و شرایط بروز لگ را ثبت کنید:
- لگ از چه زمانی شروع میشود؟
- آیا با افزایش تعداد بازیکنان بیشتر میشود؟
- آیا فقط پس از اجرای یک Resource رخ میدهد؟
- آیا هنگام ذخیره یا دریافت اطلاعات ایجاد میشود؟
- آیا همه کاربران همزمان مشکل دارند؟
- آیا پینگ بالا میرود یا فقط اجرای دستورات کند میشود؟
- آیا مصرف CPU یا RAM افزایش پیدا میکند؟
- آیا در کنسول خطا یا هشدار ثبت میشود؟
این اطلاعات مشخص میکنند بررسی باید از پردازنده، اسکریپت، دیتابیس، شبکه یا سیستم کاربران شروع شود.
بررسی لگ با Performance Browser
ابزار Performance Browser یکی از مهمترین ابزارهای رسمی برای بررسی عملکرد سرور MTA است. این ابزار مصرف پردازنده و حافظه Resourceها و بخشهای مختلف سرور را نمایش میدهد.
برای اجرای آن ابتدا در کنسول سرور دستور زیر را وارد کنید:
start performancebrowserسپس با یک حساب دارای دسترسی لازم، آدرس زیر را در مرورگر باز کنید:
http://SERVER-IP:22005/performancebrowser/بهجای SERVER-IP باید آدرس سرور قرار بگیرد. پورت HTTP پیشفرض MTA معمولاً 22005 است، مگر اینکه در تنظیمات تغییر کرده باشد.
نسخه داخل بازی این ابزار نیز با نام IPB در منابع رسمی وجود دارد و معمولاً پس از ورود با حساب مدیر از طریق دستور زیر اجرا میشود:
/ipbبررسی Threadهای اصلی سرور
در بخش Server info ابزار Performance Browser میتوان مصرف بخشهای مختلف سرور را مشاهده کرد:
| بخش | وظیفه اصلی | نشانه احتمالی مشکل |
|---|---|---|
| Logic Thread | اجرای اسکریپتهای Lua و منطق گیممود | تأخیر در فرمانها، تایمرها و سیستمها |
| Sync Thread | مدیریت همگامسازی عناصر | پرش یا تأخیر در نمایش بازیکنان و خودروها |
| RakNet Thread | ارسال و دریافت بستههای شبکه | اختلال شبکه، حجم بالای رویدادها یا Element Data |
| DB Thread | پردازش عملیات دیتابیس | کندی ورود، ذخیره یا دریافت اطلاعات |
اگر Logic Thread بهطور مداوم مصرف بالایی دارد، باید Resourceها و توابع Lua بررسی شوند. اگر DB Thread در زمان لگ بالا میرود، احتمال وجود کوئری سنگین یا درخواستهای بیشازحد دیتابیس بیشتر است.
مصرف کلی CPU بهتنهایی کافی نیست. ممکن است میانگین کلی پردازنده پایین باشد، اما یک Thread اصلی به محدودیت خود رسیده باشد.
پیداکردن اسکریپت سنگین با Lua Timings
در Performance Browser وارد بخش Lua timings شوید. این قسمت مقدار زمان پردازنده مصرفشده توسط هر Resource را در بازههای مختلف نشان میدهد.
ستونهای مهم معمولاً شامل موارد زیر هستند:
- درصد مصرف پردازنده
- مجموع زمان اجرا
- تعداد دفعات فراخوانی
- میانگین زمان هر اجرا
- بیشترین زمان ثبتشده
برای مشاهده جزئیات توابع داخل یک Resource میتوان از گزینه d استفاده کرد. در این حالت فایل، خط یا تابعی که بیشترین زمان پردازنده را مصرف کرده است مشخص میشود.
Resource مشکوک را بلافاصله حذف نکنید. ابتدا رفتار آن را در زمان حضور بازیکنان، اجرای سیستمهای مختلف و بازههای زمانی متفاوت بررسی کنید.
تست توقف Resourceهای مشکوک
پس از تهیه بکاپ و در زمانی که اختلالی برای کاربران ایجاد نمیشود، میتوان Resource مشکوک را موقتاً متوقف کرد:
stop resource-nameاگر پس از توقف آن، مصرف پردازنده یا لگ کاهش پیدا کرد، احتمالاً مشکل از همان Resource یا ارتباط آن با بخشهای دیگر است.
برای اجرای دوباره:
start resource-nameاین آزمایش بهتر است روی نسخه تست پروژه انجام شود. متوقفکردن Resourceهای اصلی روی سرور فعال ممکن است باعث ازدسترفتن داده یا اختلال در گیممود شود.
تایمرهای پرتعداد و Loopهای سنگین
یکی از دلایل رایج مصرف بالای پردازنده، اجرای مداوم یک تابع در فاصلههای زمانی بسیار کوتاه است.
- تایمرهای ۵۰ یا ۱۰۰ میلیثانیهای بدون نیاز واقعی
- Loop روی همه بازیکنان در هر اجرا
- Loop روی همه خودروها یا Elementها
- جستوجوی تکراری اطلاعاتی که میتوان ذخیره کرد
- ایجاد چند تایمر مشابه برای هر بازیکن
- حذفنکردن تایمر هنگام خروج بازیکن یا توقف Resource
قبل از ایجاد تایمر جدید بررسی کنید آیا همان عملیات را میتوان هنگام وقوع یک رویداد مشخص انجام داد. اجرای کد هنگام نیاز معمولاً بهتر از بررسی دائمی وضعیت است.
تأثیر onClientRender بر افت فریم بازیکنان
رویداد onClientRender در هر فریم بازی اجرا میشود. بسته به FPS کاربر ممکن است تابع متصل به آن دهها بار در هر ثانیه فراخوانی شود.
قرارگرفتن عملیات سنگین در این رویداد میتواند باعث افت FPS یا حتی ناپایداری سمت کلاینت شود.
- Loopهای بزرگ را در هر فریم اجرا نکنید.
- اطلاعات ثابت را در هر فریم دوباره محاسبه نکنید.
- از دریافت مکرر اطلاعات غیرضروری خودداری کنید.
- تصاویر و فونتها را یکبار ایجاد و مدیریت کنید.
- توابع رسم را فقط هنگام نمایش واقعی رابط اجرا کنید.
- Event Handler را پس از بستهشدن پنل حذف کنید.
اگر لگ فقط برای کاربران دارای یک پنل، HUD یا سیستم گرافیکی خاص رخ میدهد، کدهای کلاینت و بخش onClientRender باید بررسی شوند.
استفاده زیاد از setElementData
Element Data بهصورت پیشفرض میان سرور و کلاینتها همگامسازی میشود. استفاده پرتعداد از setElementData میتواند حجم زیادی ترافیک و پردازش شبکه ایجاد کند.
مشکلات رایج عبارتاند از:
- تغییر Element Data در تایمرهای کوتاه
- ارسال اطلاعاتی که فقط سرور به آن نیاز دارد
- همگامسازی یک مقدار برای همه بازیکنان بدون ضرورت
- استفاده داخل onClientRender
- ذخیره اطلاعات موقت در Element Data بهجای جدول Lua
برای اطلاعاتی که فقط داخل سرور استفاده میشوند، معمولاً جدول Lua یا متغیر داخلی مناسبتر است. برای ارسال اطلاعات به یک بازیکن مشخص نیز میتوان از رویداد هدفمند استفاده کرد.
در نسخههای جدیدتر MTA امکان استفاده از حالت subscription برای Element Data سمت سرور فراهم شده است تا اطلاعات فقط برای کاربران لازم ارسال شود.
بررسی بستههای شبکه در Performance Browser
در بخش Event Packet usage میتوان تعداد بستههای تولیدشده توسط triggerClientEvent و setElementData را مشاهده کرد.
به ستون pkt/sec توجه کنید. اگر یک رویداد یا Element Data در هر ثانیه تعداد بسیار زیادی بسته تولید میکند، باید بررسی شود که آیا ارسال آن ضروری است یا خیر.
- اطلاعات را فقط برای بازیکنان موردنیاز ارسال کنید.
- از ارسال پیشفرض به root بدون ضرورت خودداری کنید.
- دادههای تکراری را دوباره نفرستید.
- چند رویداد کوچک مرتبط را در صورت امکان مدیریت کنید.
- حجم جدولها و آرگومانهای ارسالی را کاهش دهید.
در triggerClientEvent میتوان گیرنده را یک بازیکن یا گروه مشخص تعیین کرد. ارسال همه رویدادها برای تمام کاربران باعث مصرف غیرضروری شبکه و پردازنده کلاینتها میشود.
بررسی خطاهای اسکریپت با debugscript
خطاهای تکرارشونده ممکن است علاوه بر خرابکردن عملکرد یک سیستم، فایل Log را نیز بهسرعت بزرگ کنند.
برای نمایش خطاها و هشدارها در محیط تست میتوان از دستور زیر استفاده کرد:
debugscript 2برای نمایش اطلاعات کاملتر:
debugscript 3سطح ۳ ممکن است حجم زیادی پیام ایجاد کند؛ بنابراین بهتر است برای عیبیابی موقت استفاده شود. خطاهای تکراری، هشدارهای دیتابیس و پیامهای مربوط به Resourceهای خاص را بررسی کنید.
مشکلات دیتابیس و لگ سرور MTA
اگر لگ هنگام ورود بازیکن، بازکردن پنل، خرید آیتم، ذخیره اطلاعات یا دریافت لیستها رخ میدهد، دیتابیس یکی از بخشهای مهم برای بررسی است.
دلایل رایج کندی دیتابیس عبارتاند از:
- کوئری بدون Index مناسب
- خواندن تعداد زیادی ردیف بدون نیاز
- اجرای کوئری در Loop
- اتصال مجدد به دیتابیس برای هر درخواست
- استفاده از کوئری همزمان و منتظرماندن سرور
- ذخیره اطلاعات با فاصله زمانی بسیار کوتاه
- چند Resource با درخواستهای تکراری مشابه
- دیتابیس روی سروری با حافظه یا دیسک کند
از انتظار همزمان برای دیتابیس خودداری کنید
استفاده از dbPoll با مقدار منفی باعث میشود اجرای سرور تا آمادهشدن نتیجه منتظر بماند. این رفتار میتواند سرور را متوقف کند.
روش مناسبتر، استفاده از dbQuery بهصورت غیرهمزمان و پردازش نتیجه داخل Callback است.
ثبت جزئیات کوئریهای دیتابیس
برای عیبیابی موقت میتوان در کنسول سرور از دستور زیر استفاده کرد:
debugdb 2اطلاعات کوئریها معمولاً در فایل logs/db.log ذخیره میشوند. پس از بررسی، سطح Log را کاهش دهید تا فایل بیدلیل بزرگ نشود.
پینگ، Packet Loss و نوسان شبکه
گاهی مصرف CPU و RAM طبیعی است، اما بازیکنان همچنان پرش و تأخیر دارند. در این حالت باید شبکه بررسی شود.
- پینگ میان کاربران و دیتاسنتر
- نوسان پینگ یا Jitter
- Packet Loss
- محدودیت سرعت پورت سرور
- تمامشدن ترافیک ماهانه
- حمله یا ترافیک غیرعادی
- ازدحام شبکه دیتاسنتر
- مشکل مسیر ارتباطی یک اپراتور خاص
اگر فقط کاربران یک اینترنت یا شهر خاص مشکل دارند، ممکن است مسیر ارتباطی آن اپراتور دچار اختلال باشد. اگر همه کاربران همزمان مشکل دارند، شبکه سرور یا دیتاسنتر باید دقیقتر بررسی شود.
بررسی بازبودن پورتهای سرور
برای بررسی پورتهای اصلی MTA میتوان در کنسول خود سرور دستور زیر را اجرا کرد:
openportsپورتهای پیشفرض رایج MTA عبارتاند از:
| کاربرد | پورت پیشفرض | پروتکل |
|---|---|---|
| اتصال اصلی بازی | 22003 | UDP |
| HTTP و دانلود منابع | 22005 | TCP |
| نمایش در Server Browser یا ASE | 22126 | UDP |
اگر پورتها در mtaserver.conf تغییر کردهاند، قوانین فایروال و پنل دیتاسنتر نیز باید بر همان اساس تنظیم شوند.
تأثیر دانلود Resourceها بر ورود بازیکنان
حجم زیاد فایلهای کلاینت میتواند باعث کندشدن ورود بازیکنان شود، اما این حالت الزاماً لگ پردازشی سرور نیست.
- تصاویر حجیم را فشرده کنید.
- فایلهای صوتی غیرضروری را حذف کنید.
- Resourceهای استفادهنشده را پاک کنید.
- نسخههای تکراری فایلها را بررسی کنید.
- کش منابع را پس از تغییر صحیح مدیریت کنید.
- برای پروژههای بزرگ، وبسرور خارجی را بررسی کنید.
MTA امکان تعیین آدرس دانلود خارجی با گزینه httpdownloadurl را دارد. استفاده صحیح از وبسرور خارجی میتواند بار دانلود فایلها را از سرور اصلی جدا کند.
تنظیم bandwidth_reduction
در فایل mtaserver.conf گزینه bandwidth_reduction برای کاهش مصرف پهنای باند وجود دارد و مقادیر آن شامل none، medium و maximum است.
مقدار maximum نباید بدون آزمایش استفاده شود؛ زیرا ممکن است در برخی شرایط روی همگامسازی حرکت اثر منفی بگذارد. تغییر تنظیمات شبکه باید روی نسخه تست و با حضور چند کاربر بررسی شود.
<bandwidth_reduction>medium</bandwidth_reduction>تغییر این گزینه جایگزین اصلاح اسکریپتهای پرمصرف یا حل مشکل شبکه دیتاسنتر نیست.
آیا افزایش FPS سرور لگ را برطرف میکند؟
افزایش محدودیت FPS بدون بررسی پردازنده ممکن است مصرف منابع را بیشتر کند. همچنین مقدار fpslimit مربوط به محدودیت فریم کلاینتها است و نباید آن را بهعنوان درمان عمومی لگ تغییر داد.
گزینه server_logic_fps_limit نیز تنظیمی تخصصی است و در مستندات MTA تأکید شده فقط در صورت آگاهی کامل تغییر داده شود.
برای رفع لگ ابتدا باید اسکریپتها، Threadهای سرور، دیتابیس و شبکه بررسی شوند؛ سپس تنظیمات تخصصی تغییر کنند.
تأثیر VPS ضعیف یا شلوغ
اگر پس از بررسی کدها و شبکه همچنان Logic Thread یا سایر بخشها به محدودیت میرسند، ممکن است پردازنده VPS قدرت کافی نداشته باشد.
در VPSهای اشتراکی ممکن است توان پردازنده در ساعات شلوغی کاهش پیدا کند. نشانههای این وضعیت عبارتاند از:
- تغییر عملکرد سرور در ساعات مختلف
- بالارفتن Load بدون تغییر تعداد بازیکنان
- کندشدن ناگهانی همه سرویسهای VPS
- نوسان شدید قدرت CPU
- بهبود موقت پس از انتقال به Node دیگر
برای انتخاب منابع مناسب، مقاله VPS مناسب سرور MTA چه مشخصاتی باید داشته باشد؟ را مطالعه کنید.
آیا افزایش RAM لگ را برطرف میکند؟
فقط زمانی که مشکل از کمبود حافظه باشد. اگر رم آزاد وجود دارد و Swap استفاده نمیشود، افزایش RAM احتمالاً تأثیر مستقیمی روی اسکریپت سنگین یا پردازنده ضعیف ندارد.
در Performance Browser بخش Lua memory را بررسی کنید. افزایش مداوم حافظه یک Resource ممکن است نشانه موارد زیر باشد:
- جدولهایی که پاک نمیشوند
- Elementهای باقیمانده
- تایمرهای حذفنشده
- Callbackهای پرتعداد
- XMLهای بازمانده
- ذخیره اطلاعات غیرضروری برای مدت طولانی
چگونه بفهمیم لگ از کلاینت است یا سرور؟
| نشانه | احتمال بیشتر |
|---|---|
| فقط یک بازیکن مشکل دارد | سیستم، اینترنت یا فایلهای همان کاربر |
| کاربران یک اپراتور مشکل دارند | مسیر شبکه یا اپراتور |
| همه کاربران هنگام یک عملیات لگ دارند | Resource، دیتابیس یا منطق سرور |
| فقط هنگام نمایش HUD یا پنل FPS کم میشود | کد کلاینت و رسم گرافیکی |
| با افزایش بازیکنان اجرای دستورات کند میشود | پردازنده، اسکریپت یا دیتابیس |
| پینگ بالا میرود اما CPU طبیعی است | شبکه یا ارسال زیاد بستهها |
ترتیب عملی عیبیابی لگ سرور MTA
- زمان و شرایط ایجاد لگ را ثبت کنید.
- مصرف CPU، RAM، دیسک و شبکه VPS را بررسی کنید.
- در Performance Browser بخش Server info را مشاهده کنید.
- Logic، Sync، RakNet و DB Thread را مقایسه کنید.
- در Lua timings Resourceهای پرمصرف را پیدا کنید.
- بخش Event Packet usage را بررسی کنید.
- مصرف Lua memory را در چند بازه زمانی مقایسه کنید.
- خطاهای debugscript و فایلهای Log را بررسی کنید.
- کوئریهای دیتابیس را با debugdb تحلیل کنید.
- Resource مشکوک را روی نسخه تست متوقف کنید.
- شبکه، Packet Loss و پورتها را بررسی کنید.
- پس از اصلاح نرمافزار، نیاز به ارتقای VPS را ارزیابی کنید.
اشتباهات رایج هنگام رفع لگ
- ارتقای VPS بدون بررسی اسکریپتها
- ریاستارت روزانه سرور بهجای رفع نشت حافظه
- حذف تصادفی Resourceها بدون نسخه پشتیبان
- تغییر همزمان چند تنظیم شبکه
- استفاده از تنظیمات maximum بدون آزمایش
- نادیدهگرفتن لگ سمت کلاینت
- بررسی مصرف کلی CPU بهجای Threadهای جداگانه
- استفاده از کوئریهای همزمان دیتابیس
- ارسال همه رویدادها به تمام بازیکنان
- ثبت Log سطح بالا برای مدت طولانی
چکلیست کاهش لگ سرور MTA
- Resourceهای پرمصرف با Performance Browser شناسایی شدهاند.
- توابع سنگین داخل Lua timings بررسی شدهاند.
- تایمرها و Loopهای غیرضروری کاهش یافتهاند.
- کدهای onClientRender بهینه شدهاند.
- استفاده غیرضروری از setElementData حذف شده است.
- رویدادها فقط برای کاربران لازم ارسال میشوند.
- کوئریهای دیتابیس غیرهمزمان هستند.
- Indexهای دیتابیس بررسی شدهاند.
- خطاهای تکراری اسکریپت رفع شدهاند.
- پینگ، Packet Loss و مسیر شبکه آزمایش شدهاند.
- فضای دیسک و حجم Logها کنترل شدهاند.
- منابع VPS متناسب با مصرف واقعی انتخاب شدهاند.
چه زمانی باید از پشتیبانی فنی کمک گرفت؟
اگر سرور فعال است و تغییر Resourceها میتواند باعث آسیب به اطلاعات کاربران شود، بهتر است قبل از آزمایش از پروژه نسخه پشتیبان تهیه شود.
در شرایط زیر بررسی تخصصی مفید است:
- Logic Thread دائماً به مصرف بالا میرسد.
- عامل مصرف در Performance Browser مشخص نیست.
- دیتابیس هنگام حضور کاربران کند میشود.
- مصرف حافظه بهمرور افزایش پیدا میکند.
- سرور فقط در ساعات خاص دچار لگ میشود.
- پس از انتقال VPS مشکل ادامه دارد.
- چند Resource روی عملکرد یکدیگر اثر میگذارند.
- نیاز به بهینهسازی گیممود و زیرساخت وجود دارد.
برای بررسی فنی پروژه میتوانید صفحه پشتیبانی فنی گیمسرور یا خدمات راهاندازی و کانفیگ سرور MTA را مشاهده کنید.
جمعبندی
رفع لگ سرور MTA باید بر اساس اندازهگیری انجام شود، نه حدس. ابتدا مشخص کنید مشکل از Logic Thread، شبکه، دیتابیس، حافظه یا کدهای کلاینت است.
Performance Browser، Lua timings، Event Packet usage، Lua memory، debugscript و debugdb ابزارهای مهمی برای پیداکردن عامل اختلال هستند.
در بسیاری از پروژهها، اصلاح یک Resource سنگین، کاهش همگامسازی غیرضروری یا اجرای صحیح کوئریهای دیتابیس تأثیر بیشتری از افزایش رم سرور دارد.
برای نصب اصولی زیرساخت نیز راهنمای آموزش ساخت سرور MTA روی VPS لینوکس را مطالعه کنید.
پرسشهای متداول
چرا سرور MTA با CPU پایین لگ دارد؟
مصرف کلی CPU ممکن است میان چند هسته محاسبه شده باشد، درحالیکه یک Thread اصلی مانند Logic Thread به محدودیت یک هسته رسیده است. مصرف Threadها را جداگانه بررسی کنید.
آیا افزایش رم باعث رفع لگ میشود؟
فقط زمانی که سرور کمبود حافظه دارد. افزایش رم نمیتواند اسکریپت سنگین، کوئری کند یا مشکل شبکه را برطرف کند.
چطور Resource سنگین را پیدا کنیم؟
در Performance Browser وارد بخش Lua timings شوید و مصرف Resourceها را بررسی کنید. با گزینه d میتوان جزئیات توابع و خطوط پرمصرف را مشاهده کرد.
آیا setElementData باعث لگ میشود؟
استفاده محدود و صحیح مشکلی ایجاد نمیکند، اما تغییر پرتعداد اطلاعات همگامشونده میتواند مصرف شبکه و پردازنده را بالا ببرد. برای دادههای داخلی از جدول و برای ارسال هدفمند از Event استفاده کنید.
چرا بازیکنان پینگ مناسب دارند اما سرور کند است؟
پینگ مناسب فقط وضعیت رفتوبرگشت شبکه را نشان میدهد. ممکن است Logic Thread، دیتابیس یا یکی از Resourceها با مصرف بالا باعث تأخیر در اجرای دستورات شده باشد.
چرا فقط بعضی بازیکنان لگ دارند؟
ممکن است مشکل از اینترنت، مسیر شبکه، سختافزار کاربر یا کدهای کلاینت باشد. باید FPS، پینگ، Packet Loss و Resourceهای فعال برای همان کاربران بررسی شوند.