در صورتی که تعداد کاربران و حجم محتوای شبکه طراحی شده با استفاده از موتوشاب زیاد باشد، نیاز به تنظیمات پیشرفته بر روی کارگزار ضروری می‌گردد. به طور کلی اقدامات لازم جهت تنظیم و بهبود کارایی موتوشاب را می‌توان به دو دسته تقسیم کرد که عبارت‌اند از:

• تنظیمات صورت گرفته بر روی کارگزار وب Apache

• تنظیمات صورت گرفته بر روی پایگاه‌داده MySQL

در ادامه به شرح هر کدام از این موارد پرداخته شده است.

اگرچه انتخاب‌های گوناگونی برای کارگزار وجود دارد، اما کارگزار پیش‌فرض پشتیبانی شده در موتور شبکه اجتماعی موتوشاب Apache است. البته امکان استفاده از کارگزارهای دیگری مانند nginx نیز وجود دارد که بر حسب نیاز و بر اساس توان فنی تیم استفاده کننده از موتور، می‌توانند جایگزین Apache شوند. در ابتدا می‌بایست تصریح شود که اکیدا توصیه می‌شود کارگزار وب Apache بر روی سیستم‌عامل ویندوز راه‌اندازی نشود. چرا که تنها ماژول چندپردازه‌ای ¹ آپاچی در سیستم‌عامل ویندوز winnt است. این ماژول ضعف‌های مختلفی دارد که هنگام درخواست‌های بسیار زیاد ممکن است دچار اختلال‌ شود. در شکل 1 تصویری از توقف عملکرد Apache هنگام پردازش تعداد زیادی درخواست‌ قابل مشاهده است.

شکل 1: تصویری از توقف عملکرد Apache هنگام پردازش درخواست‌های زیاد

در لینوکس بر خلاف ویندوز به صورت پیش‌فرض از فناوری prefork به عنوان ماژول چند پردازه‌ای برای کارگزار وب Apache استفاده شده است که موجب تسریع اجرای کدهای PHP می‌شود. همچنین توصیه می‌شود که همواره از جدید‌ترین نسخه Apache استفاده شود.

به جهت تنظیم کارگزار وب می‌بایست تنظیمات زیر بر روی کارگزار صورت پذیرد:

• StartServers: مشخص می‌کند که از همان ابتدای راه‌اندازی کارگزار وب چه تعداد کارگر ² آماده پاسخ‌گویی به درخواست‌ها باشند. به ازای هر کدام از موارد فوق یک پردازه در سیستم‌عامل ایجاد می‌شود.

• MinSpareServers: حداقل تعداد کارگر بی‌کار توسط این تنظیم مشخص می‌شود. در صورتی که تعداد کارگر‌های بیکار کمتر از MinSpareServers شود، Apache تعدادی کارگر ایجاد کرده تا تعداد کل کارگر‌های بیکار برابر با MinSpareServers شود.

• MaxSpareServers: حداکثر تعداد کارگر‌های بی‌کار توسط این تنظیم مشخص می‌شود. در صورتی که تعداد کارگر‌های بیکار از این تعداد بیشتر شود Apache موارد زائد را از بین می‌برد.

• MaxRequestWorkers: حداکثر تعداد کارگزارهای موازی توسط این خصیصه مشخص می‌شود.

• ServerLimit: این خصیصه، حد بالای کل Apache را برای تعداد کارگر‌های ایجادشده و در هر لحظه اجرای سامانه مشخص می‌کند. فارغ از این‌که ماژول پردازش موازی مرتبط با Apache، prefork، event یا worker باشد. در نتیجه برای تنظیم MaxRequestWorkers نیاز به افزایش ServerLimit نیز بوده و مقدار MaxRequestWorkers نمی‌تواند از ServerLimit کمتر باشد.

• MaxConnectionsPerChild: حداکثر تعداد اتصالات به هر کارگر توسط این خصیصه قابل تنظیم است. معمولا می‌توان این مقدار را برابر با 0، به معنای اینکه محدودیتی وجود نداشته باشد تنظیم کرد.

تنظیم موارد فوق در فایل زیر صورت می‌پذیرد.

/etc/apache2/mods-available/mpm_prefork.conf

به عنوان مثال تنظیمات زیر در فایل mpm_prefork.conf برای یک سخت‌افزار با حافظه اصلی ³ با حجم 16G و پردازنده با چهار هسته که حجم کاربران آن بین 100 الی 10000 نفر باشد و همچنین بر روی آن کارگزار پایگاه‌داده نیز نصب باشد، در محیط آزمایشی سنجیده شده و نتایج مناسبی از لحاظ کارایی ارائه داده است.

<IfModule mpm_prefork_module>
        StartServers             	20
        MinSpareServers           	10
        MaxSpareServers          	40
        MaxRequestWorkers       512
        ServerLimit             	512
        MaxConnectionsPerChild   0
</IfModule>

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

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

• پیکربندی و مدل دقیق‌ سخت‌افزارهای مورد استفاده

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

* تعداد کاربران سامانه

* میانگین تعداد کاربران برخط در ساعات شلوغ

* سناریوهای پرتکرار در استفاده از سامانه.‌ به عنوان مثال مشاهده صفحه «داشبورد» یکی از سناریوهای پرتکرار است. اگرچه وابسته به کاربران سامانه ممکن است سناریوهای پرکاربرد متفاوت باشد.

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

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

پیش از هر چیز اکیدا توصیه می‌شود که از آخرین نسخه MySQL استفاده شود. MySQL در هر نسخه بهبودهای چشم‌گیری ارائه می‌کند و علاوه بر آن، تنظیمات پیش‌فرض نامناسب در نسخه‌های پیشین را نیز مرتفع می‌کند.

موتور InnoDB در پایگاه‌داده MySQL از نسخه 5.5 به بعد این پایگاه‌داده، بهبودهای چشم‌گیری یافته است. به گونه‌ای که از دیدگاه متخصصین پایگاه‌های داده MySQL از جهت کارایی⁴ و قابلیت اتکا ⁵ از مهم‌ترین رقیب خود یعنی، MyISAM به طور قابل ملاحظه‌ای پیشی گرفته است. به علاوه در نسخه‌های 5.6 و سپس 5.7 نیز این برتری بیش‌ازپیش نمایان شده تا آنجا که از نسخه 5.6 به بعد موتور پیش‌فرض در MySQL به InnoDB تغییر کرده است؛ اما موتور استفاده‌شده در موتوشاب MyISAM است. در نتیجه، ابتدا با استفاده از تعداد پرسمان می‌بایست موتور تمامی جداول را به InnoDB تبدیل کرد. بدین مقصود می‌بایست یک فایل PHP ایجاد کرده و کد زیر را داخل آن قرار داد:

<?php
    $link=mysql_connect('db_server_url','db_user','db_pass');
    $db = 'db_name';
    $sql = "SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = '".$db."' AND ENGINE = 'MyISAM';";
    $rs = mysql_query($sql,$link);
    while($row = mysql_fetch_array($rs))
    {
        $tbl = $row[0];
        $sql = "ALTER TABLE `$db`.`$tbl` ENGINE=INNODB;";
        mysql_query($sql);
    }
?>

در کد فوق می‌بایست به جای عبارات «db_server_url»، «db_user»، «db_pass» و «db_name» مقادیر مناسب قرار گرفته و سپس کد مذکور اجرا شود.

اکنون نوبت به اعمال تنظیمات MySQL می‌رسد. در این مرحله می‌بایست فایل /etc/mysql/my.cnf را باز و سپس تنظیمات را داخل این فایل وارد کرد. در این راستا تنظیمات زیر می‌بایست در بخش [mysqld] با مقادیر مناسب وارد شود.

• innodb_buffer_pool_size: این خصیصه مهم‌ترین مورد برای تنظیم در MySQL است. توسط این مقدار مشخص می‌شود که MySQL به چه میزان می‌تواند برای InnoDB pool، حافظه اصلی اختصاص دهد. شایان ذکر است که داده‌ها در pool به حافظه‌نهان ⁶ سپرده می‌شود؛ در نتیجه به هر میزان اندازه pool بیشتر شود، MySQL داده‌های بیشتری را می‌تواند به حافظه‌نهان بسپارد. مقدار این خصیصه می‌بایست تا حدی تنظیم شود که اگر تمام مقدار مذکور از حافظه اصلی به MySQL اختصاص یابد سیستم‌عامل و دیگر خدمات در حال اجرا بر روی آن دچار مشکل نشوند. به عنوان مثال در صورتی که حافظه اصلی برابر با 8 گیگابایت باشد و هیچ کارگزار دیگری جز MySQL بر روی سخت‌افزار اجرا نباشد مقدار 5G الی 6G برای این تنظیم مناسب است.

• innodb_log_file_size: تاریخچه تراکنش‌های پایگاه‌داده توسط MySQL ثبت می‌شود که از طریق آن قادر به بازاجرای⁷ پرسمان‌ها (پس از توقف⁸ عملکرد MySQL) و به عقب برگرداندن⁹ آن‌ها خواهد بود. با این تنظیم می‌توان حجم فایل تاریخچه را کنترل کرد. مقدار تعیین‌شده برای این تنظیم کاملا وابسته به میزان حجم تراکنش‌ها و عملیات‌های نوشتن در پایگاه‌داده است. نکته اساسی این است که:
  • هرچه اندازه فایل تاریخچه کوچک‌تر باشد فرایند ترمیم پس از توقف MySQL سریع‌تر شده ولی در عوض فرایند نوشتن در پایگاه‌داده کندتر خواهد شد؛ چرا ‌که فایل تاریخچه به گونه‌ای نقش یک بافر را برای عملیات‌های نوشتن ایفا می‌‌کند.
  • و هرچه اندازه فایل تاریخچه بزرگ‌تر باشد فرایند ترمیم پس از توقف MySQL کندتر شده ولی در عوض فرایند نوشتن در پایگاه‌داده سریع‌تر خواهد شد.

دقیق‌ترین مقدار برای این خصیصه را می‌توان با اندازه‌گیری حجم فایل تاریخچه طی 1-2 ساعت در شلوغ‌ترین زمان‌های سامانه سنجید:

mysql> pager grep seq
mysql> show engine innodb status\G select sleep(60); show engine innodb status\G
Log sequence number 1777308180429
...
Log sequence number 1777354541591
 
mysql> nopager
mysql> select (1777354541591-1777308180429)*60/1024/1024;
+--------------------------------------------+
| (1777354541591-1777308180429)*60/1024/1024 |
+--------------------------------------------+
|                              2652.80696869 |
+--------------------------------------------+
1 row in set (0.00 sec)

در آزمایش فوق تغییر حجم فایل تاریخچه طی یک ساعت به میزان 2.6 گیگابایت بوده است. در نتیجه با تنظیم مقدار خصیصه innodb_log_file_size به میزان 2.6G می‌توان نتیجه مناسبی را بدست‌ آورد. اما در صورتی که فرصت کافی برای این اندازه‌گیری وجود ندارد با تنظیم آن بر روی مقدار 1G الی 2G برای یک سامانه پرمخاطب، در شرایط سخت نیز این سامانه به خوبی عمل خواهد کرد.

• innodb_log_buffer_size: اندازه بافر قابل اختصاص برای تراکنش‌ها توسط این تنظیم تعیین می‌شود. در صورتی که تراکنش‌های سامانه حجیم و سنگین باشد می‌توان با افزایش این مقدار عملکرد سامانه را بهبود داد. به طورکلی موتوشاب تراکنش‌های سنگینی ندارد و علاوه بر آن از حالت autocommit استفاده می‌کند که همین امر نیز موجب کاهش حجم تراکنش‌ها خواهد شد. می‌توان به صورت پیش‏فرض این مقدار را بر روی 16M تنظیم کرد.

• innodb_thread_concurrency: در صورتی که در یک لحظه تعداد پرسمان‌هایی که پردازنده می‌بایست پردازش کند از تعداد هسته‌های آن بیشتر شود، InnoDB از این تنظیم برای کنترل هم‌زمانی در پردازش استفاده می‌کند. به طور کلی این مقدار را می‌توان به اندازه دو برابر تعداد هسته‌های پردازنده انتخاب کرد. در نتیجه در صورتی که تعداد هسته‌های پردازنده چهار عدد باشد مقدار مناسب برای این تنظیم 8 خواهد بود.

• innodb_flush_log_at_trx_commit: وضعیت عمل sync پس از هر تراکنش توسط این خصیصه مشخص می‌شود. برای این خصیصه سه مقدار 0،1 و یا 2 قابل تنظیم است:
  • 0: بعد از هر تراکنش، عمل flush اتفاق می‌افتد اما عمل sync صرفاً هر یک ثانیه اتفاق خواهد افتاد.
  • 1: بعد از هر تراکنش،‌ دو عمل flush و sync هر دو اتفاق خواهند افتاد.
  • 2: بعد از هر تراکنش، عمل flush اتفاق نخواهد افتاد و عمل sync صرفاً هر یک ثانیه اتفاق خواهد افتاد.

در صورت انتخاب موارد 0 یا 2، اگر در فاصله زمانی یک ثانیه که هنوز عمل sync اتفاق نیفتاده مشکلی برای پایگاه‌داده ایجاد شود اطلاعات تراکنش از بین خواهد رفت.

شایان ذکر است که عمل flush سبک و کم‌هزینه است. در مقابل عمل sync هزینه‌بر خواهد بود. در نتیجه کاهش تعداد رخداد sync منجر به افزایش کارایی و در مقابل کاهش تضمین تراکنش موفق پس از وقوع مشکل در اجرای MySQL خواهد شد. بنابر نظر کارشناسان مطرح این حوزه، انتخاب موارد 0 یا 2 امنیت اطلاعات را آن‌قدر کاهش نمی‌دهد که استفاده از این موارد را غیر منطقی جلوه دهد. در نتیجه در اکثر سیستم‌ها (غیر از سامانه‌های بانکی یا مشابه‌ آن‌ها که تراکنش در آن‌ها بسیار مهم است) مشکل خاصی ایجاد نمی‌شود. بنابراین در موتوشاب توصیه می‌شود اگر عملیات نوشتن بر روی پایگاه‌داده بر روی کارگزار فشار ایجاد می‌کند، از مقدار 0 استفاده شود.

• sync_binlog: توسط این خصیصه می‌توان همانندسازی پایگاه‌داده را تنظیم کرد که با تعیین مقدار 0 غیرفعال می‌شود. در موتوشاب در صورتی که نیاز به Replication نباشد بهتر است این مقدار بر روی 0 تنظیم شود.

• innodb_flush_method: با تعیین مقدار O_DIRECT برای این خصیصه، می‌توان جلوی بافر مجدد¹⁰ را گرفت.

• skip_name_resolve: با تعیین مقدار ON می‌توان، عمل بررسی DNS توسط MySQL در هر بار اتصال را متوقف کرد.

• innodb_buffer_pool_load_at_startup و innodb_buffer_pool_dump_at_shutdown: با تنظیم این دو خصیصه در هر بار خاموشی، MySQL تمامی حافظه موقت و بافر خود را در حافظه ذخیره کرده و هنگام راه‌اندازی مجدد از موارد ذخیره‌شده استفاده می‌کند. بدین مقصود کافی است تا مقدار ON برای این دو خصیصه تعیین شود.

• innodb_buffer_pool_dump_pct: این خصیصه از نسخه 5.7 به MySQL افزوده شده است و هدف از آن کنترل بیشتر بر صفحات حافظه حین فرایند خاموش شدن MySQL است. مقدار توصیه شده برای این خصیصه بین 75 الی 100 است.

• max_connections: حداکثر تعداد ارتباطات شبکه‌ای که می‌توان با MySQL برقرار کرد توسط این خصیصه مشخص می‌شود. در صورتی که کارگزارهای در حال اجرای Apache زیاد بوده و هر کدام در حال اجرای کد PHP باشد که این کد به پایگاه‌داده متصل می‌شود، ممکن است تعداد اتصالات به حد بالای تعیین‌شده رسیده و پایگاه‌داده به پرسمان‌های جدید پاسخ ندهد. در نتیجه با افزایش این مقدار متناسب با کارگزارهای Apache می‌توان از این امر جلوگیری کرد. به عنوان مثال در صورتی که تعداد کارگزارها حداکثر به صد عدد برسد این مقدار را می‌توان بر روی 200 تنظیم کرد. در این صورت به طور متوسط هر پردازه Apache قادر به برقراری اتصال با پایگاه‌داده خواهد بود.

• innodb_checksum_algorithm: در نسخه 5.7 به صورت پیش‌فرض این خصیصه بر روی crc32 تنظیم شده است؛ اما در نسخه‌های پیشین، تنظیم این مقدار باعث افزایش سرعت محاسبات خواهد شد.

• query_cache_type: این خصیصه تعیین می‌کند که آیا MySQL از سازوکار حافظه‌نهان برای نگه‌داری پرسمان‌های اجراشده و نتایج آن‌ها استفاده کند یا خیر. در صورتی که این خصیصه فعال باشد MySQL در پاسخ به پرسمان‌های جدید از نتایج پرسمان‌های گذشته (در صورتی که قابل استفاده باشند) استفاده خواهد کرد. مقدار این خصیصه می‌بایست ON تعیین شده و همچنین میزان فضای اختصاص‌یافته به حافظه‌نهان را از طریق خصیصه query_cache_size به 256 مگابایت تعیین کرد.

• table_open_cache_instances: از نسخه 5.6.6 به بعد، MySQL حافظه‌نهان جداول را به چند قسمت تقسیم می‌کند. این سازوکار بسیار مناسب بوده و در نسخه 5.7.8 به صورت پیش‌فرض مقدار خصیصه مربوطه 16 است. در صورتی که از نسخه‌های پیشین MySQL استفاده شود می‌بایست مقدار خصیصه را بر روی 16 قرار داد.

پس از اعمال تنظیمات فوق، می‌بایست MySQL راه‌اندازی مجدد شود.

همان‌طور که پیش‌تر ذکر شد، قبل و پس از تنظیم کارگزار و پایگاه‌داده می‌بایست توسط ابزارهای نظارتی ¹¹ کارایی سامانه را دقیق مورد بررسی قرار داد. تنظیم کردن کارگزار بدون اجرای آزمون و نظارت بر نتایج آن منجر به عملکرد بسیار ضعیف و غیرقابل پیش‌بینی خواهد شد. در این بخش تعدادی از ابزارهای آزمون و نظارتی به عنوان مثال ذکر شده است. تصریح می‌شود که ابزارهای معرفی‌شده تنها ابزارهای موجود نبوده و ممکن است ابزارهای پیشرفته‌تر و بهتر از موارد مذکور نیز وجود داشته باشد.

به جهت طراحی، پیاده‌سازی و گزارش‌گیری از آزمون کارایی می‌توان از ابزار Apache Jmeter ¹² استفاده کرد. این ابزار به طور کامل توسط زبان Java و با هدف آزمون عملکرد و همچنین کارایی نرم‌افزار‌های تحت وب توسعه یافته است؛ اگرچه نسخه‌های اخیر آن قابلیت‌ آزمون نرم‌افزارهایی که تحت وب نیستند را نیز دارد. توسط این ابزار می‌توان محیطی با حجم بسیار بالا از درخواست‌های موازی را برای سامانه تحت آزمون شبیه‌سازی کرده و عملکرد سامانه در این محیط را اندازه‌گیری کرد.

Jmeter نمودارهای گوناگونی نیز از عملکرد سامانه ارائه می‌کند. به طور دقیق‌تر توسط این ابزار می‌توان پروتکل‌های گوناگونی را مورد آزمون قرار داد، مانند:

• HTTP، HTTPS
• SOAP، REST
• FTP
• پایگاه‌داده از طریق JDBC
• LDAP
• SMTP، POP3 و IMAP
• اسکریپت‌های خط فرمان
• TCP

نکته بسیار مهم اینکه Jmeter یک مرورگر نبوده و حتی مشابه ابزار Selenium از یک مرورگر استفاده نمی‌کند. بلکه رفتار یک مرورگر را به صورت ساده شبیه‌سازی می‌کند. به عنوان مثال Jmeter قابلیت‌هایی چون نگه‌داری و ارسال کوکی ¹³ ، تولید درخواست به کارگزار مشابه مرورگرها و برخی از ویژگی‌های یک مرورگر را پشتیبانی می‌کند؛ اما قدرت تفسیر جاوااسکریپت‌های صفحه و همچنین CSSها را ندارد. در عوض به علت سبک بودن پردازش صفحات، قادر است تا بر روی یک رایانه شخصی تا چندهزار کاربر موازی را شبیه‌سازی کند. در شکل 2 نمایی از این نرم‌افزار قابل مشاهده است.

شکل 2: نمایی از نرم‌افزار Apache Jmeter

به طور کلی نظارت بر عملکرد کارگزار وب را می‌توان به دو جنبه تقسیم کرد:

1. نظارت بر میزان مصرف منابع سیستم‌عامل توسط کارگزار وب از جمله پردازنده، حافظه جانبی، حافظه اصلی و پهنای باند شبکه. برای بررسی لحظه‌به‌لحظه و بلادرنگ وضعیت منابع سیستم‌عامل می‌توان از دو ابزار netdata و htop استفاده کرد.
2. نظارت بر تعداد و وضعیت کارگر‌های کارگزار، تعداد پردازه‌های ¹⁴ مرتبط با کارگزار و وضعیت هر کدام. به جهت بررسی لحظه‌به‌لحظه و بلادرنگ وضعیت موارد مذکور می‌توان از ابزار Apache Status استفاده کرد.

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

NetData

NetData ابزاری توسعه‌یافته توسط زبان Nodejs بوده که بر خلاف اغلب ابزارهای موجود، به طور لحظه‌ای گزارشات متعددی را از وضعیت منابع سیستم‌عامل ارائه می‌کند، از جمله:

• وضعیت مصرفی پردازنده به تفکیک هسته‌ها
• پردازه‌های پردازنده
• ترافیک شبکه
• نوشتن/خواندن حافظه
• میزان مصرف حافظه اصلی
• وضعیت swap
• نمایش آمار با محوریت کاربران و همچنین گروه‌های سیستم‌عامل
• وقفه‌های ¹⁵ پردازنده

نمایی از NetData در شکل 3 قابل مشاهده است. در صفحه اصلی این ابزار داشبوردی حاوی اطلاعات لحظه‌ای مصرف پردازنده، حافظه اصلی، خواندن/نوشتن بر روی حافظه و پهنای باند مصرفی قابل مشاهده است. همچنین در شکل 4 نمایی از نمودارهای وضعیت پردازنده در طول زمان قابل مشاهده است. هر کدام از نمودارها وضعیت یک هسته پردازنده را مشخص می‌کند. از این شکل پیداست که یک بازه زمانی کوتاه بار پردازشی زیادی به پردازنده وارد شده و در مابقی زمان‌ها، پردازنده مشغول پردازش خاصی نبوده است. همچنین در NetData این اطلاعات را می‌توان به تفکیک کاربران سیستم‌عامل مشاهده کرد. به عنوان مثال با مشاهده اطلاعات مربوط به کاربر www-data که مربوط به Apache است، می‌توان منابعی که فقط کارگزار وب مصرف می‌کند را مشاهده کرد.

شکل 3: بخشی از قابلیت‌های netdata

شکل 4: نمایی از نمودار مصرف CPU در طی زمان. هر کدام از نمودارها وضعیت یک هسته CPU را مشخص می‌کند.

htop

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

شکل 5: نمایی از برنامه htop

ماژول Apache Status

اگرچه ابزار netdata گزارشات دقیقی از وضعیت پردازه‌ها، کاربران و گروه‌های سیستم‌عامل ارائه می‌کند، اما برای ارزیابی کارایی، شناسایی چالش‌ها و رفع ایرادات اطلاعات دقیق‌تری از تمامی کارگزارهای Apache مورد نیاز است. به عنوان مثال این‌که در هر لحظه چند کارگر کارگزار در حال اجرا هستند، چه مقدار از این موارد مشغول پردازش بوده، چه مقدار بی‌کار هستند و غیره. به علاوه ماژول Apache Status به سادگی بر روی کارگزار قابل نصب بوده و بار پردازشی کمی بر روی کارگزار اعمال می‌کند. در شکل 6 نمایی از گزارش ارائه‌شده توسط Apache Status قابل مشاهده است. در قسمت فوقانی تصویر اطلاعاتی در خصوص کارگزار، میزان مصرف پردازنده، وضعیت ترافیک، نرخ درخواست‌ها و از همه مهم‌تر تعداد درخواست‌هایی که اکنون سامانه در حال پردازش آن‌ها است قابل مشاهده است. نقاط موجود در میانه تصویر هر کدام یک کارگر کارگزار وب را نشان می‌دهد که در صورت لزوم به یک پردازه تبدیل شده و درخواست را پردازش خواهند کرد. در صورتی که نقطه به «_» تبدیل شود بدان معناست که Apache برای آن کارگر یک پردازه ایجاد کرده است که منتظر درخواست برای پردازش است. در صورتی که حالت به «W» تبدیل شود، بدان معناست که پردازه در حال پردازش و ارسال پاسخ است. سایر حالات پردازه‌ها با مراجعه به مستندات Apache Status قابل مشاهده است.

شکل 6: نمایی از گزارش Apache Status در خصوص وضعیت کارگزار وب

به طور کلی عملکرد پایگاه‌داده به طور مشابه با کارگزار وب از دو وجه می‌بایست بررسی شود:

1. نظارت بر میزان مصرف منابع سیستم‌عامل توسط پایگاه‌داده از جمله پردازنده، حافظه جانبی، حافظه اصلی و پهنای باند شبکه. برای بررسی لحظه‌به‌لحظه و بلادرنگ وضعیت منابع سیستم‌عامل نیز می‌توان از دو ابزار netdata و htop استفاده کرد.
2. لیست‌های مرتبنظارت بر عملکرد پایگاه‌داده، پرسمان‌های اجرا‌شده، پرسمان‌های کند و زمان‌بر، میزان مصرف بافر و غیره. بدین مقصود می‌توان از امکانات نظارتی ارائه‌شده توسط MySQL، ابزارهای عیب‌یابی ارائه‌شده توسط هسته موتوشاب و همچنین ابزار قدرتمند Percona-toolkit استفاده کرد.

طریقه بهره‌گیری از ابزار‌های netdata و htop پیش‌تر شرح داده شد. در ادامه به شرح ابزار‌های مورد استفاده به جهت نظارت بر عملکرد پایگاه‌داده پرداخته شده است.

امکانات نظارتی ارائه‌شده توسط MySQL

قابلیت‌های نظارتی ارائه‌شده توسط MySQL که در ارزیابی عملکرد و کارایی پایگاه‌داده می‌توان از آن‌ها استفاده کرد به شرح زیر است:

• با تنظیم خصیصه slow_query_log به مقدار ON و همچنین long_query_time به مقدار دلخواه به جهت مشخص کردن پرسمان‌های کند، می‌توان پرسمان‌های ارسال‌شده به MySQL به همراه زمان اجرای هر کدام را ثبت کرد. در این راستا MySQL به صورت پیش‌فرض فایلی در آدرس /var/log/mysql حاوی پرسمان‌های کند ایجاد می‌کند.
• با استفاده از دستور SHOW FULL PROCESSLIST می‌توان فهرستی از پرسمان‌های در حال پردازش را در لحظه مشاهده کرد.
• دستور SHOW GLOBAL STATUS، آمار و خصیصه‌های فعلی پایگاه‌داده را نشان می‌دهد. بخشی از آمارهای ارائه‌شده توسط این دستور در شکل 7 قابل مشاهده است.

شکل 7: آمارهای ارائه‌شده توسط دستور SHOW GLOBAL STATUS

ابزار عیب‌یابی موتوشاب

با فعال‌سازی PROFILER_ENABLE در فایل config.php موتوشاب، در هر درخواست، تمامی پرسمان‌های پایگاه‌داده به همراه زمان اجرای هر کدام قابل مشاهده است. به علاوه زمان اجرای توابع PHP نیز در این گزارش قابل مشاهده است.

شکل 8: تصویری از ابزار نمایش پرسمان‌های پایگاه‌داده توسط موتوشاب

percona-toolkit ¹⁶

این بسته نرم‌افزاری حاوی تعداد زیادی ابزار برای نظارت بر عملکرد و کارایی MySQL است. ابزارهای ارائه‌شده در خط‌فرمان سیستم‌عامل قابل دسترس بوده و عملا واسط کاربری گرافیکی ندارند. شایان ذکر است که ابزارهای ارائه‌شده توسط شرکت Oracle برای نظارت بر کارایی MySQL به مراتب پیشرفته‌تر هستند اما اغلب این موارد رایگان نیستند.

به عنوان مثالی از ابزارهای percona-toolkit می‌توان به pt-query-digest اشاره کرد. ورودی این ابزار تاریخچه پرسمان‌های اجراشده توسط MySQL است که توسط فعال‌سازی تنظیم slow_query_log ایجاد خواهد شد. خروجی این ابزار گزارش دقیق از پرسمان‌های سنگین سامانه و آمار و ارقام مرتبط با آن‌ها است؛ بنابراین کافی است پرسمان‌های کند اجراشده طی مدت مشخصی را توسط MySQL ثبت کرده و به ابزار pt-query-digest داد تا این ابزار گزارش دقیقی‌ از پرسمان‌های کند مرتب‌شده بر اساس میانگین زمان اجرا ارائه کند. شایان ذکر است که percona-toolkit علاوه بر pt-query-digest شامل 31 ابزار دیگر نیز بوده که از بین آن‌ها می‌توان به موارد زیر اشاره کرد:

به عنوان مثالی از ابزارهای percona-toolkit می‌توان به pt-query-digest اشاره کرد. ورودی این ابزار تاریخچه پرسمان‌های اجراشده توسط MySQL است که توسط فعال‌سازی تنظیم slow_query_log ایجاد خواهد شد. خروجی این ابزار گزارش دقیق از پرسمان‌های سنگین سامانه و آمار و ارقام مرتبط با آن‌ها است؛ بنابراین کافی است پرسمان‌های کند اجراشده طی مدت مشخصی را توسط MySQL ثبت کرده و به ابزار pt-query-digest داد تا این ابزار گزارش دقیقی‌ از پرسمان‌های کند مرتب‌شده بر اساس میانگین زمان اجرا ارائه کند. شایان ذکر است که percona-toolkit علاوه بر pt-query-digest شامل 31 ابزار دیگر نیز بوده که از بین آن‌ها می‌توان به موارد زیر اشاره کرد:

• pt-config-diff: توسط این ابزار می‌توان تفاوت دقیق بین پیکربندی موجود در یک فایل پیکربندی را با پیکربندی فعلی کارگزار MySQL مشاهده کرده و با یک‌دیگر مقایسه کرد.
• pt-deadlock-logger: توسط این ابزار می‌توان تمامی بن‌بست‌های رخ‌داده در MySQL را با فرمت مناسب ثبت کرد.
• pt-diskstats: این ابزار بستری تعاملی را برای نظارت بر رفتار حافظه جانبی فراهم می‌کند.
• pt-duplicate-key-checker: این ابزار تمامی شاخص‌ها و کلیدهای خارجی تکراری را در پایگاه‌داده شناسایی می‌کند.
• pt-heartbeat: این ابزار بستری را برای نظارت بر تاخیر در عملیات همانند‌سازی در پایگاه‌داده فراهم می‌کند.
• pt-index-usage: این ابزار تاریخچه پرسمان‌های پایگاه‌داده را به عنوان ورودی گرفته و وضعیت و چگونگی استفاده پرسمان‌ها از شاخص‌های پایگاه‌داده را گزارش می‌کند.
• pt-fingerprint: این ابزار یک پرسمان را به عنوان ورودی گرفته و اثرانگشت آن را بازمی‌گرداند. اثرانگشت صورتی انتزاعی از یک پرسمان است که داده‌های آن با ؟ جایگذاری می‌شود.
• pt-kill: این ابزار پرسمان‌هایی که از الگوی خاصی پیروی کنند را از بین می‌برد.
• pt-mysql-summary: این ابزار اطلاعات مربوط به MySQL را به صورت مناسبی خلاصه‌ و ارائه می‌کند.

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

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

تعداد زیادی از درخواست‌های ارسال‌شده به کارگزار وب معمولا درخواست‌های مربوط به دریافت فایل‌های CSS، جاوااسکریپت و تصاویر است. در نتیجه یکی از راه‌های موثر در کاهش قابل توجه تعداد درخواست‌های ارسال‌شده به کارگزار وب استفاده از شبکه‌های توزیع محتوا است.

بر اساس ارزیابی‌های صورت گرفته و گزارشات ارائه شده در سطح اینترنت، کارگزار وب Nginx کارایی بیشتر و مصرف منابع کمتری نسبت به Apache دارد. در نتیجه یکی از اقدامات موثر در راستای افزایش کارایی موتوشاب تغییر کارگزار وب از Apache به Nginx است.

ازآنجاکه در موتوشاب لایه داده به خوبی از لایه برنامه ¹⁷ جدا شده است، می‌توان لایه برنامه را بر روی چند کارگزار وب چنان اجرا کرد که همگی از یک پایگاه‏‌داده استفاده کنند؛ بنابراین مسئله قابلیت‌ اجرای موازی بر روی چند کارگزار وب با توجه به معماری موتوشاب قابل‌حل خواهد بود.

بحث مهمی که در ادامه مبحث توزیع‌ در نرم‌افزار مطرح می‌شود توازن بار کاری¹⁸ است. کاربران سامانه نباید از بیرون متوجه توزیع‌شدگی سامانه شوند. درنتیجه یک کارگزار نقش دریافت‌کننده درخواست و ارسال آن به کارگزار(های) برنامه مناسب را دارد. این کارگزار باید درخواست‌ها را به نحو متوازن بین سایر کارگزاران پخش کند. چالشی که در چنین شرایطی مطرح می‌شود نحوه نگه‌داری نشست¹⁹ کاربران بوده که با استفاده از فناوری‌ memcached مرتفع می‌گردد.

با نگاهی دقیق به معماری لایه‌داده در موتوشاب پیش‌فرض پایگاه داده رابطه‌ای²⁰ در آن موج می‌زند. درنتیجه امکان استفاده از پایگاه داده‌های NoSQL که به صورت پیش‌فرض قابلیت توزیع‌شوندگی را دارا هستند، در موتوشاب تغییر اساسی معماری را می‌طلبد که ریسک بسیار بالایی را در پروژه به همراه‌ دارد و قابلیت به‌روزرسانی نرم‌افزار را با توجه به حجم بالای تغییر با خطر جدی مواجه خواهد کرد.

اغلب شبکه‌های اجتماعی بزرگ مانند Facebook و Pinterest در ابتدا با پایگاه‏‌داده رابطه‌ای کار خود را آغاز کردند. کاربران و محتوای این شبکه‌ها پس از مدتی افزایش چشم‌گیر یافت و سازندگان این خدمات عمومی راه‌حل‌هایی برای فراهم‌سازی مقیاس‌پذیری در لایه داده مبتنی بر پایگاه داده رابطه‌ای ابداع کردند. یکی از این راه‌حل‌ها استفاده از معماری ارباب/ برده ²¹ در سطح پایگاه داده بوده که ویژگی‌های آن به شرح زیر است:

• در معماری ارباب/ برده یک پایگاه‌‏داده نقش ارباب را ایفا می‌کند. تمامی کارگزاران برنامه‌کاربردی پرسمان‌های از نوع افزودن یا به‌روزرسانی اطلاعات را به پایگاه داده ارباب ارسال می‌کنند.
• چندین پایگاه‏‌داده به عنوان برده صرفاً نقش پاسخ‌گویی به پرسمان‌های بازیابی اطلاعات را دارند. این برده‌ها به صورت مستمر از طریق عملیات همانندسازی خود را با ارباب همگام می‌کنند.
• بنابراین کارگزاران برنامه‌ کاربردی قادر هستند پرسمان‌های نوع بازیابی اطلاعات را به هر یک از برده‌ها ارسال کنند.
• درنتیجه‌ی این معماری عملیات بازیابی اطلاعات توزیع خواهد شد.

* این معماری مبتنی بر این باور است که در خدمات عمومی حجم بازیابی اطلاعات از ثبت و به‌روزرسانی آن به مراتب بالاتر است. از آنجا که این عقیده در شبکه‌های اجتماعی کاملاً صدق می‌کند، درنتیجه در این معماری کارگشا خواهد بود.

شکل 9: معماری عمومی پایگاه داده ارباب/ برده

با توجه به جداسازی لایه داده در موتوشاب می‌توان عملیات بازیابی اطلاعات را به برده‌ها ارسال کرده و نوشتن و به‌روزرسانی را به ارباب ارسال کرد. درواقع کنترل اتصال به پایگاه داده و ارسال پرسمان‌ها به صورت مرکزی صورت می‌پذیرد. درنتیجه تغییر چنین رفتاری کار چندان دشواری به نظر نمی‌رسد. در انتها دوباره تاکید می‌شود که به‌روزرسانی پایگاه‌‌های داده‌ برده از روی ارباب در لایه پایگاه‌داده و از طریق عملیات همانند‌سازی صورت می‌پذیرد و ارتباطی با موتوشاب ندارد.

به طور کلی کارگزار نام، وظیفه دریافت دامنه یک کارگزار و در عوض تعیین آی‌پی آن را دارد. با استفاده از ساز و کار توازن بار کاری²² از طریق یک کارگزار نام می‌توان درخواست‌های ارسال‌شده به سامانه را بین کارگزاران مختلف پخش کرده و بدین ترتیب یک توازن در تعداد درخواست‌های ارسال‌شده به هر کارگزار برقرار کرد. از طریق این سازوکار می‌توان به مراتب مؤثرتر نیز عمل کرد؛ بدین‌صورت که کارگزار نام، کارگزاری را به عنوان صاحب نام به کاربر معرفی می‌کند که از جهت جغرافیایی به آن نزدیک‌تر باشد. به عنوان مثال کاربری که از ایران قصد اتصال به شبکه اجتماعی را دارد به کارگزاری در داخل ایران متصل شده و کاربری که از یک کشور خارجی قصد اتصال به شبکه اجتماعی را دارد به کارگزار نزدیک‌تر از جهت جغرافیایی متصل شود. حال‌آن‌که هر دو کاربر دامنه وبگاه را یکسان می‌پندارند؛ بنابراین این وظیفه کارگزار نام است که آی‌پی مناسب را به هر کاربر معرفی کند.

باید توجه کرد که این قابلیت‌ مستقل از برنامه ‌کاربردی بوده و می‌توان آن را برای هر سامانه‌ای که قابلیت نصب و راه‌اندازی در چند کارگزار را دارا است راه‌اندازی کرد؛ بنابراین در صورت توزیع موتوشاب می‌توان از این سازوکار نیز بهره برد.

اگرچه به نظر می‌رسد با توزیع لایه برنامه‌کاربردی و همچنین لایه‌ پایگاه‌‏داده مسئله مقیاس‌پذیری حل می‌شود، اما سناریو‌هایی وجود دارند که بار پردازشی بسیاری را بر روی کارگزاران پایگاه‌‏داده تحمیل می‌کنند. به عنوان مثال در تمامی صفحات یک شبکه اجتماعی همواره تعداد پیغام‌های خوانده‌نشده توسط کاربر را به او نمایش داده؛ بنابراین بازدید هر کاربر از هرکدام از صفحات سامانه منجر به ارسال یک پرسمان به جدولِ سنگین و حجیم پیغام‌های پایگاه‌‏داده خواهد شد. در چنین شرایطی استفاده از کارگزاران حافظه‌نهان بسیار مفید خواهد بود. این کارگزاران درواقع پایگاه‌‏داده‌هایی هستند که اطلاعات را در حافظه موقت نگه‌داری می‌کنند. درنتیجه ذخیره و بازیابی اطلاعات در آن‌ها بسیار سریع خواهد بود. برخی از آن‌ها اطلاعات را در حافظه دائم نیز ذخیره می‌کنند (مانند Redis²³ ) و برخی دیگر چنین اقدامی نمی‌کنند (مانند memcached ²⁴ ).

متأسفانه برای استفاده از این فناوری‌ها در یک سامانه نرم‌افزاری اغلب تغییرات اساسی در معماری موردنیاز است. موتوشاب به صورت پیش‌فرض از فناوری‌های حافظه‌نهان پشتیبانی نمی‌کند؛ اما آنچه در معماری موتوشاب امیدوارکننده است زیرساخت رویداد در این موتور شبکه اجتماعی است. با استفاده از رویداد می‌توان از اتفاقات و تراکنش‌های هسته مطلع شد و اقدام مناسب را صورت داد. بدین ترتیب یک سازوکار منتشرکننده-مشترک ²⁵ در سرتاسر موتوشاب فراهم شده است. درنتیجه امکان افزودن رفتار (در اینجا ذخیره و بازیابی اطلاعات از کارگزاران حافظه‌نهان) به موتوشاب بدون تغییر هسته آن وجود دارد. به عنوان مثال با توجه به معماری Oxwall می‌توان مشترک رویداد «ایجاد یک پیغام در سامانه» شده و پس از رخداد آن یک نسخه از پیغام را نیز در کارگزار حافظه‌نهان ذخیره کرد؛ بنابراین اطلاعات مربوط به پیغام‌ها از حافظه‌نهان نیز قابل‌دسترسی‌ خواهد بود.

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

در این نمونه آزمایشگاهی از رویکرد «اجرای کارگزار وب و کارگزار پایگاه‌داده بر روی ماشین‌های مجزا» استفاده شده است. در نتیجه بر روی ماشینی که کارگزار وب بر روی آن نصب بوده و همچنین ماشینی که کارگزار پایگاه‌داده بر روی آن نصب است هیچ خدمت دیگری ارائه نمی‌شود. دو ماشین مذکور با پیکربندی زیر مورد استفاده قرار گرفته است:

• حافظه اصلی:16GB
• پردازنده: Intel xeon e5520, 4 cores 2.266GH
• حافظه جانبی: 20GB HDD

در ادامه پیکربندی هر کدام از کارگزارها ارائه شده است.

نسخه کارگزار وب Apache مورد استفاده برابر با 2.4.7 بوده و پیکربندی آن به شرح زیر است:

<IfModule mpm_prefork_module>
        StartServers             	100
        MinSpareServers           	80
        MaxSpareServers          	500
        MaxRequestWorkers       2048
        ServerLimit             	2048
        MaxConnectionsPerChild   0
</IfModule>

نسخه MySQL مورد استفاده Ver 14.14 Distrib 5.7.13 بوده و پیکربندی کارگزار پایگاه‌داده به شرح زیر است:

innodb_buffer_pool_size = 11G
long_query_time = 0.1
slow_query_log = ON
#tx_isolation = READ-COMMITTED
log_error = /var/log/mysql/error.log
slow_query_log_file = /var/log/mysql/mysql-slow.log
innodb_log_file_size = 1G
innodb_log_buffer_size = 16M
innodb_thread_concurrency = 8
innodb_flush_log_at_trx_commit = 0
sync_binlog = 0
innodb_flush_method = O_DIRECT
skip_name_resolve = ON
innodb_buffer_pool_load_at_startup = ON
innodb_buffer_pool_dump_at_shutdown = ON
innodb_buffer_pool_dump_pct = 75
max_connections = 1000
innodb_page_cleaners = 8
query_cache_type = ON
query_cache_size = 256M

پیکربندی که در این بخش ارائه شده است قادر به پردازش مناسب درخواست‌های کاربران توسط یک سامانه موتوشاب با ویژگی‌های زیر است:

• تعداد کل کاربران سامانه 1000000 نفر است.
• هر کاربر بین 1 الی 20 دوست دارد. تعداد دوستان هر کاربر به صورت تصادفی تعیین شده است.
• تعداد کل نوشته‌های داخل سامانه 1000000 عدد است.
• 2000 کاربر برخط به صورت هم‌زمان وارد سامانه شده و در آن فعالیت می‌کنند.
• فعالیت‌های شبیه‌سازی‌شده شامل تعدادی از متداول‌ترین رفتارهای کاربران در موتوشاب است. از جمله ورود به سامانه، مشاهده صفحه داشبورد و غیره.