من برای شناسایی مسئله اساسی الگوی تأخیر زیر برای حداکثر صدک برنامه خود کار سختی دارم: This is a gatling chart that shows 4 minutes of load testing. The first two minutes are warmup of the same scenario (thats why it has no latency graph). Two triangles (sometimes more) with a nearly identical slope are clearly visible and reproducible across multiple test runs, no matter how many application instances we deploy behind our load balancer: I am looking for more paths to investigate as I have a hard time googling for this patte - it strikes me as particularly odd that this triangle is not "filled" but just consists of spikes. Furthermore the triangle feels "inverted": if this would be a scenario with ever-increasing load (which it isn't) I would expect to see this kind of triangle manifest with an inverted slope - this slope just doesn't make any sense to me. Technical context:

• این برای یک برنامه بوت بهار با یک پایگاه داده PostgreSQL در AWS است
• 6 غلاف در خوشه Kubeetes ما مستقر شده است ، مقیاس خودکار برای این آزمایش غیرفعال شده است
• نگه داشتن Alive توسط آزمون گاتلینگ ما استفاده می شود (به پاسخ زیر مراجعه کنید ، معلوم است که این یک دروغ بود)
• پیکربندی ورود به Kubeetes به عنوان یک به عنوان باقی مانده است که دلالت بر نگه داشتن در هر بالادست اگر پیش فرض را به درستی بخوانم
• هر دو بانک اطلاعاتی و CPU در هر غلاف حداکثر نیستند
• پیوند شبکه دستگاه تست بار ما حداکثر نیست و دستگاه علاوه بر اجرای تست بار ، هیچ چیز دیگری انجام نمی دهد
• بار (درخواست ها / ثانیه) در برنامه تقریباً ثابت است و بعد از گرم شدن / در طول اندازه گیری تغییر نمی کند
• فعالیت جمع آوری زباله کم است

در اینجا یک تصویر دیگر برای نشان دادن "مثلث" قبل از اینکه برخی از بهینه سازی های سمت برنامه را برای درخواست تأخیر ایجاد کنیم:

دنبال کردن رووکی از 6 ژوئیه 2022 ساعت 6:00 پرسید رووکی رووکی 1،668 13 13 نشان نقره 24 24 نشان برنز

1 پاسخ 1

مرتب شده توسط: تنظیم مجدد به طور پیش فرض

این مسئله یک مسئله دو قسمتی بود:

• ما فکر کردیم که آزمایش بار ما از اتصال نگهدارنده استفاده می کند ، که این کار را نکرد (دستهای SSL گران قیمت است ، درگاه های زودگذر پس از مدتی تمام می شوند)
• یک سیستم برنامه ریزی وظیفه مبتنی بر اولویت سفارشی (یک درخواست قبلی و زیرمجموعه های آن از اولویت بالاتری نسبت به درخواست های بعدی) "گمشده" اولویت وظیفه خود به دلیل نحوه کار Coroutines Kotlin (موضوع A در طی یک کوروتین و دیگری کار باقیمانده را بعداً به حالت تعلیق در می آورد. از دست دادن هرگونه اولویت ThreadLocal - این می تواند از طریق AscontextElement () برطرف شود)

در حالی که این مسئله بیش از شکل عجیب الگوی تأخیر را توضیح نمی دهد که مسائل اصلی ما را برطرف کرده و الگوی از بین رفته است.

دنبال کردن 8 ژوئیه 2022 در 6:26 پاسخ داد رووکی رووکی 1،668 13 13 نشان نقره 24 24 نشان برنز

• بوته بهار
• kubeetes
• تست بار
• گودال
• تاخیر

• وبلاگ سرریز

مربوط

سوالات شبکه داغ

مشترک شدن در RSS

خوراک پرسش

برای عضویت در این فید RSS ، این URL را در RSS Reader خود کپی و چسباندن کنید.

طراحی سایت / آرم © 2023 Stack Exchange Inc ؛مشارکتهای کاربر دارای مجوز تحت CC BY-SA. Rev 2023. 5. 31. 43466

با کلیک بر روی "قبول همه کوکی ها" ، شما موافقت می کنید که Exchange می تواند کوکی ها را در دستگاه شما ذخیره کند و اطلاعات را مطابق با خط مشی کوکی ما فاش کند.