معماری برای ماژول روتینگ
#kdht

@knowpow

“Failure is an option here. If things are not failing, you are not innovating enough.”

-Elon Musk

@knowpow

ریپو رو ساختم و کانکشن udp رو نوشتم، برای async از توکیو استفاده میکنم و نیازی به io uring نیست

https://github.com/aabolfazl/kdht

@knowpow

چیزی که توی rust اذیتم میکنه عجیب بودن سینتکسشه، اورده از هر زبون یه چیزی رو استفاده کرده یه لحظه به خودت میایی میبینی داری توی rust با سی++ جاوا مینویسی 😂 یعنی حواست نباشه به فنا میری.

البته این نظر برای امروزمه و ممکنه ماه بعد بیام بگم ای بابا چقدر ساده بودی اینم نمیدونستی؟!

@knowpow

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

@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

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