نه بگذارید باشه. چون بد نیست یه توضیحی بدم راجع به همچین بنچمارک هایی. (یا کلا بنچمارک هایی که روی
اینترنت میبینید، برای همهی زبان ها)
هر از چند گاهی یکی پیدا میشه و بچمارکی رو انجام میده و نتیجهی اون رو منتشر میکنه. اونهایی که با قضیه آشنا
نیستن، همچین چیزایی روی فکرشون خیلی تاثیر میذاره و فکر میکنن که این اعداد و ارقام خیلی واقعی هستن. اما اون هایی
که سرد و گرم این جور مطالب رو چشیدن، میدونن که این بنچمارک ها همونقدر ارزش دارن که عددی که کنار لنز گوشیتون به
عنوان مگاپیکسل درج شده ارزش داره!!
من در اینجا فقط همین یه مورد بنچمارک رو بررسی میکنم، اما چیزی که توضیح میدم برای تمام بنچمارک هایی که روی
اینترنت میبیند صادق هست.
این بنچمارک به زبان کاری نداره. همونطوری که میبینید بنچمارکی هست برای تست سرعت فریم ورک های زبان های مختلف.
یک لحظه Go رو بیخیال شید، برید پایین سمت Django و Sinatra . اینها فریم ورک هایی هستن که تعدادی از بهترین سایت
های دنیا باهاشون ساخته شدن. مطابق این بنچمارک به نظر میرسه فریم ورک های بدرد نخوری هستن درسته؟
حالا بیاید بالا سمت netty و vertx. این دو تا رو نمیشه گفت که فریم ورک هستن. ابزارهایی هستن برای اعمال «ناهمگام» (async)
توی جاوا. جاوا، زبانیه که سال هاست داره توسعه پیدا میکنه و میلیاردها دلار خرجش شده. خود netty و vertx که اینجا میبینید،
میشه گفت در دنیای جاوا چیزی بالاتر از اینها وجود نداره. با کیفیت ترین ابزارهای دنیای جاوا در این زمینه هستن. اگه Go که
توسط یه تیم چند نفره توسعه پیدا میکنه و هزینههاش هم احتمالا به چند ده هزار دلار هم نمیرسه، و هنوز یک سال هم از انتشار نسخهی
پایدارش نگذشته میاد و دقیقا بعد از اینها قرار میگیره، همینش برای من کافیه!
حالا بیاید تخصصی تر نگاه کنیم. اگه با عملیات ناهمگام آشنا باشید میدونید که این عملیات فقط در رابطه با I/O کاربرد دارد و
فقط هم تحت یک thread اجرا میشن. یعنی فرقی نداره که cpu شما چند تا هسته داشته باشه، این ابزارها به حالت معمول از یک
هسته استفاده میکنن. چون اصلا برای پردازش ساخته نشده، برای کار با I/O ساخته شده.
خوب برسیم به اینکه خود بنچمارک قضیه اش چیه. یکی پیدا شده که ماشاالله توی همهي این زبان ها و فریو ورکها وارده! و برای همشون کد نوشته!
دستش درد نکنه! توی این بنچمارک برای هر درخواست که میرسه، یک رشتهی JSON برگشت داده میشه که اندازهی نصف خط هم طول نداره. در
نهایت یعنی چند بایت از داده بدون اینکه هیچ پردازشی انجام بگیره برگشت داده میشه. دقت کنید، هیچ پردازشی صورت نمیگیره و فقط
عملیات I/O داره اتفاق میفته. اینکه چند بایت رو بفرستیم روی شبکه. همین. در نهایت هم این بنچمارک از ۲۵۶ تا کانکشن همزمان داره
استفاده میکنه (که به طور کل ۱۰۰۰۰۰ کانکشن در طول زمان بنچمارک صورت میگیره)
توی بنچمارک از فریم ورک web.go استفاده شده. خوب توی Go اصولا شما نیاز به هیچ فریم ورکی ندارید. حالا این قضیه به کنار. پس کل
قضیه اینه که برای هر درخواست، چند بایت رو بدون اینکه کار خاصی صورت بگیره برگشت بدیم. آیا همهي برنامه های وب به همین سادگی هستن؟
توی برنامه های وب هیچ پردازشی انجام نمیشه؟ مثال میزنم، وقتی یک درخواست میاد شما دوست دارید رشتهی مربوط به user-agent
رو بگیری و این رشته رو تجزیه کنی و بفهمی که کاربر از چه مرورگر و سیستم عاملی میاد تا آخر ماه یه آمار از سایتت داشته باشی.
این یه نمونهي ساده بود فقط. یه برنامهی واقعی پره از همچین پردازش هایی. مدل کار این فریم ورک ها در مقابل Go بیشتر به جوک شبیه!
Go قدرت تمام هسته ها رو آزاد میکنه. وقتی پردازش اتفاق میفته، این فریم ورک ها دستشون به چی بنده؟ وقتی هسته های cpu تعدادشون 8
تا باشه چی؟ وقتی هسته ها تعدادشون 300 تا باشه چی؟ این ها عین خنگ ها از همون یه هستهی اول استفاده میکنن در حالی که Go گریهي cpu شمارو در میاره! حالا همهی اینها بعد از اومدن نسخهی 1.1 زبان Go خیلی جالب تر میشه!
بحث سرعت به کنار، خیلی دوست دارم این آقا میزان مصرف حافظه رو هم منتشر میکرد! حاظرم شرط ببندم که Go با چند مگابایت کارش رو انجام
داده و بقیه اون فریم ورک هایی که ازش بالاتر هستن در بهترین حالت به چند صد مگ (اگه چند گیگ نباشه!) حافظه نیاز داشتن. حافظه هم به کنار، چقدر کد نوشته شده؟ مدل کد نویسی راحتتر بوده یا سخت تر؟ سرعت کد نویسی چقدر بوده؟ همهی این ها دست به دامن فریم ورک های جانبی
شدن در حالی که Go همهی این قابلیت هارو توی خودش داره و به هیچ پکیجی نیاز نداره!....
اصولا امثال این بنچمارک ها اینقدر مسخره هستن که نیاز به توصیح دادن ندارن. نه فقط این بنچمارک به خصوص، بلکه اکثر بنچمارک هایی
که میبینید (برای زبان ها و فریم ورک های مختلف) هم به همین شکل هستن. ارزش وقت طلف کردن ندارن. واقعا فکر میکنید مثلا کسایی که دارن
Django کار میکنن نمی دونن که پایتون و Django از جاوا و netty کند تر هستن؟ شده فکر کنید که پس دلیلشون برای اینکارشون چی بوده؟
چرا نرفتن از همون جاوا استفاده کنن؟ شده فکر کنید اگه همه چیز سرعت هست، چرا همه نمیان از اسمبلی یا C استفاده نمیکنن؟ از همهی اینها
هم سریع تره
همچین بنچمارک هایی فقط یک چیز رو ثابت میکنن. اینکه در این تست بخصوص، و با این کد، و در این محیط، فلان مورد از اون یکی مورد سریعتر
یا کندتر بوده. همین. دلیلی بر این نیست که همیشه قرار باشه همچین چیزی اتفاق بیفته. همونطور که گفتم، این بنچمارک ها فقط به اندازه
ی همون عددی که کنار لنز گوشی موبایل شما به عنوان مگاپیکسل نوشته شده ارزش دارن. زیاد وقت خودتونو با اینها طلف نکنید....
------------------------
آپدیت: به نظر میرسه من یک جا رو اشتباه کردم. توی netty میتونید thread poolایجاد کنید بنابراین میشه از هسته های
مختلف cpu هم استفاده کرد. هرچند که فرقی در اصل قضیه نداره چون در هر صورت پردازش ها مناسب مدل ناهمگام نیستن و در
هر حال این مدل برای I/O با مقیاس بالا مناسب هست نه پردازش های سنگین. این قضیه رو فقط موقعی میتونید درک کنید که با
برنامه نویسی asynchronous آشنا باشید.