DJANGOLEARN_IR Telegram 935
بهینه سازی 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👍32



tgoop.com/djangolearn_ir/935
Create:
Last Update:

بهینه سازی 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 جنگولرن


Share with your friend now:
tgoop.com/djangolearn_ir/935

View MORE
Open in Telegram


Telegram News

Date: |

Choose quality over quantity. Remember that one high-quality post is better than five short publications of questionable value. Over 33,000 people sent out over 1,000 doxxing messages in the group. Although the administrators tried to delete all of the messages, the posting speed was far too much for them to keep up. Hui said the time period and nature of some offences “overlapped” and thus their prison terms could be served concurrently. The judge ordered Ng to be jailed for a total of six years and six months. Each account can create up to 10 public channels Joined by Telegram's representative in Brazil, Alan Campos, Perekopsky noted the platform was unable to cater to some of the TSE requests due to the company's operational setup. But Perekopsky added that these requests could be studied for future implementation.
from us


Telegram جنگولرن
FROM American