مقایسه فریمورکهای وب پایتون
سلام...
پایتون فریمورکهای متعددی برای نوشتن وب داره. به حدی گسترده که ادم حتی گیج میشه و اسمهاشون رو هم نمیتونه به یاد بیاره. در جلسه اخیر پاگ، من و دوستم امین یه سری از این فریمورک ها رو با هم مقایسه کردیم.
البته من ادعا ندارم که این بهترین مقایسه فریمورکها بوده یا اینکه تمام فریمورکهای موجود رو بررسی کردیم. بلکه بیشتر میخوام بگم که فریمورکهای معروف و مورد علاقه خودمون رو بررسی کردیم و همچنین برای من جالب بودش که بدونم چطوری میشه یه فریم ورک رو تست کرد و چطوری میشه نتایجش رو بررسی کرد.
بخشی از کدها رو من نوشتم، ولی زحمت اصلی رو امین کشید. توی این مقایسه، فریمورکهای فلسک، تویستد، جانپروتو( یاپروتو) و سنیک با هم مقایسه شدن با دو سناریو نزدیک به واقعیت.
ابتدا باید این رو بگم که دو فریم باتل و جنگو هم هستن، اما در امار وجود ندارن ولی کدشون نوشته شده که میتونید خودتون در صورت تمایل تست بکنین. همچنین مسئله دیگه این هستش که این وسط، غیر از تویستد و فلسک، بقیه با پایتون ۳ هستند و نکتهٔ اخر اینکه جانپروتو و سنیک ایسینک هستن و به قولی سرور رو بلاک نمیکنن که باعث میشه به صورت پیشفرض نتظار داشته باشیم تا چند برابر سریعتر باشن.
سوال من و احتمالا سوال شما این باشه که خوب، چقدر سریعتر؟
سناریو ها
هر سناریو، شامل دو بخش ارسال و دریافت هستش. برای دریافت مقداری از سمت کاربر به صورت Json دریافت میشه و روش پردازشی صورت میگیره. در مرحله دوم، نتیجه پردازش برای کاربر ارسال میشه. همچنین هر سناریو ۲ مرحله داره. بهتر هستش که دقیقتر بررسی کنیم:
- سناریو ۱:
- ارسال:
کاربر یک متن ازمایشی را به سرور ارسال میکند، سرور متن دریافتی را به صورت base64 برگردانده، مقدار را برای کاربر ارسال میکند
- دریافت:
کاربر متن کد شده با فرمت base64 را به سرور ارسال میکند، متن دریافتی دیکد شده و مقدار دیکدشده به کاربر ارسال میشود.
- سناریو ۲:
- ارسال:
کاربر یک متن را به سرور ارسال میکند، سرور مقدار دریافتی را در دیتابیس ذخیره کرده و id مربوط به ذخیره را به کاربر بر میگرداند.
- دریافت:
کاربر یک id را به سرور ارسال میکند و سرور در مقابل مقدار متن مربوط به آن ip را به کاربر ارسال میکند.
همینجوری که میبینید، سناریو ها، شبیه به دنیای واقعی هستند. یا صورت گرفتن یک پردازش رو بررسی میکنند یا ذخیره در دیتابیس رو. بنابراین نتیجه نهایی در اینجا میتونه به شدت نزدیک به مقداری باشه که شما در عمل دریافت میکنید.
گلوگاه
مسائل مختلفی دخیل هستن که ممکنه گلوگاه تعداد ریکوستی که وباپلیکیشن پردازش میکنه باشن. پهنای باند، توان سختافزار، طراحی دیتابیس، طراحی اپلیکیشن، مدل کد نوشتن و بسیاری مسائل دیگه میتونه به صورت مستقیم دخیل باشه در تعداد ریکوستی که در ثانیه میتونید پردازش بکنید. بنابراین میشه گفت که فوت کوزه گری و به قولی نحوه طراحی و انتخاب دیتابیس، نحوه طراحی و اجرای اپلیکیشن مهمتر از خود زبان و فریم ورک استفاده شده باشه.
نتایج سناریو اول
سناریو اول، همونشکلی بود که انتظار داشتیم. در حالی که فریمورکهای ایسینک مثل سنیک و جانپروتو در رنج ۲۰ هزار ریکوست در ثانیه بنچمارک دادند، فلسک از ارائه بیشتر از ۸۰۰ ریکوست بازماند و تویستد نیز صرفا ۲۰۰۰ ریکوست را توانست سرو کند.
کد تبدیل به base64 برای همهٔ این اپلیکیشن ها یکسان بود. با این حال میبینید که تفاوت عملکرد چقدر زیاد است.
نتایج سناریو دوم
سناریو دوم، که البته کار با دیتابیس بود، در نوع خودش جالبتر بود. چرا که عموما کار ما در حوزه وب به شدت درگیر دیتابیساست و هم اینکه معمولا دیتابیس مانگودیبی را به عنوان یک دیتابیس سریع میشناسیم. با این حال، تفاوت سرعت عملکرد در نوع خودش بسیار جالب بود. افت بسیار شدید فریمورکهای ایسینک با وجود استفاده از ORM ایسینک بازهم نتوانستند کار چندانی از پیش ببرند و دچار افت شدید چندده هزار ریکوستی شدند. عملکردی که ما را به شدت غافلگیر کرد.
در حالی که فلسک همان ۸۰۰ ریکوست خود را توانست همچنان سرو کند و نشان داد که در طراحیاش دیتابیس و غیر ان تفاوت چندانی ایجاد نمیکند، اما جانپروتو و سنیک از ۲۰ هزار ریکوست در ثانیه به ۲ هزار ریکوست در ثانیه افت کردند که در حقیقت، سقوط آزاد قدرت پردازشی انان بود.
تویستد نیز در همان رنج حدودی ۲۰۰۰ تایی خود ماند و با اینکه قدرت پردازشش به نصف رسید، اما باز هم شاهد افتی به شدت سنیک و جانپروتو نبود.
نتیجه گیری کلی
از نظر من، قدرت پردازش و سرعت یک وباپ بیشتر به قدرت پردازشی، طراحی سیستم و مسائل از این دست ارتباط دارد. به شدت مرسوم است که سیشارپ و ASP را برای وب کند بدانیم، با این حال یکی از سریعترین سایتهایی که من به شخصه دیدهام، سایت استکاورفلو است که به اندازه کافی سریع عمل میکند. در حقیقت یکی از سریعترین وبسایت های موجود است!
میشود گفت در این میان، تویستد بسیار خوب نتیجه داد. من شخصا علاقمند هستم که اگر برای تویستد نیز از ORM ایسینک استفاده شده بود، ایا باز هم شاهد این افت شدید میبودیم یا خیر.
به نظر میرسد با توجه به اینکه در نهایت الزاما باید با دیتابیس کار کنیم، و با توجه به سختی کار با فریمورکهای ایسینک و به صورت کلی نوشتن کد ایسینک، بهترین انتخاب همچنان میتواند همین امثال فلسک باشد. چرا که هم از نظر جامعه کاربری غنیاست، هم در دور و اطراف خود تعداد زیادی اکستنشن داره که نوشتن وباپ رو سادهتر میکنه.
در حقیقت، به نظرم میرسه که سرعت در اوردن پروژه با امثال فلسک سریعتر از برای مثال جانپروتو و سنیک باشه. ضمن اینکه تفاوت سرعت پردازش در نهایت به صورتی هستش که هم میشه نادیده گرفتش و هم میشه با طراحی و پیاده سازی درست اپلیکیشن، اون رو جبران کرد.
لینکها
- جانپرونتو ( اسم درستش یاپروتو هست. من اینجوری اسمش رو صدا میزنم!)
- سنیک| فلسک| جنگو| باتل| تویستد
- پنجشنبه, ۲۲ تیر ۱۳۹۶، ۱۲:۲۱ ق.ظ