Concurrent requst sending and connection pool done.

Gulini guliga qo'yib tashladim 😎

Applega notificaiton send qilish uchun APNs bor va u Http2 da ishlaydi. Biz matrix notification getway yozish doirasida apple/google notificationlar send qilish uchun driverlarni ham o'zimiz ishlab chiqdik.

Apple notificaitonlar http2 da ishlaydi va bilamizki http2 connection pool ham support qiladi. Shundan foydalanib, apns driverda har bir requestga alohida emas balki bitta poolga request yozadigan mexanizm qildim.

Shunda connectionda requestlar queuega tushadi va o'zini statesiga ega. State responseni yozish uchun kerak.

runSession qilinganida esa queuega kelgan APN requestlarni o'qiydi va bittalab yozib chiqadi.

Endi buni prikol tarafi biz buni Poolinga ulab turib concurrent requestlarni nazorat qila olamiz. Ideya xozircha shunchaki proof of concept ammo o'zimga yoqib ketdi :)

Xinux jamoasiga qo'shilgani roadmap.

Yana bor

yana shedervrlardan.

Bizda toxic atmosfera emas :)

Hechqanaqa docker, k8 va yana birbalolarsiz manashu narsani high perfomance qilib ko’ramizmi ?

Faqat bazi narsalarni keskin o’zgartirib yubormasan. Masalan xozir servant ishlatamiz, buni replace qilmayman.

Concurrency va yana bazi tricklar evaziga yaxshi metrikalar olmoqchiman shunchaki.

Apn, fcm providerlarni esa vaqtincha mock qilib turamiz.

Har bir requestni esa transaction id bilan beramiz. Shunda boshidan ohirigacha track qilsak bo’ladi ammo tracking sabab bazi overheadlae bo’ladi.

Bonusga esa agar ko’proq vaqt bo’lsa application o’zini scale qiladigan qilib ko’rarmiz :)

Oylik traffic 1 Petabyte bo’lishi yaxshigina natija.

Bu degani kuniga taxminan 33 TB va ~3Gbps

Etiborli tomoni esa cachix bu nix cache hosting. U yerda nix keshlar saqlanadi. Ammo bu yerda etiborimizni qaratadigan narsalar sal boshqa.

1. Cachix serveri open source. Dastur ochiq kodli va shunga qaramasdan biznes ham qilyabti.

2. Nix ekotizimi yetarlicha kattalashib boryabti, cachix, determinate systems va yana ko'plab kompaniyalar nix atrofida enterprays yechimlarni taqdim qilishyabti.

3. Nix infratuzulma yechimlari keng rivojlanmoqda texnalogiya va biznes tomondan ham. Masalan nix as build system kabi ideyalar.

4. Cachix juda kichik jamoa va kamchilik odamlardan tashkil topgan. Ammo shunga qaramay manashunday masshtabda ishlayabti.

5. Special: Cachix serveri Haskellda yozilgan 😎

Bu ma'lumotlardan ko'p hulosalar qilsak bo'ladi. Masalan Cachix ochiq kodli dasturlar qilib ham biznes qilyabti engineering team ham juda kichik va tech stack ham unchalik mashxur emas.

Endi CVga yozsam bo'lsa kerak.

725mb > 66mb

Haskell pobeda.

Memory 100mb dan oshishi uchun apnsda 200+ concurrent request per second.

FCM esa taxminan 100 rps.

Nu juda ideal muhitda juda juda taxminimga ko'ra 50-100 rps bo'ladi.

Lekin rate limitlar, turli overheadlarni hisobga olsak bunaqa ko'rsatkichga chiqish qiyinroq. Shunda ham agar soniyasiga 50ta process qila olsa 1 soatda 150k request process qila olar ekan 100mb memory bilan.

Lekin bu raqamlar juda juda taxminiy. Metrikalarni setup qilib bir sanash kerak ekan :)

Nu xozir bazi joylarni yanada optimize qilib latency oshirsa bo'ladi, evaziga ko'proq memory beramiz. Lekin fikrimcha kerak emas :) Bizda xozir soniyasiga 100ta notificaiton ham bo'lmasa kerak.

Ammo qiziq, ancha bekorchiroq bo'lganimda apn, fcm servislarni prod bilan 1:1 simulate qilib teskhirib ko'raman latencyni.

O'ylab qarasam shuni o'zi yetar ekan qolgani bekor vaqtni sarflash. Oldin servisimiz manashu holda qanaqadir tupiklargacha borvosin. Da 700MB memory usage ko'p edi bazi runtime flaglar va kichik accumlationlarni yoqotib ko'rdim shular yetarli.

Servis o'zi shunchai notitifaction getway holos uyoqda asosiy narsa IO latency boshqa hechvaqo emas. Yani yog'liq narsani o'zi yo'q edi.

Bahonada kecha haskellda optimization haqida sal tayinli research qildim. Haskell runtime va GC haqida o'qidim, o'zi bu mavzular juda katta sekin sekin manashunaqa expirementlar doirasida ancha narsa o'rganib qo'ysa bo'ladi. Optimizatsiyalarga juda mukkasidan ketmaganman ammo o'ziga yarasha qiziq chunki Garbage collectorli til uchun bunaqa natijalar juda yoqimli. Haskellda corectess va perfomance juda balanced.

Endi keyingi qadamlar asosan biror narsalarni tezroq yakunlashga qaratilgan bo'lsa zo'r.

Yaqinda bir do'stim prikol qilgandi.

Tassavur qiling buyoqda kimdir ficha qanaqa bo'lishi kerakligini aytib turibti, siz esa eshitib yozyabsiz.

... manashunaqa narsalar bo'lishi kerak, qachon tayyor bo'ladi ?

— Aytilgan gaplarni tiplarga o'girib, servantda apilarni shaqillatib tashlaysiz va... Uje tayyor bo'ldi.

Ko'pchilik aytishi mumkin eyay bilan uje shunaqa holatdamiz deb. Ammo bizda no AI/LLM policy. Shu sabab development timeni ham raqobatdosh qilishimiz kerak. Bular juda juda context dependent mavzualr ammo o'zimga ham qiziq anchalik development timeni improve qila olamiz va buning uchun skilldan tashqari yana nimalar kerak. Masalan ekotizim qanday bo'lishi kerak etc...

Dasturchilarni aynitgan platformalar.

1. Linkedin.
2. Leetcode.
3. Aws/gcp/azue etc clouds.

Endi degradatsiyaga olib kelyotganlari esa.

Birbalo AI, LLM servislar vaxakazo. Ro'yxat uzun ekan.