مقایسه عملکرد جنگو با روبی

تفاوت عملکرد روبی با جنگو

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

این مقاله برای افراد مبتدی و کسانی که به دنبال تصمیم گیری بین این دو فریم ورک هستند نوشته شده است. در این مطلب مقایسه جنگو و روبی و عملکرد آن ها را بررسی می کنیم.

جنگو یک فریم ورک برنامه نویسی تحت وب است که در سال 2005 انتشار یافت. این فریم ورک با هدف سرعت بخشیدن به توسعه ی وب سایت های خبری ایجاد شده بود اما در طول زمان به یک فریم ورک کامل برای همه نوع کاربری تبدیل شد. برنامه های معروف زیادی در جنگو نوشته شده اند. اینستاگرام، BitBucket و Pinterest. تا ژانویه 2017، 1350 شریک جنگو در Guthub کد های خود را به اشتراک گذاشته بودند.

این فریم ورک که به اصلاح ” باتری سر خود” نیز خوانده می شود، در خود ORM ، Admin UI، ورود به سیستم و مدیرت Session ها و سایر ابزارها را دارد.

اصول معماری هسته ای در جنگو بر مبنای اصول پایتون می باشد: یعنی ” خوانش مهم است” و ” صراحت مهم تر است از تعهد”. کد های جنگو براحتی خوانده شده و روش کاری و اجرایی کد ها بسیار راحت و مشخص است.

روبی (Ruby on Rails)

روبی در سال 2008 منتشر شد. این فریم ورک در 37 سیگنال برای تواندهی به پروژه ها ایجاد شده است. روبی خیلی زود محبوبیت یافت و حتی بیشتر از جنگو مورد توجه قرار گرفت. روبی، سایت های زیادی را پشتبانی می کند : Fivvrr  و Github و AirBnB. تا ژانویه ی سال 2017، 3224 شریک روبی در Github کد های خود را قرار داده اند. مثل جنگو، روبی تمامی ابزار های خوب را برای کار بهتر با برنامه های مبتنی بر پایگاه داده فراهم می کند.

روبی دنبال کننده ی اصلی “راحتی بر پیکربندی ارجحیت دارد” فعالیت می کند؛ یعنی شما نسبت به جنگو کدهای کم تری می نویسید، ولی همیشه مشخص نیست که کار ها به چه شکل رخ می دهند و چگونه باید آن ها ویرایش کرد.

روبی در مقایسه با جنگو

بیایید این دو فریم ورک را با هم در یک جدول مقایسه کنیم.

عملکرد فریم ورک های توسعه ی تحت وب

وقتی من شروع به یادگیری برنامه نویسی تحت وب کردم، برای من عملکرد بهینه‌ی فریم ورک و سرعت زبان برنامه نویسی مهم ترین گزینه ها بودند. حتی در یک دوره من از زبان برنامه نویسی haskell به خاطر سرعتش استفاده می کردم. حالا که ده سال گذشته، برای من کاملا واضح است که فقط سرعت زبان برنامه نویسی و فریم ورک ملاک نیستند، بلکه عملکرد کلی و موفقیت نهایی آن هاست که تعیین کننده می باشد.

با نگاهی به جدول بالا، می توان دریافت که جنگو و روبی از نظر سرعت مشابه هستند و شما می توانید از هر دو برای ایجاد یک سایت سنگین استفاده کرده و در یک زمان به نتیجه برسید. اما بیایید به دنبال چیزهای مهم تری از سرع باشیم. چیز هایی که قرار است برای موفقیت برنامه ی ما مهم باشند.

چه چیزهایی عملکرد برنامه ها را تحت تاثیر قرار می دهد؟

با هم دوره ی request در هر فریم ورک را بررسی و ابزار های درگیر در این فرایند را بهتر خواهین شناخت.

Request path

برنامه های سنگین سرور  های زیادی دارند. Load balancer ابزاری است که مسیر درخواست ها را به سرور  مربوطه متصل می کند. در این مرحله یکی از فرمان های مشهور به نام HAProxy.ssl را میتوان اجرا نمود.

Web accelator

این شتاب دهنده ها برای فشرده سازی و ذخیره سازی response ها و ارائه ی سریع آن ها در بین سرور  ها و کلاینت ها مورد استفاده قرار می گیرد. یکی از قوی ترین ابزار ها در این زمینه Varnish است.

سرور وب

Nginx احتمالا تمامی کارهای مربوط به فایل های استاتیک و درخواست های پویا را در سرور ها انجام خواهد داد. توجه داشته باشید که Nginx توانایی کار های دو ابزار قبلی ( load balancer , Web accelerator) را دارد، پس پیکر بندی Nginx می تواند کارهای شما را انجام دهد.

سرور  برنامه

سرور  وب درخواست های Http را به شی تبدیل می کند تا فریم  ورک تحت وب ما بتواند آن ها را اجرا کند. برای مثال، Unicorn برای روبی و Gunicorn برای جنگو.

فریم ورک

بیشتر بخوانید:

مزایای جنگو

طراحی مدل در جنگو

در نهایت کد هایمان را اجرا خواهیم کرد. برای رسیدن به یک response ،فریم ورک ما باید کارهای زیر را انجام دهد:

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

در واقعیت، سطوح چندانه cache در برنامه مورد استفاده قرار خواهند گرفت و اگر خالی بودند از پایگاه دادهای استفاده خواهد شد.

Cache

برنامه ما سعی می کند تا صفحه ی کاربری را از cache دریافت کند. اگر موجود نبود، بخش های مختلف صفحه را از Cache بیرون خواهد کشید. برای بخش هایی که در cache نیستند، Response ها را از پایگاه داده ای گرفته و رندر خواهد نمود.

پایگاه داده ای

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

تاثیر فریم ورک

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

تاثیر معماری

وقتی هیچ چیزی در cache نباشد و برنامه باید تمامی درخواست های db را انجام داده و رندر کند، ممکن است کار تا 2 ثانیه طول بکشد.

زمان پاسخگویی در حالت Cache کامل 10تا 20 میکرو ثانیه است. وقتی بخشی از cache مورد استفاده باشد 200میکرو ثانیه است. پس بهینه سازی Cahce ها و ساختارهای پایگاه دادهای می تواند سرعت پاسخگویی را تا 90درصد کاهش دهد.

همانطور که می بینید، تصمیم های معماری داده ها می تواند تغییرات چشمگیری بر سرعت پاسخگویی داشته باشد.

سرعت 

پس می دانیم که روبی و پایتون سهم کمی در سرعت پاسخگویی کلی دارند. حالا بیایید فرق بین روبی و پایتون را در زمان اجرا بسنجیم.

در ژانویه 2017 نتایج بازی اندازه گیری نشان داد که پایتون 0.7درصد کند تر از روبی است.

این بازی در لینک زیر قابل دسترسی است:

http://benchmarksgame.alioth.debian.org/u64q/Ruby.html

نتیجه گیری:

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

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