اینتل و ردیس پیشرفتهای قابل توجهی را انجام داده اند. در اینجا ما تکنیک های بهینه سازی را برای ارزیابی و به حداکثر رساندن عملکرد فرمان Redis Geo ، مانند کاهش محاسبات زباله و ساده کردن الگوریتم ها به اشتراک می گذاریم.
تمام کارها پرداخت شده است. در مجموع ، ما عملکرد Redis را تا چهار برابر سرعت قبلی بهبود بخشیدیم.
دستورات GEO Redis (به طور رسمی شاخص های جغرافیایی ) ابزاری قدرتمند برای کار با داده های جغرافیایی است. Redis می تواند مختصات جغرافیایی یک شی را مانند مکان های فروشگاه یا کامیون های تحویل در حال حرکت ذخیره کند. سپس Redis می تواند عملیات ریاضی و مبتنی بر هماهنگی را بر روی آن داده ها انجام دهد ، مانند تعیین فاصله بین دو نقطه (ماشین تحویل با سفارش ناهار من چقدر فاصله دارد؟) یا یافتن تمام نقاط ثبت شده در یک شعاع معین از یک نقطه دیگر (نزدیکترین فروشگاه حیوان خانگی به مکان فعلی من کجاست؟).
در نهایت ، آن طول و عرض جغرافیایی فقط داده هایی برای دسترسی و به روزرسانی برنامه های شما هستند. و مانند هر پایگاه داده ای که بخشی از منطق بحرانی تجارت شما باشد ، شما می خواهید بهترین عملکرد ممکن-به ویژه هنگامی که سیستم های دسترسی به داده ها از نظر جسمی در حال حرکت هستند (آن کامیون تحویل) در حال حرکت هستند و بنابراین به پاسخ های زمان واقعی نیاز دارند. برای تحقق این امر ، بهینه سازی نمایش داده ها و الگوریتم هایی که برای تعامل با داده های GEO استفاده می کنید مهم است.
برای به حداکثر رساندن عملکرد اجرای دستورات Redis Geo ، ما به تجزیه و تحلیل عملکرد و تکنیک های توصیف بار کار رسیدیم. اهداف شناسایی تنگناها ، بهینه سازی استفاده از منابع و بهبود عملکرد کلی بود.
در این پست ، ما آن تکنیک های بهینه سازی ، مانند کاهش محاسبات زباله و ساده سازی الگوریتم ها و همچنین نتایج تجزیه و تحلیل ما را به اشتراک می گذاریم. The Takeaway: ما می توانیم چهار برابر توان خود را در نمایش داده های Geosearch برسیم ، و این پیشرفت قبلاً به عنوان بخشی از ردیس ۷ ۷
تجزیه و تحلیل عملکرد و مورد استفاده جغرافیایی
تجزیه و تحلیل عملکرد و توصیف بار کار تکنیک های مهمی برای درک ویژگی های عملکرد برنامه ها است. این تکنیک ها شامل جمع آوری و تجزیه و تحلیل داده ها در مورد رفتار برنامه و استفاده از منابع آن برای شناسایی تنگناها ، بهینه سازی استفاده از منابع و بهبود عملکرد کلی است.
هر برنامه ای که سعی در سرعت بخشیدن به آن داریم ، از روشهای قطعی ، مختصر و روشمند برای نظارت و تجزیه و تحلیل عملکرد استفاده می کنیم. برای انجام این کار ، شما می توانید هر یک از تعدادی از روش های عملکردی را مناسب تر از دیگران ، بسته به کلاس و تجزیه و تحلیل شما می خواهید
.
به طور گسترده ، وقتی می خواهید کارآیی یک برنامه را بهبود بخشید ، این لیست چک عمومی در بیشتر شرایط اعمال می شود:
- اهداف عملکرد را تعیین کنید: قبل از شروع ، شما نیاز به درک روشنی از آنچه می خواهید به دست آورید. اهداف ممکن است شامل بهبود زمان پاسخ ، کاهش استفاده از منابع یا افزایش توان باشد. در این حالت ، ما می خواهیم هر دو زمان پاسخ هر یک از عملکردهای فردی را بهبود بخشیم و در نتیجه ، توان قابل دستیابی را افزایش دهیم.
- بار کار را مشخص کنید: در مرحله بعد ، بار کاری را که تجزیه و تحلیل خواهید کرد تعیین کنید. این ممکن است شامل شناسایی وظایف یا اقدامات خاص که برنامه انجام خواهد داد و همچنین الگوهای بار و استفاده مورد انتظار است. برای مورد استفاده از دستورات GEO ، ما از یک مجموعه داده با ۶۰ میلیون نقطه داده مبتنی بر OpenStreetMap (Planetosm) querist queristance queristance استفاده کردیم.
- جمع آوری داده ها: پس از شناسایی بار کار ، داده های مربوط به عملکرد برنامه و استفاده از منابع آن را برای هر مورد استفاده جمع آوری کنید. ممکن است از پروفایل ، اشکال زدایی یا ابزارهای تجزیه و تحلیل عملکرد استفاده کنید. اطلاعات مربوط به استفاده از حافظه برنامه ، استفاده از CPU و سایر معیارها را جمع آوری کنید. پروفایل استفاده از CPU با نمونه گیری از آثار پشته در یک بازه به موقع ، روشی سریع و آسان برای شناسایی بخش های کد عملکردی با عملکرد (که به آن نقاط داغ نیز گفته می شود) است. یافته های ما دقیقاً بر اساس استفاده از لینوکس ابزار PERF برای آن هدف است. ما مستندات در مورد شناسایی رگرسیون عملکرد و پیشرفت های بالقوه در CPU شامل لیست کاملی از ابزارها و روشهای دیداری عمیق تر است.
- داده ها را تجزیه و تحلیل کنید: پس از جمع آوری داده ها ، می توانید از تکنیک های مختلفی برای تجزیه و تحلیل آن و شناسایی مناطقی از برنامه استفاده کنید که ممکن است بر عملکرد تأثیر بگذارد. برخی از این تکنیک ها در حال تجزیه و تحلیل عملکرد با گذشت زمان ، مقایسه بار کاری مختلف و به دنبال الگوهای موجود در داده ها هستند. ما می توانیم با تجزیه و تحلیل اطلاعات پروفایل ضبط شده با استفاده از گزارش پروفایل ، وقتی که شما گزارش می دهید ، بهبود در مورد موارد استفاده مرتبط هرچه تجربه بیشتری با کد برنامه داشته باشید ، بهینه سازی آن آسان تر است.
- برنامه را بهینه کنید: بر اساس تجزیه و تحلیل شما ، می توانید مناطقی از برنامه را شناسایی کنید که ممکن است باعث ایجاد مشکلات عملکرد شود. سپس برای بهینه سازی کد ، مانند تغییر به یک الگوریتم کارآمدتر ، کاهش میزان حافظه مورد استفاده یا انجام سایر تنظیمات کد ، مراحلی بردارید. در سناریوهایی که در مرحله بعدی به نمایش می گذاریم ، ما روی کارآیی الگوریتم ها تمرکز می کنیم و میزان محاسبات تکراری را کاهش می دهیم.
- فرآیند را تکرار کنید: تجزیه و تحلیل عملکرد و توصیف بار کار فرآیندهای در حال انجام است ، بنابراین مهم است که به طور منظم عملکرد برنامه را مرور و تجزیه و تحلیل کنید. این به شما امکان می دهد تا تنگناها یا مواردی را که ممکن است در به روزرسانی ها یا شرایط استفاده ایجاد شود ، شناسایی و پرداختن کنید.
زمینه در محاسبه فاصله از شاخص های Geospatial Redis
اگر نمی دانید چه کاری انجام می دهد ، نمی توانید نرم افزار را سریعتر اجرا کنید. در این حالت ، این به معنای معرفی کوتاهی از روند کار با داده های جغرافیایی است.
بیشتر دستورات برای پرس و جو شاخص های جغرافیایی redis فاصله بین دو هماهنگی را محاسبه می کند ، بنابراین این حس را بررسی می کند که چگونه آن را به صورت آلگوریتمی انجام داده است. فاصله haversine یک اقدام مفید است ، زیرا در نظر گرفته می شود که با انحراف زمین ، با نتایج دقیق تر از نتایج فاصله اقلیدسی محاسبه.
برای محاسبه فاصله Haversine در یک کره (مانند زمین) ، به عرض جغرافیایی و طول دو نقطه و همچنین شعاع کره نیاز دارید. فرمول Haversine فاصله بین نقاط را در یک خط مستقیم محاسبه می کند ، به دنبال کوتاهترین مسیر در سطح کره.
این محاسبات برای محاسبه فاصله Harvesive به عملکردهای مثلثاتی متکی هستند و فراخوانی توابع مثلثاتی از نظر چرخه CPU گران است. In a bottleneck analysis of a simple GEOSEARCH command, around 55% of the CPU cycles are spent within those functions, as shown in Figure 1. That means it’s worth the time to optimize those code blocks, or as amhdal می گوید: “بهبود عملکرد کلی به دست آمده با بهینه سازی یک قسمت واحد از یک سیستم محدود به کسری از زمان است که در واقع قسمت بهبود یافته استفاده می شود.”
بنابراین ، بیایید روی بزرگترین بهینه سازی ممکن تمرکز کنیم.
شکل ۱: اطلاعات پروفایل اولیه برای یک دستور geosearch ساده ، نشان دادن ۵۵ ٪ از چرخه های CPU که در توابع مثلثاتی انجام می شود.
اولین دور بهینه سازی: محاسبه زباله را کاهش دهید
همانطور که داده های پروفایل بالا نشان می دهد ، ۵۴.۷۸ ٪ از چرخه های CPU توسط GeohashgetDistanceifinRectangle تولید می شوند. در درون آن ، ما سه بار GeohashgetDistance را صدا می کنیم. دو بار اول ، ما روال را برای تولید نتایج متوسط (مانند بررسی اینکه آیا یک نقطه از طول جغرافیایی یا عرض جغرافیایی خارج است) می نامیم. در صورت عدم وجود شرایط ، این امر از محاسبات فاصله گسترده CPU جلوگیری می کند. منطقی است که بررسی کنید که داده ها در محدوده هستند ، اما ما نیازی به انجام این کار به طور مکرر نداریم.
اولین بهینه سازی ما برای کاهش محاسبات زباله نتایج واسطه ای در دو مرحله (و به تفصیل در pr #11535 ):
- محاسبات گران قیمت را در محاسبات GeohashgetDistance متوسط کاهش دهید.
- در صورت عدم موفقیت شرایط فاصله عرض جغرافیایی ، از محاسبه فاصله طول جغرافیایی خودداری کنید.
که بهینه سازی تفاوت معنی داری ایجاد کرد. برای این پرس و جو Geosearch ، با استفاده از یک مشتری معیار واحد و بدون خط لوله ، ما میانگین تأخیر (از جمله زمان سفر دور) را از ۹۳.۵۹۸ms به ۷۳.۰۴۶ms کاهش دادیم ، که نمایانگر افت تاخیر تقریبا ۲۲ ٪ است.
دور دوم: محاسبات زباله
همان تجزیه و تحلیل عملکرد نمایش داده شدگان Geosearch همچنین نشان داد که در برخی موارد ، Redis تماس های فریبنده ای را به SDSDUP و SDSFREE انجام می دهد. این دستورات به ترتیب حافظه رشته ها را اختصاص می دهند و به هم اختصاص می دهند. این با مجموعه داده های بزرگ ، جایی که بسیاری از عناصر خارج از محدوده جستجو هستند اتفاق می افتد.
شکل ۲: در این فرآیند ، بیش از ۲۸ ٪ از توجه CPU برای دستور SDSDUP صرف شده است. هر کاری که می توانیم برای کاهش این معامله انجام دهیم ، نتایج جستجوی جغرافیایی را افزایش می دهد.
بهبود عملکرد ما در pr 11522 ساده بود: به جای پیش از پیوند دادن رشته های رشته ای ، ما فقط می توانیم نقش geoappendifwithinshifwithinshipwwithinshiphwithinshiphwithinshiphwithinshiphwithinshiphwithinshiphwwithinshiphwwithinshope را تغییر دهیم. این منجر به افت تاخیر تقریباً ۱۴ ٪ و ۲۵ ٪ بهبود در OPS/Sec قابل دستیابی
دور سوم: ساده سازی الگوریتم ها
برای بهینه سازی پرس و جو شاخص جغرافیایی ، ما روی اطلاعات الگوی داده متمرکز شدیم. هدف این است که تعداد محاسبات مورد نیاز برای فاصله Haversine را ساده کنیم. این صرفاً یک تمرین ریاضی است.
وقتی اختلاف طول جغرافیایی ۰ است:
- با توجه به اختلاف طول جغرافیایی صفر ، ASIN (SQRT (A)) روی Haversine Asin (Sin (ABS (U))) است.
- arcsin (sin (x)) را برابر با x تنظیم کنید وقتی x ∈ [−𝜋/۲ ، 𝜋/۲].
- با توجه به عرض جغرافیایی بین [−𝜋/۲ ، 𝜋/۲] ما می توانیم Arcsin (sin (x)) را به ABS (x) ساده کنیم.
pr #11579 بهینه سازی را توصیف می کند و بهبود عملکرد این ساده سازی را به دست می آورد. خط پایین: منجر به افزایش ۵۵ ٪ در عملیات قابل دستیابی در هر ثانیه از دستور redis geosearch شد.
دور چهارم: شماره نمایندگی
همه مواردی را که به شدت به تبدیل یک دو برابر به یک نمایش رشته متکی هستند (مانند تبدیل یک شماره نقطه شناور دوتایی (۱.۵) به یک رشته (“۱.۵”) می توانند با جایگزینی فراخوان به Snprintf (buf ، len ، ۴f “، ارزش) با یک نقطه ثابت دو برابر نسخه بهینه سازی نسخه بهینه
می توانند سود ببرند.
دستور ژئودیستی ، که در شکل ۳ نشان داده شده است ، مثال خوبی است. حدود یک چهارم از زمان CPU به تبدیل نوع اختصاص داده شده است.
>
شکل ۳: اطلاعات پروفایل برای دستور ژئودیست ، با نمایش ۲۶ ٪ از چرخه های CPU که صرف تبدیل یک دو برابر به یک نمایش رشته می شود.
pr 11552 به تفصیل بهینه سازی را که پیشنهاد کردیم ، توصیف می کند ، که منجر به افزایش ۳۵ ٪ در عملیات قابل دستیابی در هر ثانیه از نظر ژئودیستی می شود.
قرار دادن همه آن در redis 7.0
دلیل اصلی محبوبیت Redis به عنوان یک پایگاه داده ، عملکرد آن است. ما به طور کلی نمایش داده ها را در زمان پاسخ زیر میلیسوت ثانیه اندازه می گیریم-و می خواهیم آن را بهبود بخشیم.
تأثیر تجمعی بهینه سازی هایی که در این پست وبلاگ توضیح می دهیم: ما عملکرد دستورات redis geospatial را تا چهار برابر سرعت قبلی آنها افزایش دادیم. شما می توانید از این پیشرفت ها بهره مند شوید ، زیرا آنها بخشی از Redis 7.0.7 هستند. و این باید شما را به جایی که می روید ، سریعتر از آنچه که قبلاً انجام داد ، برساند.
<جدول کلاس = "LegacyTable">
فرمان
مورد آزمایش
OPS/SEC REDIS قابل دستیابی ۷.۰.۵
OPS/SEC REDIS قابل دستیابی ۷.۰.۷
فاکتور بهبود
کلید ژئودیستی…
GEO-60M-Elements-Geodist-Pipeline-10
۷۷۵۵۲۴
۹۹۳۶۳۲
۱.۳ x
Geosearch … Fromlonlat … Byradius
GEO-60M-Elements-Geosearch-fromlonlat
۱۱.۸
۱۳.۸
۱.۲ x
Geosearch… FromLonlat… bybox
Geo-60M-Elements-Geosearch-Fromlonlat-Bybox
۱۳.۲
۴۹.۶
۳.۸ x
فرمان
مورد آزمایش
OPS/SEC REDIS قابل دستیابی ۷.۰.۵
OPS/SEC REDIS قابل دستیابی ۷.۰.۷
فاکتور بهبود
کلید ژئودیستی…
GEO-60M-Elements-Geodist-Pipeline-10
۷۷۵۵۲۴
۹۹۳۶۳۲
۱.۳ x
Geosearch … Fromlonlat … Byradius
GEO-60M-Elements-Geosearch-fromlonlat
۱۱.۸
۱۳.۸
۱.۲ x
Geosearch… FromLonlat… bybox
Geo-60M-Elements-Geosearch-Fromlonlat-Bybox
۱۳.۲
۴۹.۶
۳.۸ x
پیشرفت های کلی GEO در توان قابل دستیابی بین Redis 7.0.5 و ۷.۰.۷ در سرور مبتنی بر پردازنده Intel Xeon Platinum 8360Y.
<جدول کلاس = "LegacyTable">
فرمان
مورد آزمایش
تأخیر کلی P50 شامل RTT (MS) Redis 7.0.5
تأخیر کلی P50 شامل RTT (MS) Redis 7.0.7
فاکتور بهبود
کلید ژئودیستی…
GEO-60M-Elements-Geodist-Pipeline-10
۲.۵۷۵
۲.۰۰۷
۱.۳ x
Geosearch … Fromlonlat … Byradius
GEO-60M-Elements-Geosearch-fromlonlat
۶۷۹.۹۳۵
۵۹۸.۰۹۷
۱.۱ x
Geosearch… FromLonlat… bybox
Geo-60M-Elements-Geosearch-Fromlonlat-Bybox
۶۰۵.۷۳۹
۱۶۱.۷۹۱
۳.۷ x
فرمان
مورد آزمایش
تأخیر کلی P50 شامل RTT (MS) Redis 7.0.5
تأخیر کلی P50 شامل RTT (MS) Redis 7.0.7
فاکتور بهبود
کلید ژئودیستی…
GEO-60M-Elements-Geodist-Pipeline-10
۲.۵۷۵
۲.۰۰۷
۱.۳ x
Geosearch … Fromlonlat … Byradius
GEO-60M-Elements-Geosearch-fromlonlat
۶۷۹.۹۳۵
۵۹۸.۰۹۷
۱.۱ x
Geosearch… FromLonlat… bybox
Geo-60M-Elements-Geosearch-Fromlonlat-Bybox
۶۰۵.۷۳۹
۱۶۱.۷۹۱
۳.۷ x
بهبود کلی GEO در تأخیر کلی P50 شامل RTT در هر دستور بین Redis 7.0.5 و ۷.۰.۷ Intel Xeon Platinum 8360y سرور مبتنی بر پردازنده.
توجه داشته باشید که این یک بهبود عملکرد منزوی نیست – کاملاً برعکس. این مجموعه از پیشرفت ها نمونه ای از زندگی واقعی از تأثیر تلاش های عملکردی است که ما آن را “مشخصات معیار Redis” می نامیم. ما دائماً در حال فشار بیشتر و عملکرد بهتر در کل API Redis هستیم.
در حال مسافت
آیا می خواهید در مورد محاسبات جغرافیایی اطلاعات بیشتری کسب کنید؟ وبلاگ های عملکرد دیگر این سری را بررسی کنید ، که بیشتر آنها با اینتل نوشته شده اند:
- ساخت سریع ، سریعتر! به طور متد بهبود عملکرد Redis ، توصیف می کنیم که چگونه عملکرد مصرف جریان را حدود ۲۰ ٪ بهبود بخشیدیم.
- تست عملکرد ، پروفایل و تجزیه و تحلیل ، توصیف عملکرد و اتوماسیون پروفایل “صفر” ما.
- گوریل در اتاق: کاوش در بهینه سازی عملکرد مجدد ، بررسی بهینه سازی های بالقوه برای بازگرداندن algormension
- بهینه سازی پرچم های سازنده پیش فرض Redis ، در مورد تغییر رفتار کامپایلر در Redis.
*اینتل ، آرم اینتل و سایر علائم اینتل علائم تجاری شرکت اینتل یا شرکتهای تابعه آن هستند.
پست های مرتبط
سرعت بخشیدن به دستورات جغرافیایی در Redis 7
سرعت بخشیدن به دستورات جغرافیایی در Redis 7
سرعت بخشیدن به دستورات جغرافیایی در Redis 7