البته سینتکس زبون ساده اس، مهم ایده ی پشته زبونه که باید یاد بگیریم،‌ یعنی باید ذهنیتمون رو راستی کنیم...

@knowpow

یه کتابخونه ی خوب از مجموعه‌ی توکیو توی راست پیدا کردم به اسم MIO که میاد پایینترین لایه ای که میشه روش ابسترکشن پیاده سازی کرد رو فراهم میکنه.
کتابخونه ی MIO روی مکانیزم‌های سیستم‌عامل(epoll توی لینوکس، kqueue توی macOS/BSD و IOCP توی ویندوز) تمرکز میکنه تا یه بدون درگیری با پیاده سازی notification system بیاییم و برنامه هامون رو بنویسیم.

حالا تفاوتش با async/await خود زبون چیه؟ اگه از رانتایم توکیو استفاده میکنید به احتمال زیاد داره از mio برای مدیریت io استفاده میکنه ولی بهتون یه اینترفیس تمیز بدون درگیری و پیاده سازی مدیریت ایونت ها رو به اسم async/await فراهم میکنه توی خود mio مستلزم پیاده سازی توسط خودتونه. mio کنترل بیشتری میده ولی پیچیدگی کدنویسی رو بالا میبره، شما باید همه چی رو دستی هندل کنید و ادامه ی ماجرا دیگه به نحوه ی پیاده سازی شما داره.

سورس کد پروژه برای ایده گرفتن:

https://github.com/tokio-rs/mio

@knowpow

I just added a YAML config loader using the cpp-yaml library to my load-balancing project. Let's implement the related cluster manager and listener manager.

✅ write accept new connection using io_uring dispatcher
✅ load listeners and clusters from the config

Next commit will be:
implement listener manager and open listener according to the listeners' config

https://github.com/aabolfazl/Vortex
#vortex #io_uring #loadbalancing #cpp

@knowpow

در باب io uring

حین اینکه Vortex رو توسعه میدادم دیدم که چقدر io_uring بزرگ و عمیقه، داکیومنت موال در موردش اونقدر غنی نبود و یا خیلی پراکنده بود، پس یه پروژه‌ی جدید رو شروع کردم به اسم io-uring-lab. تمرکزش روی بررسی و پیاده‌سازی مکانیزم io_uring توی لینوکسه، که یکی از جدیدترین و بهینه‌ترین راه‌ها برای مدیریت عملیات I/O تو سیستم‌عامله.

ایده‌ی اصلی اینه که از پایه مکانیزم io_uring رو درک کنیم و ببینیم چطوری میشه ازش برای ساخت سیستم‌های پرکاربرد استفاده کرد. برخلاف مدل‌های سنتی مثل epoll، اینجا کلی از بار سیستمی کم میشه و شما می‌تونید با یه مدل مدرن‌تر و منعطف‌تر کار کنید. چیزی که این مکانیزم رو خفن می‌کنه، کاهش overhead سیستمی و امکان اجرای عملیات async بدون نیاز به context switch های اضافیه.

فعلاً شروع کردم به ساختن یه سری example ساده برای io_uring تا بدون درگیر شدن با پیچیدگی‌های ‌لایه پایین، تا بتونم عملیات async I/O رو راحت‌تر هندل کنم. توی قدم های بعدی میرم سمت پیاده‌سازی مثال هایی از وب سرور و پولینگ سیستم ها

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

لینک پروژه:
https://github.com/aabolfazl/io-uring-lab

#iouring

@knowpow

کدهایی که بین همه ی مثال ها مشترکه مثل logger و argument parser رو زدم و پوش کردم، تسک بعدی اینه که بریم سراغ اولین مثالمون:

لینک کامیت:
https://gtb/aabolfazl/last_commit

لینک ریپو:
https://github.com/aabolfazl/io-uring-lab

#iouring

@knowpow

راستی توی این پروژه دیشب به ۱۰۰ تا سرور توی کمتر از ۱۰۰ میلی ثانیه کانکشن async باز کردم.

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

#vortex

@knowpow

این مدتی که vortex رو دارم مینویسم فهمیدم یکم تو سی++ عقب موندم و چیزای جدید زیادی بهش اضافه شدن که من اپدیت نیستم، یادگیری Rust الان برام اولویت نداره، پس این پروژه رو فعلا متوقف میکنم و تمرکزم رو میبرم روی سی++ و سیستم های با تاخیر کم، تا ببینم چی میشه و کی Rust رو دوباره میارم تو برنامه، تصمیمم رو توی پست بعدی توضیح میدم

🚀 هدف اینه که یاد بگیریم چطور یه سیستم با تاخیر کم طراحی کنیم و برنامه مون رو متناسب با اون بنویسیم یا سیستمی که داریم رو پرفورمنسش رو بهتر کنیم.

پس میام به دوتا بخش تقسیم میکنم، نوشتن یه اپلیکیشن که low latency باشه، و بخش دوم اجرای اون اپلیکیشن روی کرنلی هست که بهینه‌سازی شده.

- نوشتن سیستم با تاخیر کم (low latency system design):
طبیعتا زبون مورد استفاده مون C++ خواهد بود و برای Low Latency میاییم Memory Model، Lock-free programming، Zero-Copy design، SIMD/Vectorization، Modern C++ features (17/20) رو کار میکنیم.

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

- بهینه‌سازی سیستمی:
اینجا بهینه‌سازی سطح سیستم رو انجام میدیم که شامل CPU Architecture & Cache، Kernel tuning، Network stack optimization و IO_uring & async I/O هست.

جدای از اون پروتکل TCP/IP رو تحلیل میکنیم و با تغییرات هدفمند و حذف overhead های غیرضروری، latency رو بهبود میدیم.

پروژه‌های عملی:

- لودبالانسر لایه ۴ با io_uring که در حال توسعه‌اش هستم و هر بخش رو با بنچمارک‌های دقیق بررسی می‌کنیم #vortex
- یک market data handler کم‌تاخیر که از ابتدا با هم طراحی و پیاده‌سازی می‌کنیم #market_data_handler

هر مدت یه بار آپدیت پیشرفت و چالش‌ها رو اینجا به اشتراک میذارم.

#LowLatency #SystemProgramming
#CPlusPlus

@knowpow

فعلا یه نتیجه از کدی که توی هر ثانیه نزدیک ۵۰۰ تا ایونت رو هندل میکنه رو ببینید تا ببینیم دنیا دست کیه 😃

تک هسته، تک کانکشن

آیا این کد low latency محسوب مبشه؟ نه حتی بهش نزدیکم نیست، چرا؟ چون هر ایونت به صورت میانگین داره توی ۱~۲ میلی ثانیه هندل میشه که باید برسه به ۱۰۰~میکرو ثانیه! بله همینقدر کم 🤷‍♂️

آیا همه چی به نرم افزار وابسته اس؟ نه قطعا، اینجا سخت‌افزاره که حرف اول رو میزنه بعد میرسیم به نرم‌افزار…

@knowpow

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

فعلا حالت با لیتنسی رو پیش ببرم بعد برگردم عقب دونه دونه بنچ مارک بگیرم و درست کنم یا اینکه از اول high performance پیش ببرم؟ نمیدونم فردا تصمیم میگیرم.

راستی دارم از api بایننس استفاده میکنم که خب منبع رایگان از یه مشت ایونته، دوم اینکه ایونتاش timestamp داره و میشه باهاش کار کرد و latency رو سنجید. برای IO هم از Boost Asio استفاده میکنم(خیلی دلم میخواست io uring عزیزم باشه ولی اون رو توی vortex داریم)، و برای سوکت هم بازم از boost beast استفاده میکنم.

معماری کانکشن ها هم شبیه معماری توی vortex عه با این تفاوت که مولتی پروسس نیستیم، اینجا مولتی تردیم، چون میخواییم ترد ها از کش پروسس استفاده کنند.

این پروژه در راستای این پیامه.

اکانت X من

@knowpow

باننس هم ملت رو دست انداخته ها! اخه جیسون؟ قشنگ معلومه اون پشت پول میگیره تا باینری بده

تصمیم اینه که بیاییم:

۱- کدش رو بزنیم و به هر قیمتی که شده کار کنه
۲- بعد بیاییم پرفورمنسش رو اندازه بگیریم و سریعش کنیم
۳- بیاییم سوپر سریعش کنیم (مقصود تویی مرحله ی ۱ و ۲ بهانه)

@knopow

اینجا گفتم ۲ تا پروژه ولی کلا ۳ تا پروژه داریم:

۱- با اسم vortex، لودبالانسر لایه‌ ۴ با سی++ و io uring
هشتگ: #vortex

۲- با اسم shepherd، لودبالانسر لایه‌ ۳ با eBPF و XDP، زبون سی/سی++
هشتگ: #shepherd

۳- پردازش دیتای ریل تایم از مارکت کریپتو (بایننس) و ارسال اون به تعداد زیادی کلاینت(وب سوکت، boost, beast, asio)
هشتگ: #market_data_handler

برای اندازه گیری بنچمارک هم از Google Benchmark استفاده میکنم.

@knowpow

مفاهیم شبکه، سیستم عامل(لینوکس)، معماری سی‌پی‌یو(خیلی مهمه اینجا)، نحوه‌ی کار مموری و تعاملش با سیستم و هرچیزی که مربوط به اینا باشه رو هم اینجا/توییتر و وبلاگم منتشر میکنم. سوالی داشتین بپرسین

یکمم از اینا ببینید عشق کنید:
https://youtu.be/sbSCUOTLZBo?si=hFdMA7lxu0XlaQ_T

سیستم باید اینجوری async کار کنه ولی هماهنگ باشه، رهبر ارکستر ترد master عه و بقیه هم ترد slave، شما یه مشکل توی کانکارنسی میبینی؟ نه! کدمون هم باید اینجوری باشه.

ناگهان ندایی امد و گفت همه چی رو IO و ترد نبین ای انسان... 😁

چالش طراحی threading توی پروژه‌ی market data handler

ما با یه استریمی از داده ی حجیم طرفیم که توی کمتر از 1ms باید پردازش و به بقیه ارسال بشه. پس حتی میکروثانیه ها هم مهمن برامون، حالا بیایین فرض کنیم یه ماشین با ۸ هسته داریم و فرض کنیم مراحلی که یه پکت دریافتی از وب سوکت دریافت میکنه A و B و C و D باشه، میتونیم به سه روش بیاییم هر مرحله رو انجام بدیم.

روش اول:
بیاییم ۴ دسته‌ی ۲ تایی ترد بسازیم یعنی ۴ تا تردپول ۲ تایی و از ترد ۱ تا ۸ رو به هسته های ۱ تا ۸ تخصیص بدیم و بگیم هر ترد فقط روی یک هسته باشه، بعد تسک A تا D رو به ۲ تا ۲ تا ترد تقسیم کنیم. مزیتش اینه که هم دیگه رو بلاک نمیکنن، هدف هم همینه، ولی یه مشکلی داریم، اگه تسک A بیشتر از تسک B طول بکشه چی؟ اونوقت A درگیره و ترد های B دست خالی نشستن دارن چایی میخورن، پس نیاز تسک A به ریسورس بیشتر از تسک B عه. نتیجه: این روش میره تو دیوار

روش دوم:
بیاییم برای هر تسک یه ترد پول ۸ تایی بسازیم یعنی ۴ تا ترد پول ۸ تایی داشته باشیم و در کل ۳۲ تا ترد باشه، اینجوری توزیع منابع یکسان انجام شده و هرکسی کارش بیشتر طول بکشه بیشتر از هسته های cpu استفاده میکنه، ولی کاش همینجوری بود،‌ اینجا context switch عزیزمون میاد وسط میگه کجا دارین برا خودتون میدوزین و میبافین؟ حواستون هست که کلا ۸ تا هسته داریم و سیستم عامل باید اون رو بین ۳۲ تا ترد تقسیمش کنه، شاید بگین خب اوکیه دیگه همینو میخواییم. باید بگم نه این برای این پروژه بشدت مشکل داره. چرا؟! فرض کنید توی یه اشپزخونه ۳۲ تا اشپز داریم و ۸ تا ماهیتابه، برای اینکه همه بتونن غذاهاشون رو بپزن باید ماهیتابه رو مشترک استفاده کنن، پس هروقت یه اشپز میخواست ماهیتابه ی اشپز قبلی رو استفاده کنه باید ماهیتابه رو تمیز کنه و بشوره بعد روغن خودش رو بریزه و بعد غذاش رو بپزه، و همین روند همینجوری طی بشه. بد بود نه؟ اینجا هم همینه ما داریم وقت اشپزارو توی شستن و اماده کردن ماهیتابه هدر میدیم. پس این روش هم رفت تو دیوار

روش سوم(محبوب من):
بیاییم کلا ۸ تا ترد بسازیم و همه ی تسکارو به ترتیب توی همون ترد انجام بدیم، یعنی یه پکت که وارد سیستم ما میشه یه ترد روی یه هسته بهش اختصاص میدیم و به ترتیب تسک A, B, C, D رو روش انجام میدیم و بعد ازادش میکنیم. این روش جلوگیری میکنه از کانتکس سوییچ و ما میاییم همینو با async تلفیق کنیم و دیگه میشه نور علی نور.

بریم ببینیم چی میشه

این پروژه در راستای این پیامه.

#market_data_handler

@knowpow