مقیاس پذیر بودن همیشه یکی از بحث های داغ بین برنامه نویسان زبان ها و فریم ورک های مختلف محسوب میشه.
همیشه یه نفر هست که پیدا بشه و بگه یعنی مثلا میشه با این زبان یا فریم ورک، چیزی مثل فیسبوک یا توییتر یا گوگل یا... رو پیاده سازی کرد و به همون تعداد کاربر با سرعت مناسب پاسخ داد؟
در این بررسی می خوایم یک بار برای همیشه به این سوال پاسخ بدیم که آیا لاراول مقیاس پذیر هست یا نه؟
آیا میشه باهاش چیزی مثل فیس بوک و توییتر رو پیاده سازی کرد؟
آیا لاراول امکان پاسخ گویی به تعداد زیادی درخواست همزمان رو داره؟
خب علاوه بر کسانی که برای تفریح این سوال رو میپرسن که باهاشون کاری نداریم، ممکنه واقعا یک مدیرعامل شرکت نرم افزاری قصد داشته باشه پروژه جدیدش رو راه اندازی کنه و توی ذهنش هم قراره به بزرگ شدن و حتی بین المللی شدن پروژش فکر کنه.
در این شرایط واقعا حق داره این سوال رو بپرسه که آیا لاراول به اندازه کافی مقیاس پذیر هست یا نه؟ و اینکه در آینده با تعداد کاربران بالاتر هم میشه روش حساب کرد؟
خب یک مثال خوب از عملکرد و مقیاس پذیری PHP میتونه وب سایت ویکی پدیا باشه. این وب سایت طبق آخرین اطلاعات از استک PHP و MariaDB در بک خودش استفاده می کنه.
و طبق آمار ارائه شده، ویکی پدیا در سال 2020، تعداد 255 میلیون نمایش صفحه به صورت میانگین در روز داشته.
که این یعنی 2604 نمایش صفحه در ثانیه!
خب بعد از این آمار ببینیم وب سایتی مثل فیس بوک چه تعداد درخواست رو هندل می کنه.
آخرین آماری که از این وب سایت موجود هست مربوط میشه به سال 2010 که طبق بررسی ها در هر ثانیه 1.15 میلیون درخواست رو هندل می کرده!!!
خب این عدد واقعا بزرگتره از تعداد درخواست های ویکی پدیا
البته این نکته رو هم باید در نظر داشته باشید که وب سایت فیسبوک هم از یک ورژن شخصی سازی شده ی PHP به اسم Hack استفاده می کنه ولی فعلا با این موضوع کاری نداریم.
خب آیا لاراول واقعا امکان هندل کردن این تعداد درخواست رو داره؟
قبل از اینکه به این سوال پاسخ بدم به این موضوع اشاره کنم که این وب سایت ها هم با PHP نوشته شدن و بر مبنای اون کار می کنن:
- Tumblr با 555 میلیون بازدید کننده ماهانه
- Slack با 3 میلیون کاربر روزانه
- MailChimp
- Etsy
- وردپرس
- یاهو
- Twitch
- و...
یکی از بحث های مهم بین طرفداران زبان های مختلف بررسی و مقایسه بنچمارک های مربوط به سرعت و مقیاس پذیری هست.
نکته جالب اینه که در نهایت هم معمولا یک زبان یا فریم ورک تصادفی و کمتر شناخته شده رتبه اول رو کسب می کنه!
اینجا این سوال پیش میاد که آیا چون بهترین سرعت پاسخ گویی رو داشته حتما باید در پروژه بعدی شرکت استفاده بشه؟
به عنوان نمونه بنچمارکی در وب سایت TechEmpower منتشر شد که در اون لاراول در رتبه 388 از لحاظ تعداد پاسخ گویی به درخواست در ثانیه قرار گرفته و در همین بنچمارک dragon-core تونسته رتبه اول رو کسب کنه با امکان پاسخ گویی به 666737 درخواست در ثانیه.
جالب اینه که این تعداد از تعداد درخواست در ثانیه فیس بوک در سال 2010 بیشتره!
پس قاعدتا باید به این نتیجه برسیم که رتبه اول این لیست هم قابل استفاده برای سایتی مثل فیس بوک نیست!
خب حالا بیاید از زاویه ی دیگه ای به داستان نگاه کنیم.
در توضیحات این بنچمارک ذکر شده که:
"در این تست از ORM خود فریم ورک ها برای دریافت اطلاعات سطر ها از پایگاه داده استفاده شده است"
خب بیاید بررسی کنیم در هر درخواست چه اتفاقاتی رخ میده:
- راه اندازی کل فریم ورک
- اتصال به دیتابیس
- اجرای کوئری
- قطع اتصال به دیتابیس
خب اگر از Laravel Octane استفاده کنیم و کل لاراول رو در رم قرار بدیم که نیاز به اجرای مجدد فریم ورک در هر درخواست نباشه چی؟ اگر از persistent connection ها استفاده کنیم چی؟ اگر از یک لایه ی connection pooling استفاده کنیم چطور؟
اینجاست که باید به این نتیجه برسیم که این بنچمارک ها بی معنی و بی ارزش هستن.
واقعا به جز بحث تبلیغاتی و گرفتن بازدید چه فایده ای برای انجام چنین بنچمارک هایی وجود داره؟ چرا باید چنین بررسی هایی بدون اندک تغییراتی در ساختار اولیه فریم ورک ها و زبان ها و در نظر گرفتن نیاز ها انجام بشه؟
نکته ای که باید اینجا ذکر کنم اینه که شما در 99.9 درصد پروژه ها اصلا حتی نیاز به انجام چنین مواردی رو هم ندارید و میتونید به راحتی از لاراول برای پروژه های Enterprise خودتون استفاده کنید.
و باید بدونیم که Twitch، Disney، New York Times و Warner Bros در بسیاری از بخش ها از لاراول برای پروژه هاشون استفاده می کنن.
بذارید خیالتون رو راحت کنم، برای بحث مقیاس پذیری و scaling پروژه، لاراول قرار نیست نگرانی ما باشه بلکه نگرانی هایی که ممکنه پیش بیاد در بخش های دیگه اتفاق میفته که در ادامه بررسی شون می کنیم.
یکی از گلوگاه های scale پروژه، دیتابیس یا پایگاه داده هست. پایگاه های داده ی معمول مثل MySQL و PostgreSQL و... تا حد زیادی پاسخگوی نیاز های پروژه هستند و زمانی که پروژه بزرگ و بزرگ تر میشه باز هم با انجام تنظیمات و روش هایی که وجود داره میتونیم ازشون در پروژه ها استفاده کنیم اما به جایی میرسه که به مشکل برمیخوریم.
البته اگر از ابتدا از DynamoDB و SingleStore استفاده کنید به مشکل نمی خورید و با استفاده از قابلیت هایی که به شما میدن مثل Replication ها و Cloud Native بودن و... پروژه شما کاملا برای ساپورت مقیاس های بسیار بزرگ با انجام کمترین تنظیمات آماده هستن.
سیستم مدیریت صف لاراول از درایورهای مختلفی مثل Amazon SQS، Redis، Database و... پشتیبانی می کنه.
هدف سیستم مدیریت صف یا Queue System همونطور که احتمالا میدونید انجام کارها و وظایف زمان بر در پس زمینه هست به نحوی که خللی در اجرای برنامه ایجاد نکنه و سرعت پاسخ گویی اپلیکیشن رو کاهش نده.
در حال حاضر SQS طرفداران زیادی در این زمینه داره به این خاطر که به طرز نامحدودی امکان بزرگ شدن داره، امنیت بسیار خوبی داره و همچنین job ها رو در zone های متعددی ذخیره میکنه و دسترسی پذیریش رو به حد نهایت میرسونه.
البته از SingleStore هم میشه برای مدیریت صف ها استفاده کرد اما به نظرم بد نیست که برای مدیریت خطای بهتر، پایگاه داده و سیستم مدیریت صف رو از هم جدا نگه داریم.
همچنین از Redis هم میشه استفاده کرد که البته برای اطمینان بیشتر از امکان بزرگ شدنش بهتره تنظیمات ویژه ای براش انجام بشه.
اگر از PHP-FPM استفاده می کنید باید همیشه تحت نظرش داشته باشید و اون رو load test کنید و به نحوی تنظیمش کنید که در بالاترین سطح بهینه باشه.
و این نکته رو مد نظر داشته باشید که PHP-FPM واقعا آخرین چیزیه که باید بهش فکر کنید چون قبل از اون دیتابیس و مدیریت صف و... رو داریم.
زمانی که مقیاس و scale پروژه از حدی بزرگتر میشه، مواردی پیش میاد که در پروژه های با مقیاس کوچک تر هیچوقت مهم نبودن.
یک سری پیشنهاد و نکات برای کدنویسی با دید مقیاس پذیر بودن:
1- مطمئن بشید که کوئری های شما پایدار هستند. مهندسان فیسبوک یک توصیه مهم در این زمینه دارن: "مشکلی نداره اگر کوئری شما کنده، تا زمانی که همیشه کند باشه!" در واقع باید همیشه مطمئن باشیم که کوئری هامون رو به خوبی میشناسیم و در بهینه ترین حالت ممکن هستن.
2- هر چیزی باید سر جای خودش باشه. وقتی در مورد بحث مقیاس پذیری لاراول صحبت می کنیم قرار نیست ازش انتظار هر کاری حتی پردازش ویدیوها رو داشته باشیم. اگر سرویسی ارائه میشه که این کار رو به خوبی انجام میده و به اندازه کافی مقیاس پذیر و سریع هست میریم سراغش و ازش استفاده می کنیم.
3- کوئری های سنگین خود را کش کنید. اگر میبینید کوئری سنگینی در سیستم شما به دفعات اجرا میشه و کاربران زیادی همون نتایج یکسان رو استفاده می کنن، حتما این کوئری ها رو کش کنید.
4- بررسی محدودیت سرویس های آنلاین: اگر از یک سرویس آنلاین مثل AWS و Vapor استفاده می کنید حتما محدودیت های مقیاس پذیری و تنظیمات مربوطه رو در سرویس ها بررسی کنید و دائما مانیتورشون کنید تا در این مورد به مشکل نخورید.
و در نهایت:
آیا لاراول برای استفاده در پروژه های بزرگ مناسب است؟
شرایطی رو در نظر میگیریم که شما در یک جلسه با مدیران رده بالای شرکت نشسته اید و از شما خواسته شده در مورد مقیاس پذیری لاراول به مدیران اطمینان بدهید.
یا به جایی در پروژه رسیدید که مطمئن نیستید ادامه ی پروژه با فریم ورک فعلی یعنی لاراول برای مقیاس های بزرگ تر مناسب هست یا نه.
در این شرایط بهتون این استک رو پیشنهاد می کنم و با اطمینان میتونم بگم میتونید با همین استک میلیارد ها درخواست در ماه رو پاسخ بدید:
1- Laravel Vapor (شامل SQS، Cloudfront، ALB و S3)
2- AWS WAF سرویس فایروال ارائه شده توسط آمازون که بحث های امنیتی شما رو بر عهده میگیره و از انواع حملات و نفوذ جلوگیری می کنه.
3- SingleStore به جای RDS و Redis و DynamoDB
4- ALB یا Application Load Balancer که با استفاده از الگوریتم های توزیع بار ترافیک رو بین سرویس های شما تقسیم می کنه.
و همه چیز آمادست...
و اگر به شما گفته شد ما قراره در سطح بین المللی فعالیت کنیم کافیه که از شتاب دهنده های جهانی استفاده کنید و چندین Vapor پشت پرده در مناطق مختلف deploy می کنیم. بعد هم در SingleStore تنظیمات مربوط به cross-region replication رو انجام میدیم.
نتیجه گیری
خب فکر می کنم همه چیز کاملا مشخصه و جواب رو گرفته باشید.
اما در مجموع باید به این نکته اشاره کنم که یکی از بیهوده و عبث ترین کارهای دنیا بررسی انواع و اقسام بنچمارک هاست!
اگر فریمورکی که باهاش کار می کنید یعنی لاراول، مستندات خوب داره، پشتیبانی خوب داره، جامعه ی برنامه نویس و پذیرش جهانی خوبی داره، از چیزی نترسید و با رعایت نکات مقیاس پذیری کار خودتون رو ادامه بدید.
برداشتی آزاد از مقاله ی https://usefathom.com/blog/does-laravel-scale همراه با نکات و اضافات و شخصی
صالح هاشمی
