Django darslari (Mukhammad irmatov)

Pyramid nomli Python frameworki bor, O’zbekistonda unchalik ham mashhurlikka erisholmagan bo’lsada, aslida ancha qulay va ko’p imkoniyatli freymvork hisoblanadi.

Django battery-included (hammasi ichida) freymvork bo’lsa, Pyramid minimalistik freymvork hisoblanadi. Kerakli komponentlar ehtiyojga qarab tanlanadi. Django shunday freymvorkki siz unga moslashishingiz kerak, Pyramid esa sizga moslashadi.

Misol uchun django da ma’lumotlar bazasi bilan ishlash uchun o’zini tayyor ORM bilan ishlashga majbursiz (istisnolar bor), Pyramidda istasangiz SqlAlchemy, istasangiz Pony ORM yoki boshqasini ishlataverasiz.

Python uchun veb freymvorklar juda ko’p, hammasini tagida bitta maqsad yotadi, u ham bo’lsa dasturchiga qulaylik yaratish. Barcha freymvorklarda requestlarni boshqarish, URL routing, database bilan ishlash(CRUD) kabi asosiy vazifalarni o’z ichiga olgan.

Siz ham xuddi shu vazifalarni o’z ichiga olgan freymvorkni o’zingiz Python yordamida yozishingiz mumkin. Mustaqil freymvork yozmoqchi bo’lsangiz Jakhongir Rakhmonov ni “Pythonda veb framework yozish” kursini tavsiya qilaman.

Connection pooling nima?

Connection Pooling ma’lumotlar bazasiga ulanishlarni(connections) samarali boshqarish uchun ishlatiladi. Database ga yuborilgan har bir so’rov ma’lumotlar bazasida yangi connection ni ochadi va so’rov ga javob berilgach, connection yana yopiladi. Bu jarayon uzluksiz davom etadi, bu esa jarayonni sekinlashishiga olib keladi.

Connection pool esa ma’lumot bazasi bilan bog’langan va so’rov qabul qilishga tayyor bir nechta connectionlarni saqlab turadi. Ma’lumotlar bazasiga so’rov bo’lganda, yangi connection ochmasdan, tayyor connection orqali so’rovlarga javob beradi. Database ga so’rov yakunlangach, tayyor connection yana eski holatda ishlatishga tayyor holatga qaytadi.

Django 5 da yangi qo’shilgan connection pooling va eski versiyalardagi conn_max_age connection poolingni eng oddiy ko’rinishi hisoblanadi. Production uchun app va database orasida pgbouncer ni sozlash tavsiya qilinadi

Ancha oldin id.egov.uz saytida telefon raqamim bilan ro’yhatdan o’tgan edim. Hech qanday muammosiz identifikatsiyadan o’tib, kirishga muvaffaq bo’lganman. Shu yaqin kunlarda bu tizimga yana ishim tushib, o’sha vaqtda qo’ygan parolim esdan chiqib ketganligi uchun parolni tiklash sahifasini ochdim va JSHSHIR va ro’yhatdan o’tgan telefon raqamimni kiritdim va quyidagicha xatolik oldim.

Ko'rsatilgan telefon raqami Sizga tegishli bo'lmasligi mumkin. Nomingizga rasmiylashtirilgan boshqa telefon raqamini kiritib ko'ring.

Bu telefon raqam o’zimni nomimda emasdi, hayron qoldirgan jihati bu telefon raqam bilan ro’yhatdan o’tish vaqtida muammo bo’lmagan va ancha vaqt bu tizimni ishlatib yurganman. Birdan bunday o’zgarib qolishi hech qanaqa mantiqqa to’g’ri kelmaydi.

Hay mayli qoidasi shunaqa ekanda deb, pasportimga yangi telefon raqam sotib olib, endi parolni tiklayman deganimda esa boshqa xatolikka duch keldim:

Markaziy bazada ma'lumotlar topilmagan. Kiritilgan maʼlumotlarning toʻgʻriligini tekshiring.

Bu qanaqasi bo’ldi deb, call centerga bog’langanimda telefon raqam olayotganda yangi raqamni pasport seriyasiga emas, pasportdagi JSHSHIR ga bog’latib olishingiz kerak ekan 🤯

Oddiy foydalanuvchi telefon raqam sotib olayotgan vaqtda ID tizimi pasport seriyasiga olingan raqam bilan ro’yhatdan o’tolmasligini qayerdan biladi? Shuni odamlar uchun ovoragarchiliklarsiz, qulay qilib qo’ysa ancha vaqt va asablar tejalgan bo’lar edi.

Bu tizim foydalanuchilarni vaqtini sarflab, qiynalib yurishi uchun emas, qaytganga vaqtini tejash uchun yaratilgan emasmidi?

P.S. Uzinfocomda ishlaydigan dasturchilar, parolimni tiklab beringlar kerak bo’lyapti )

ChatGPT ga rahmat, 70-80 % rezyumelar ancha yaxshilanib, to’g’ri formatga tushib qolibdi.

Faqat birgina iltimos rezyumeni wordda va hh.uz generate qilib bergan shablon da qilmanglar )

Bu savolga o’zimda ham 100% ishlaydigan aniq yechim yo’q.
Agar “sizga mana 1 yil, va istalgancha moliyaviy resurs sarflab, shu proyektni qiling”, deganda, ishni avvalo kuchli komanda yig’ishdan boshlagan bo’lardim.

Komandaga eng kamida 1 ta Database engineer, 1 ta DevOps engineer, backend dasturchi va ishni ko’zini biladigan frontend dasturchi olinar edi.

Asosiy texnologiya sifatida FastAPI ni sinab ko’rgan bo’lardim. Boshlanishiga microservice emas, monolit arxitekturani tanlardim. Database uchun relation database masalan Postgresql va connection poolni yaxshilash uchun Pgbouncer. Data partitioning, sharding va scaling kabi database tasklarni barchasini Database engineerga yuklardim.

Caching - backend uchun Redis, front uchun (CDN) Cloudflare maqul variant. Load balancing uchun Nginx va HAProxyni kombinatsiyasi ishlatsa bo’ladi. Load balancerni monolit arxitektura bo’lsada ishlatsa bo’ladi, server ichidagi instance larga traffikni baribir taqsimlash kerak.

Message queue uchun Redis emas, aynan RabbitMQ ni ishlatgan bo’lardim, chunki RabbitMQ aynan queue uchun native tool hisoblanadi. Monitor qilish uchun Prometheus va Grafana kombinatsiyasi va albatta error logs uchun Sentry.

Serverni konteynerlash uchun Docker va Kubernetes kombinatsiyasi va Cloud server esa AWS eng maquli. AWS da ham barchasi uchun alohida servis olinadi(Postgres, Redis Cluster vahokazo) va auto scale funksiyasi yoqiladi.

CI/CD pipeline github yoki gitlab emas, Jenkins orqali amalga oshiriladi. Secure bo’lishi uchun Rate limiting application levelda yoqiladi. Xavfsizlik uchun qo’shimcha ravishda CloudFlare va AWS sozlamalari ham to’g’irlanadi.

Nega moliyaviy jihatdan muammosi yo’q, istalgan server resurslarni sotib olishga qodir bo’lgan uzavtosanoat.uz sayti har doim down bo’ladi? Ular ham hech 1 million user bilan load test qilib, qachon down bo’lishini bilib shunga yarasha tayyorgarlik ko’rishadimi?

Agar sizga 1 yil vaqt berib, shu saytni down bo’lmaydigan qilgin deganda qanday yo’l tutgan bo’lardingiz? Qaysi texnologiya va usullardan foydalanib, down bo’lishini oldini olardingiz?

Load testing qilish aysbergni uchi xolos, asosiy qilinadigan ish testdan keyin bo’ladi. Har bir “Nega” degan savollaringizga debug qilib, javob olishga harakat qiling.

Agar database javob berish vaqti oshib ketib, loglarda 504(timeout) error qaytarayotgan bo’lsa, qaysi querylar ko’p vaqtni olyapti, qaysi querylarni optimizatsiya qilish haqida bosh qotirishim kerak deb o’zingizga savol bering.

Agar server CPU va memory ga yuklama 90% dan oshib ketsa, demak server resurslarini oshirish haqida bosh qotirishingiz kerakdir.

Qolgan barcha savollaringizga shoshmasdan, o’ylab javob olishga harakat qiling.

Dasturingiz BUG siz, RPS ingiz har doim baland bo’lsin : )

Load testing nega kerak?

Loyihadagi eng oxirgi buglarni ham to’g’irlab, so’nggi o’zgarishlarni deploy qilgach, endi nima ish qilsam ekan deb o’ylayotgan bo’lsangiz, dasturingizni load(stress) test qilib, uning imkoniyatlarini bilib olganingiz maqul.

Load testing - dasturga turli xil yuklama berish orqali ya’ni dastur yuklama yo’q, yuklama ko’p va yuklama haddan tashqari ko’p vaqtda qanday ishlashini bilib olish mumkin bo’ladi.

Siz o’zingiz ishlab chiqqan dasturni tinch holatda tekshirganingizda aksariyat holatda test muvaffaqiyatli o’tadi. Lekin dasturingizga 1000, 10000 va 100000 lab request jo’natilganda qanday ishlashini, qachon server ishlashdan to’xtashini albatta tekshirib olishingiz kerak.

Load testing(stress test ham deb atashadi) quyidagi savollarga javob topish uchun kerak:

1) Serverdan bir vaqtda foydalanuvchilar soni keskin oshganda qanday ishlaydi

2) Serverni maksimal qobiliyati qanday ya’ni bir vaqtda maksimal qancha user yoki qancha so’rovlarga javob bera oladi yoki server down bo’lish nuqtasi qayerda

3) Foydalanuvchilar soni oshganda response time qanchalik o’zgaradi

4) Dasturni qayerida qanday muammolar bor. Database querylar to’g’ri sozlanmaganmi yoki server resurslari yetarlimi yoki yo’q

Bu ma’lumotlarni bilish sizga dasturingiz kamchiliklarini to’g’irlashga va resurslarni to’g’ri sarflashga yordam beradi

So’nggi oylarda elektromobillarni zaryadlash biznesi ancha ommalashdi. Ilovalar ichida Tokbor va Megawatt ilovalari dizayn tomonlama ham, qulaylik tomonlama ham talabga umuman javob bermay qo’ygan.

Aprel oyidan boshlab, foydalanuvchi uchun qulay va sodda ilova yaratishni boshladik. Zaryadlash stansiyasi bilan serverni orasida bog’lanish uchun OCPP standartidan foydalaniladi ya’ni stansiyani ishlayotgan yoki ishlamayotganligi haqida signallar ham, user tomonidan mashinani zaryadlashni boshlash uchun yuboriladigan Start va zaryadlashni to’xtatish uchun Stop buyruqlar ham hammasi OCPP standarti orqali boshqariladi. Aynan shu qismi juda ko’p vaqt va resurni oldi.

Boshida 3-4 oyda bitadigandek ko’ringan sodda ilova, alohida backend, websocket server, korporativ vebsayt va Admin paneldan tashkil topgan ulkan loyihaga aylanib ketdi. Loyiha muvaffaqiyatli va o’z vaqtida topshirlishi juda ko’p faktorlarga bog’liq lekin kuchli jamoa va IT ni tushunadigan odamlar bilan birga ishlasangiz loyihani tezroq va ortiqcha stress va boshog’riqlarsiz topshirasiz.

Bizda biznes egalari odatda mutlaqo IT dan uzoq bo’lganligi uchun, websocket serverda qayeridadir muammo bo’lyapti desangiz, “men bilmayman qanday qilib bo’lsa ham to’g’irlanglar” degan javob eshitasiz yoki bo’lmasam dasturchi bilan maslahatlashmasdan turib, developmentda turgan product ni keng omma uchun ya’ni production uchun ham chiqarib yuboraveradi 😆

Shunday katta loyiha birgina backend dasturchi uchun og’irlik qiladi. Men bilan birga Abduaziz ham katta hajmdagi ishni bajardi. Abduaziz ni (AbduazizPy) o’zim tanigan eng ijodkor python dasturchilaridan biri deb hisoblayman

Ilova uchun link: Play market & Appstore

@djangodarslari