چرا برنامه‌های نوشته شده بسیار کند اجرا می‌شوند؟

به گزارش سرویس فناوری اطلاعات «خبرنامه دانشجویان ایران»؛  اگر یک برنامه‌نویس هستید و دوست ندارید برنامه‌ نوشته شده‌تان به‌واسطه کارایی پایین با شکست روبه‌رو شود، پیشنهاد می‌کنیم این مطلب را مطالعه کنید.

دلیل 1. شما یک ریسمان/رشته بزرگ دارید
در برخی از چارچوب‌های پیشرفته (مثل Node.js) قابلیت بندکشی (threading) برایتان انجام می‌شود. سعی‌تان بر این است که برای انجام کارهای خود فراخوانی‌های ورودی/خروجی (I/O) غیر بلوکی درست را در زمان درست به انجام برسانید و خط اصلی برنامه خود را از انجام بیش ‌از اندازه بارهای سنگین مصون نگه دارید. به نتیجه نرسیدن این کار می‌تواند باعث نرسیدن ریسمان‎های واقعی به سیستم شود.

اگر با این مشکل مواجه هستید، اصلی‌ترین سوالی که مطرح می‌شود این است: در حال اجرای یک الگوریتم بزرگ درون کدهای جاوا اسکریپت هستید که در Node.js اجرا می‌شود، آیا Node.js و جاوا اسکریپت فناوری مناسبی برای استفاده هستند؟ اگر مجبور به انجام این کار هستید، باید شیوه اداره هم‌زمانی توسط Node.js و چگونگی جلوگیری از مسدودسازی حلقه رویداد را فرا بگیرید. همچنین باید یاد بگیرید که در عوض چگونه کار را به یک workerpool واگذار کنید. ایده بدی نیست که سطح دانش خود در ارتباط با ریسمان‎ها (threads) و نحوه عملکرد آن‌ها افزایش دهید.

دلیل 2. پایگاه داده شما !@#$ است
دلایل بسیار زیادی وجود دارد که می‌تواند باعث کند شدن بیش‌ از اندازه پایگاه داده شود. نخستین و مشخص‎ترین عامل کمبود ایندکس است. اگر از یک پایگاه داده SQL استفاده می‌کنید، باید یاد بگیرید که ایندکس‎ها چگونه کار می‌کنند. اگر از شرط where با سه جفت کلید/مقدار در آن استفاده می‌کنید و آن را بارها و بارها با مقادیر مختلف اجرا می‌کنید، احتمالا مشکل‌تان به یک ایندکس مربوط می‌شود. به‌عنوان مثال:

select … from customer c where c.firstname =:fname and c.lastname =:lname and c.state =:state

شما می‌توانید سه ایندکس داشته باشید. اما هنوز هم ممکن است خروجی کار به ادغام شدن ایندکس‎ها منجر شود و این به معنای آن است که نتایج این سه جست‌وجو باید با هم ادغام شوند. به جای آن ایندکسی را در نظر بگیرید که شامل تمام این سه فیلد در یک ایندکس است. برای همه این‌ها یک پیش‌بینی احتیاطی وجود دارد: در زمان واردکردن و به‎روزرسانی داده‎ها، ایندکس‎ها کند عمل می‌کنند.

یکی دیگر از علل رایج مشکل کاهش سرعت، به‌اشتباه کلی طراحی ساختار برنامه‌تان مربوط می‌شود. بسیاری از اوقات افراد یک پروژه MongoDB بزرگ را شبیه یک RDBMS طراحی می‌کنند. باید توجه داشته باشید بر اساس نوع کاری که می‌خواهید انجام دهید پایگاه داده مناسب آن را انتخاب کنید.

در اپلیکیشن‎های پیشرفته ترجیح توسعه‌دهنده این است که بتواند با انتخاب پایگاه داده کارهای زیادی انجام دهد، اما همه برنامه‎های کاربردی نمی‌توانند با همه نوع پایگاه داده به‌خوبی عمل کنند:

• اگر محاوره‎های سلسله مراتبی انجام می‌دهید یا رابطه بین دو ردیف را پیدا می‌کنید از RDBMS استفاده نکنید.
• اگر معمولا روی یک پایگاه داده مبتنی بر کلید / ارزش جدول‌ها را دوباره پیاده‌سازی می‌کنید، این کار را انجام ندهید.
• اگر اغلب با محاوره‎هایFOAF (سرنام friend-of-a-friend) سر و کار دارید، شاید به یک نمودار نیاز داشته باشید.
• اگر با محاوره‎های بسیار زیادی با نام فیلد شرطی مثل Foo% سروکار دارید از یک ایندکس مثل Apache Solr (لااقل برای این قسمت) استفاده کنید.

یک دلیل کمتر شناخته‌شده دیگر که باعث شکست پایگاه داده می‌شود این است که شما سعی می‌کنید تا به‌یک‌باره تعداد بسیار زیادی اتصال باز کنید. به‌عنوان مثال، اگر یک connection pool دیتابیس محلی داشته باشید که 100 اتصال باز می‌کند اما شما 15 سرور اپلیکیشن داشته باشید که هر کدام 100 اتصال باز می‌کنند، در نهایت 1500 اتصال وجود خواهد داشت که هر بار باید نوسازی/فراخوانی شود. چنین اقدامی‌ ممکن است به‌درستی کار نکند. اگر مشکل عملکرد به پایگاه داده مربوط است، باید آن‌ها را با ابزارهای تخصصی این کار بررسی کرده و عملکرد پایگاه داده را تحت نظر داشته باشد تا به‌سرعت بتوانید مشکل را شناسایی کنید. این کار معمولا با گزارش‌گیری از محاوره‌ها در بازه‎های زمانی مختلف یا تحت نظر قرار دادن DBA فردی که به شما اعلام کرده قادر به اداره تمام این اتصالات نیست، انجام می‌شود.

پیشنهاد ما این است درباره بانک اطلاعاتی که باید از آن استفاده کنید، اطلاعات کافی به دست آورده و سعی کنید یک بانک اطلاعاتی مناسب با کاری که می‌خواهید انجام دهید انتخاب کنید.

دلیل 3. اندازه حافظه را به‌درستی تعیین نکرده‎اید
اغلب نرم‌افزارهای تجاری پیشرفته روی نوعی ماشین مجازی مبتنی بر پشته (Stack) اجرا می‌شوند. منظور ما VMware یا Docker نیست، ما در مورد چیزی فراتر مثل ماشین مجازی جاوا JVM (سرنام Java Virtual Machine) صحبت می‌کنیم. بدون پرداختن به جزئیات نحوه عملکرد داخلی ماشین‎های مجازی، باید بدانید که تقریبا تمام آن‌ها نیاز دارند تا میزان مشخصی از حافظه را که پشته (Heap) نام دارد، به آن‌ها اختصاص دهید. همچنین آن‌ها هر زمان که یک ریسمان را اجرا می‌کنند انواع دیگری از حافظه را استفاده می‌کنند. اگر حافظه پشته آن‌ها با کمبود مواجه شود، زمان بسیار زیادی را صرف مدیریت حافظه می‌کنند که باعث کند شدن عملکرد اپلیکیشن (تا زمانی‌که کاملا از کار بیفتد) می‌شود. روی ماشین مجازی جاوا می‌توانید رویداد گزارش Garbage-Collection را فعال کنید تا ببینید که چه میزان Collection در حال اجرا است. همچنین شما می‌توانید میزان حافظه پشته را افزایش دهید، اما باید این کار را با دقت انجام دهید. خیلی از مردم فکر می‌کنند پشته تنها نوعی از حافظه است، اما یک گزینه اندازه استک –xss مربوط به ماشین مجازی جاوا وجود دارد. هر ریسمان مقدار مشخصی از حافظه استک را به خود اختصاص می‌دهد. اگر از دستوری همانند کد زیر استفاده کنید.

System Memory – (heap + otherstuff + (numthreads * numstack)) i<= 0

وقتی یک ریسمان دیگر فعال ‌شود، با نوع خاصی از کمبود حافظه مواجه می‌شوید. بر اساس نوع کتابخانه‎هایی که اجرا می‌کنید، ممکن است یک ریسمان یا اتصال پایگاه داده وجود داشته باشد که امکان اجرای آن فراهم نشود و چنین اتفاقی به کند شدن اپلیکیشن  منجر خواهد شد. خبر خوب این است که چنین اتفاقی در هر گزارشی قابل‌شناسایی است.

دلیل 4. اندازه ریسمان یا connection pool را به‌درستی انتخاب نکرده‎اید
اگر  1000 کاربر هم‌زمان و اتصال پنج پایگاه داده در pool داشته باشید، احتمالا در این pool با شرط انتظار مواجه خواهید شد. اگر روی همه این‌ها 100 ریسمان HTTP داشته باشید و تنظیمات صف انتظار اتصال TCP روی 5 باشد، بعد از این‌که 105 نفر تلاش کردند به پایگاه داده متصل شوند،احتمالا با پیغام connection refused مواجه خواهید شد، اما قبل از این‌که به این مرحله برسید کارها به‌کندی انجام خواهد شد. علاوه بر این، بعضی از نرم‌افزارها یک رقم برای ریسمان‎های قابل‌پذیرش دارند که اصولا به درخواست پاسخ داده و آن را به یکی دیگر از این ریسمان‎ها ارجاع می‌دهد. معمولا یک یا دو نمونه از آن‌ها وجود دارد. هیچ قانون ثابت و مشخصی برای تعیین کردن این ارقام وجود ندارد، اما باید مقدار آن را معقولانه انتخاب کرد. همچنین زمانی‌که این کار را انجام می‌دهید دلیل 3 را هم در نظر داشته باشید، زیرا ممکن است با محدودیت‎های دیگری مواجه شوید.

دلیل 5. محدودیت‎ها و مدیریت استفاده از فایل را به‌درستی تنظیم نکرده‎اید
اغلب سیستم‌عامل‌ها در تعداد ریسمان‎ها و فایل‎هایی که یک کاربر سیستم‌عامل اجازه باز کردن آن را دارد، محدودیت‎هایی را اعمال می‌کنند. اگر در زمان اجرای اپلیکیشن به این محدودیت برسید، قبل از خطا با کندی سرعت مواجه خواهید شد. می‌توانید این مسئله را در فایل گزارش مشاهده کنید. همچنین ابزارهایی وجود دارد که نشان می‌دهد چه فایل‎هایی قفل‌شده و چه فایل‌های فعالی در حال استفاده هستند.

منبع: شبکه