این نوشته پس از تجربیات تیم رستک در پروژه‌ی راه‌اندازی سامانه‌ی خود ارزیابی کرونا که در مقاله‌ی «رستک و کرونا! اسفند بیمار و چالش‌ها» به تفصیل آن تجربه پرداختیم منتشر شده است. در این نوشته قصد داریم تجربه خودمان را در بهبود کارایی استفاده از Apache Solr در بازه‌ای کوتاه، که به دلیل افزایش ناگهانی کاربران ماژول پرسشنامه‌های رستِک اتفاق افتاد، با شما به اشتراک بگذاریم. لازم به ذکر است که تا قبل از این رخداد، به دلیل تمرکز تیم بر رفع پیچیدگی‌های کاربردی سامانه و همچنین محدود بودن کاربران توجه به کارایی تنها محدود به استفاده از مدل و ابزار مناسب برای ثبت داده و تحلیل داده بود و نیاز چندانی برای بهینه کردن جزئیات استفاده از این ابزارها احساس نشده بود.

ماژول پرسشنامه‌ها چگونه اسناد را ذخیره می‌کند؟

اگر بخواهیم به صورت مختصر بیان کنیم که این ماژول چگونه داده‌ها را ذخیره و تحلیل می‌کند باید بگویم که برای این کار از یک پایگاه داده postgres و چندین هسته Apache Solr استفاده می‌شود که هر یک هدف مربوط به خود را دارد. پایگاه داده postgres وظیفه نگهداری پایدار از پرسشنامه‌ها و پاسخ‌ها را به عهده دارد و از طرفی تمام نسخه‌های پاسخ را نیز نگهداری می کند. در کنار آن پس از ارزیابی و ثبت هر پاسخ، اسنادی مناسب فرایند تحلیل در Solr ذخیره می‌شود تا در ادامه برای استخراج تحلیل‌ها از آن استفاده شود.

مزایا و معایب استفاده از Solr در اینجا Solr مزایای زیر را برای ما به ارمغان می‌آورد:

  • مستقل از پایگاه داده اصلی است و با توجه به این که میزان درخواست‌ها برای تحلیل و گزارش بسیار بیشتر از درخواست‌های ورود دادهی جدید است می‌تواند آن را با سرعت بیشتر پاسخ دهد.
  • با توجه به این که SolR بسیاری از ویژگی‌های «پایگاه داده رابطه‌ای» را ندارد ( برای مثال از transaction پشتیبانی نمی‌کند)‌ در فرایند ورود و واکشی در حجم درخواست بالا، کارایی بالایی دارد.
  • با پشتیبانی از اندیس‌گذاری بر روی فیلد های آرایه‌ای، سرعت پاسخگویی بالایی برای درخواست‌های جستجو بر روی فیلدها ارائه می‌دهد.

با وجود مزایای بالا معایب زیر نیز در استفاده از Solr وجود دارد

  • کندی نسبی ارتباط با Solr به دلیل استفاده از http در مقایسه با پایگاه داده postgres
  • نیاز به ذخیره‌سازی داده‌ها در دو مکان و لزوم نگهداری و به روز بودن داده‌ها.

همانطور که گفته شد هدف اصلی استفاده از Solr پاسخگویی به درخواست‌های زیاد دریافت تحلیل داده‌ها بوده است. اما در شرایط و کاربرد خاصی رفتار کاربران تغییر کرد و به یکباره ده‌ها پاسخ در ثانیه به سمت این ماژول سرازیر شدند که عملاً باعث شد بخش زیادی از پاسخ‌ها برای ذخیره شدن دهها ثانیه زمان نیاز داشته باشند.

در ادامه با شبیه‌سازی رفتار این کاربران بر روی سرور آزمایشی توانستم مشکلات زیر را که باعث کندی در ثبت پاسخ‌ها بود کشف کنیم که خوشحال می‌شویم آن‌ها را با شما به اشتراک بگذاریم.

شبیه‌سازی رفتار کاربران و کشف علت کندی پردازش درخواست‌ها!

برای شبیه‌سازی این رفتار تستی طراحی شد که در این تست ۴۰ کاربر همزمان به صورت پیوسته هر یک ۱۶ پاسخ را به یک پرسشنامه ارسال می کنند. از طرفی ارتباط با postgres با استفاده از Hibernate و ارتباط با Solr با استفاده از کتابخانه رسمی SolrJ انجام شده است.

پیش از هر گونه بهینه‌سازی، این تست در مجموع بر روی ماشین نمونه در زمان 106.99 ثانیه به پایان می‌رسید.

در مرحله اول بهینه‌سازی، به این نتیجه رسیدیم که به دلیل این که در هنگام اجرای آزمون‌ها نیاز داشتیم که داده بلافاصله بعد از ارسال پاسخ‌ها قابل تحلیل باشند، پس از ارسال اسناد به Solr در هر درخواست با ارسال دستور commit منتظر اعمال تغییرات می‌شدیم که در ادامه متوجه شدیم که این عمل در تکرار زیاد بسیار کند است. از طرفی Solr به صورت خودکار، هر چند ثانیه اسناد را در پس زمینه commit می‌کند و نیاز به این کار وجود ندارد. گرچه می‌توان در هنگام commit کردن با استفاده از ویژگی soft commit سرعت را تا حدی بهبود بخشید. پس از حذف عملیات commit در انتهای ثبت هر پاسخ، مدت زمان اجرای این تست به 41.47 کاهش پیدا کرد. با این حال، در مقایسه با حالتی که به صورت کامل قید ذخیره سازی اسناد در Solr را بزنیم ( که حدود 16.03 ثانیه طول می کشد) هنوز کند است. برای بهبود این وضعیت با بررسی بیشتر به این نتیجه رسیدیم که، این که اسناد را در یک درخواست و یا چندین درخواست مختلف به Solr بفرستیم نیز تاثیر زیادی در سرعت کلی دارد و با در نظر گرفت این موضوع به جای این که اسناد را جداگانه به Solr بفرستیم تعداد زیادی از آنها – مثلا ۶۰۰ سند – را در یک درخواست به Solr فرستادیم که با این تغییر مدت زمان اجرای این آزمون به 21.4 ثانیه کاهش پیدا کرد که در مقایسه با وقتی که اسناد تنها در پایگاه داده postgres ذخیره می‌شوند، رضایت بخش به نظر می‌رسد. با این حال نگه داشتن تعداد زیادی سند و عدم ارسال آنها به Solr در نسخه نهایی سامانه چالش‌هایی را دارد. از طرفی در حجم زیاد درخواست این کار نقشی حیاتی را در افزایش سرعت پاسخگویی ایفا می‌کند اما از طرف دیگر در زمانی که پاسخ‌های کمی در حال ارسال شدن هستند عملا پاسخ‌ها مدت زیادی را در انتظار می‌مانند تا در Solr وارد شده و قابل تحلیل باشند. به همین دلیل تصمیم گرفتیم به جای این که منتظر بمانیم تا اسناد به میزان خاصی جمع شوند عملیات ارسال اسناد به Solr را در بازه‌های زمانی مشخص ۱۰ ثانیه‌ای انجام دهیم. این کار باعث می‌شود که در هنگامی که حجم درخواست‌ها زیاد است در طول مدت ۱۰ ثانیه تعداد زیادی درخواست آماده ارسال شوند و از طرفی در زمان خلوتی نیز پاسخ‌ها حداکثر ۱۰ ثانیه پس از ارسال قابل تحلیل باشند.

مقایسه زمان درگیر در ارسال داده ها به Solr در مراحل بهبود سرعت ارسال اسناد

در اینجا لازم به ذکر است که هدف این نوشته بررسی دقیق کارایی ارتباط با Solr در وضعیت‌های مختلف نبوده و به همین دلیل از بیان جزئیات آزمایش و همچنین روش علمی این کار که نیازمند ایزوله کردن و انجام مکرر آزمایش است خودداری شده و صرفا تاثیر دو پارامتر مختلف در ارسال داده‌ها به Solr را نشان دهیم. پارامتر اول، commit پس از ارسال بود که البته با توجه به مستندات Solr مشاهده بهبود در آن، مورد انتظار بود. اما پارامتر دوم، یعنی تاثیر ارسال دسته جمعی پاسخ‌ها برای ما بسیار غیر منتظره بود، زیرا در مرحله اول و با بررسی اسناد Solr این موضوع مطرح شده بود که کتابخانه SolrJ خود با استفاده از Connection Pooling فرایند ارسال و واکشی داده را به خوبی انجام می‌دهد؛ اما این آزمایش نشان داد که سربارهای موجود در فرایند اضافه کردن اسناد در هر درخواست فراتر از ایجاد اتصال جدید است.

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *