جنگولرن

✅بهینه سازی Query Performance : متد Only در ORM جنگو

از لینکدین آقای عموزاده

یکی از فعالیتهای روزمرهام برای محصولات این است که بخش Issues و Performance سرویس Sentry رو بررسی کنم و از لیست مشکلات Performance ای که Sentry تشخیص داده، موارد مهم رو پیدا و به تیم ارجاع بدم و گاهی اوقات هم خودم برم سروقت حل شون و یادگیری ام حفظ بشه. تو گزارش ها، endpoint و background task هایی داریم که Response time یا failure rate شون بیشتر از انتظاره و یا گاهی اوقات سرویس زیر بار کلاً از دست میره (504 میگیریم برای مثال). یکی از روش هایی که میشه برای حل این دست مشکلات استفاده کرد، محدود کردن انتخاب ستونها به اونایی که واقعاً نیاز هستند است. در ORM ها معمولاً ستونهای بیشتر به معنی مصرف منابع بیشتر است و میتونه Capacity و Response time سرویس/محصول را تحت تأثیر قرار بده. در Django یکی از ابزار هایی که برای بهبود Query ها استفاده میکنم متد only است. به این شکل که اول جایی که نتیجه قراره استفاده بشه (مثلاً Template، REST یا …) رو اول بررسی میکنم تا ببینم که چه تعداد از ستونها ضروری هستند و اونا رو به عنوان آرگومان به متد only میدم. بعد با کمک ابزار های مشاهده Query (مثل Debug toolbar یا مشابهش) نتیجه کار رو از نظر دیتابیس چک میکنم. نکته مهم این است که مطمئن باشیم همه ستونهای مورد نیاز رو به متد داده ایم، اگر متدی جای دیگه ای استفاده بشه،ORM مجبور میشه مجدد کوئری بزنه و از هدف اولیه دور میشیم. نکته بعدی اینکه در تجربه و کیس های کاری من، استفاده از این متد، بیشتر مواقع باعث تحول سرویس نشد،قدم مثبتی به جلو بود و خودش رو برای مثال در تهیه گزارش ها (جایی که تعداد زیادی iteration داشتیم) بیشتر نشون داد و اکثر مواقع تفاوت محسوسی نداشت (تفاوت رو با اندازهگیری زمان DB response time، مقدار مصرف حافظه و HTTP response time اندازهگیری کردم). تفاوت Query بدون و با استفاده از Only رو توی تصویر میتونین ببینید و امیدوارم یک ابزار مفید توی جعبه ابزارتون باشه. 🙂 لینک مستندات: https://lnkd.in/dhiwfcb4

تصاویر در نظرات پست

👏7👍3❤2

www.tgoop.com/djangolearn_ir/935

2.17K viewsNov 10, 2024 at 15:06

✅بهینه سازی Query Performance : متد Only در ORM جنگو

از لینکدین آقای عموزاده

یکی از فعالیتهای روزمرهام برای محصولات این است که بخش Issues و Performance سرویس Sentry رو بررسی کنم و از لیست مشکلات Performance ای که Sentry تشخیص داده، موارد مهم رو پیدا و به تیم ارجاع بدم و گاهی اوقات هم خودم برم سروقت حل شون و یادگیری ام حفظ بشه. تو گزارش ها، endpoint و background task هایی داریم که Response time یا failure rate شون بیشتر از انتظاره و یا گاهی اوقات سرویس زیر بار کلاً از دست میره (504 میگیریم برای مثال). یکی از روش هایی که میشه برای حل این دست مشکلات استفاده کرد، محدود کردن انتخاب ستونها به اونایی که واقعاً نیاز هستند است. در ORM ها معمولاً ستونهای بیشتر به معنی مصرف منابع بیشتر است و میتونه Capacity و Response time سرویس/محصول را تحت تأثیر قرار بده. در Django یکی از ابزار هایی که برای بهبود Query ها استفاده میکنم متد only است. به این شکل که اول جایی که نتیجه قراره استفاده بشه (مثلاً Template، REST یا …) رو اول بررسی میکنم تا ببینم که چه تعداد از ستونها ضروری هستند و اونا رو به عنوان آرگومان به متد only میدم. بعد با کمک ابزار های مشاهده Query (مثل Debug toolbar یا مشابهش) نتیجه کار رو از نظر دیتابیس چک میکنم. نکته مهم این است که مطمئن باشیم همه ستونهای مورد نیاز رو به متد داده ایم، اگر متدی جای دیگه ای استفاده بشه،ORM مجبور میشه مجدد کوئری بزنه و از هدف اولیه دور میشیم. نکته بعدی اینکه در تجربه و کیس های کاری من، استفاده از این متد، بیشتر مواقع باعث تحول سرویس نشد،قدم مثبتی به جلو بود و خودش رو برای مثال در تهیه گزارش ها (جایی که تعداد زیادی iteration داشتیم) بیشتر نشون داد و اکثر مواقع تفاوت محسوسی نداشت (تفاوت رو با اندازهگیری زمان DB response time، مقدار مصرف حافظه و HTTP response time اندازهگیری کردم). تفاوت Query بدون و با استفاده از Only رو توی تصویر میتونین ببینید و امیدوارم یک ابزار مفید توی جعبه ابزارتون باشه. 🙂 لینک مستندات: https://lnkd.in/dhiwfcb4

تصاویر در نظرات پست

BY جنگولرن