Dr. Algorithm
3.05K subscribers
470 photos
52 videos
3 files
534 links
Saidolim Djuraev’ning mantiq va qiziqarli ma'lumotlar haqida kanali.

Savollar yoki javoblar uchun: @DrAlgorithmBot
Download Telegram
Diplom shartmi?
Universitetda oʻqish shartmi?


Man javobini topdim.

Universitet menga nima beradi emas,
Universitetda nima oʻrgana olaman? - deb fikrlash kerak.


@DrAlgorithm
👍27🔥3
Bitta katta lagan oshdan,
Kunlik kichik kosa yaxshi.


Azizbek Rahimov juda zoʻr maqola chop etibdilar. Oʻqib koʻring tavsiya etaman.

https://t.me/azizrakhimov_blog/763

Deadline deb koʻp bong uramiz. Ulgurmayapmiz deb ishdan tashqari (overtime) ishlaymiz. Yechimi esa sodda ekan.

Small steps = Kichik qadamlar


Koʻp ish qilish shart emas. Ulgurganizcha qism bilan boshlang va ketma-ketlikni uzmang, vaqti kelib kunlik meyorni (norma) koʻtarib boras.

Kichik qadamlar uchun bugun kichik qadam qoʻying.

@DrAlgorithm
👍12💯2
Chet elda magistraturaga Grant yutish haqidagi taqdimot boshlandi:

https://www.youtube.com/live/4D3HX3FlH7g

O`tkazib yubormang!

@DrAlgorithm
82
Forwarded from UzGeeks Community
Assalom alaykum!!!
UzGeeks'da PHP kuni!

📆 25-may shanba kuni Toshkent shahri Raqamli texnologiyalar vazirligi binosida "UzGeeks May2024 PHP Day Meetup" bo'lib o'tadi.

1️⃣. “PHP - Highload” - Milly Khamroev(Senior engineer/TeamLead, Click/Modme)

🕰 Meetup odatiy ravishda bepul bo'lib, soat 14:00 da boshlanadi, unda qatnashish uchun UzGeeks saytida ro'yxatdan o'tish kerak.
Manzil: Toshkent shahar, Mirzo Ulug'bek tumani, Muminov ko’chasi, 4A(Raqamli texnologiyalar vazirligi binosida)


Hamkorlar:
O'zbekiston Respublikasi Raqamli texnologiyalar vazirligi
Raqamli ta'limni rivojlantirish markazi
Thinkland
Tadbir facebookda
🌐 UzGeeks.uz
Forwarded from UzGeeks Community
Assalom alaykum!!!
UzGeeks'da PHP kuni!

📆 25-may shanba kuni Toshkent shahri Raqamli texnologiyalar vazirligi binosida "UzGeeks May2024 PHP Day Meetup" bo'lib o'tadi.

📚 Meetup quyidagi bo'limlardan tashkil topgan:

2️⃣. “Futbol yangiliklari arxitekturasini qurish” - Sag'indiq Kenjabaev(Freelancer).

🕰 Meetup odatiy ravishda bepul bo'lib, soat 14:00 da boshlanadi, unda qatnashish uchun UzGeeks saytida ro'yxatdan o'tish kerak.
Manzil: Toshkent shahar, Mirzo Ulug'bek tumani, Muminov ko’chasi, 4A(Raqamli texnologiyalar vazirligi binosida)


Hamkorlar:
O'zbekiston Respublikasi Raqamli texnologiyalar vazirligi
Raqamli ta'limni rivojlantirish markazi
Thinkland
Tadbir facebookda
🌐 UzGeeks.uz
Bugungi UzGeeksning PHP Day tadbiriga uzoqdan Speakerlar taklif qilingan.

Avvallari, Xitoyda boʻlsa ham ilm izla, - deyilardi.

Hozir ustozlarni kelishgan.

Hullas, UzGeeks May2024 PHP Day Meetup da kutamiz.

@DrAlgorithm
👍21
Forwarded from UzGeeks Community
@uzgeekscommunity kanalda meetup live bo’lmoqda!
Sag'indiq aka web loyihalarni ustidan qotib tashlayaptimi? Cherperak qilib aylantirib tashayapti, 10-15 minutni ichida katta sport saytini tugatib, APIlarini chiqarib ko'rsatyaptilar. Copilotdan foydalanar ekan. Kod yozish esimdan chiqib ketyapti deydi😅🤦🏻‍♂️

PHPchi Yii'chida aka
14😱3🤣1
Forwarded from UzGeeks Community
Networking time.

@uzgeekscommunity
👍3
Forwarded from UzGeeks Community
Bugungi meetupga kelganlarga, dokladchilarga katta rahmat!
O’ylaymizki foydali va manfaatli bo’ldi!

@uzgeekscommunity
👍11
Forwarded from azam – logs.
Bugun PHP bo'yicha UzGeeks'da meetup bo'lib o'tdi. Ishtirokchi bo'lib qatnashdik. Afsuski dokladchi sifatida qatnashishni reja qilgandim, ammo Mayda tasodifan bo'lib qolgani uchun tayyor bo'lolmadim.

Milly Khamroev akadan yaxshi mavzuda suhbat bo'ldi: PHP Highload.

PHP loyihalarda requestlarga javob berish darajasi, loyihani turib berish, tez ishlash jarayonlarini yaxshilash bo'yicha tajribadan o'tkazishgan case'lari bo'yicha real gapirildi.
Forwarded from azam – logs.
azam – logs.
Bugun PHP bo'yicha UzGeeks'da meetup bo'lib o'tdi. Ishtirokchi bo'lib qatnashdik. Afsuski dokladchi sifatida qatnashishni reja qilgandim, ammo Mayda tasodifan bo'lib qolgani uchun tayyor bo'lolmadim. Milly Khamroev akadan yaxshi mavzuda suhbat bo'ldi: PHP…
1. Database: Race Condition. Prizlar ro'yxati bor. 5 tadan 3 tasi aktiv, 2 tasi tark etgan. Endi navbatdagi ishtirokchiga keyingi prizni qaytarish kerak. Bunday holatlarda bir vaqtda ikkita request birga kelishi oqibatida ikkita ishtirokchiga bitta sovg'a ketib qolishi mumkin. Bu narsani oldini olish uchun esa, "Lock for Update" metodi orqali amalga oshirish, bu muammoga yechim beradi. Bu holatda birinchi request tanlagan priz, o'zgarish uchun bloklanadi. Natijada keyingi request bu prizni tanlamaydi, balki boshqasini tanlaydi.

2. Database: Slow queries. Bazaga ko'p murojat qilish va natijada loyihani sekinlashtirish doimiy muammolardan. Indekslash esa bunga yaxshi yechim bera oladi. Bazadagi ma'lumotlarni indekslash orqali slow query'larni ishlashini tezlashtiramiz.

3. Database: Indexing cons. Indekslashni minus tomonlaridan biri, "insert, update, delete" uchun query'larni sekinlashib qolishi. Bu muammoga bazani ikkitaga bo'lish orqali yechim beriladi, ya'ni "DB Replication". Bitta asosiy baza - "insert, update, delete" uchun, ikkinchi baza asosiy bazani ko'chirmasi sifatida "select" uchun ishlatilinadi. Ikkinchi baza asosiy bazadan ma'lumotlarni o'ziga sync qilib turadi.

4. Database: Caching. Ba'zi natijasi o'zgarmas query'larni keshlash bazaga ortiqcha request'ni oldini oladi. Kesh tizimi bazaga murojaat qilishdan ko'ra tezroq ishlaydi. Bu holatga "Redis" yaxshi yechim beradi.

5. Redis: Too many connections. Ba'zida Redis'ga request'lar ko'payib ketishi natijasida Redis ham javob berolmay qoladi. Bu muammo o'zimda ham uchragandi. Ammo muammoni hal qilolmagandim. Bunga yechimlaridan biri "Pooling" qilish. Default holatda Redis'ga berilgan request bitta connection ochadi. Ishini to'xtatgandan keyin u connection yopiladi. Pooling'da esa bitta connection doimiy ochiq holda bo'ladi.

6. Redis: Slow query. Aslida keshlar bazaga beriladigan query'larni vaqtini kamaytirish uchun qilinadi. Ammo yuqoridagi holatdan keyin Redis'dan javob olish ham sekinlashib qoladi. (qolibdi) Bunga yechim sifatida Redis'ni "cluster"larga bo'lish orqali yechim topsa bo'ladi. Default holatda Redis 0 indeksli bazasini ishlatadi. Qo'shimcha unda yana 16 ta (0 bilan birga) baza bor. Bu holatda qolgan bazalarni ham ishlatish bu muammoga yechim bo'ladi.

7. PHP: Slow Request. Endi PHP scriptni o'zini javob berishiga kelsak. PHP intepreted til bo'lganligi uchun, run qilganimizda kod Parsing qismida undagi error'lar tekshiriladi. Agar xatolar chiqmasa, keyin OpCode'ga ya'ni operatsion kodga o'giriladi. Keyin Zend Engine uni haqiqiy komputer tushunadigan tilda run qiladi. Har safar shu jarayon takrorlanadi. "OpCache" orqali esa, Zend Engine qismigacha bo'lgan qismlarni olib tashlasak bo'ladi. Ya'ni bir marta ishga tushirilgan script endi xotiradan olinadi. Yana bunga yordamchi sifatida "JIT (Just in time)"ni qo'llashimiz mumkin. Bu bizga Zend Engine ishini ham olib tashlashga yordam beradi. Bitta run qilingan script birinchi marta hamma bosqichdan o'tadi va keyingi holatdan faqatgina xotiradan ishga tushadi.

8. Server: Too many connection. Tasavvur qiling xonaga 50 ta odam sig'adi. 51-odam kelib qolsa, bittasi bo'shashini kutadi. Natijada kutish ham bir necha soniya vaqt olib qoladi. Bu muammoga esa, PHP'ni asinxron sifatida ishlatish yordam beradi. "PHP Swoole" yordamida usha kutib turgan 51-odamni ham kirg'izsak bo'ladi. Ya'ni 51-requestga ham javob beradi.

Xullas, yuqoridagi amallarni qilish loyihani highload'da ham ishlab berishini ta'minlab beradi. Tajribadan o'tgan narsalari asosida gapirilgan ma'lumotlarni tushunganim bo'yicha yozdim. Rasmlarni quyida topishingiz mumkin: https://t.me/UzGeeksCommunity/483
👍1
Bugungi meetupda aytilgan bilimlarni telegramga qisqacha qilib yozishibdi, baraka topishsin.

Katta yuklamali saytlarni qilishda maslahatlar:

1. Database: Race Condition. Prizlar ro'yxati bor. 5 tadan 3 ta aktiv, 2 tasi tark etgan. Endi navbatdagi ishtirokchiga keyingi prizni qaytarish kerak. Bundan holatlarda bir vaqtda ikkita request birga kelishi oqibatida ikkita ishtirokchiga bitta sovg'a ketib qolishi mumkin. Bu narsani oldini olish uchun esa, "Lock for Update" metodi orqali amalga oshirish, bu muammoga yechim beradi. Bu holatda birinchi request tanlagan priz, o'zgarish uchun bloklanadi. Natijada keyingi request bu prizni tanlamaydi, balki boshqasini tanlaydi.

2. Database: Slow queries. Bazaga ko'p murojat qilish va natijada loyihani sekinlashtirish doimiy muammolardan. Indekslash esa bunga yaxshi yechim bera oladi. Bazadagi ma'lumotlarni indekslash orqali slow query'larni ishlashini yengillashtiramiz.

3. Database: Indexing cons. Indekslashni minus tomonlaridan biri, "insert, update, delete" uchun query'larni sekinlashib qolish. Buni muammo bazani ikkitaga bo'lish orqali yechim beriladi, ya'ni "DB Replication". Bitta asosiy baza - "insert, update, delete" uchun, ikkinchi baza asosiy bazani sinxroni sifatida "select" uchun ishlatilinadi. Ikkinchi baza asosiy bazadan ma'lumotlarni o'ziga sync qilib turadi.

4. Database: Caching. Ba'zi natijasi o'zgarmas query'larni keshlash baza ortiqcha murojaatni oldini oladi. Kesh tizimi baza murojaat qilishdan ko'ra tezroq ishlaydi. Bu holatga "Redis" yaxshi yechim beradi.

5. Redis: Too many connections. Ba'zida Redis'ga murojaatlar ko'payib ketishi natijasida Redis ham javob berolmay qoladi. Bu muammo o'zimda ham uchragandi. Ammo muammo hal qilolmagandim. Bunga yechimlaridan biri "Pooling" qilish. Default holatda Redis berilgan murojaat bitta connection ochadi. Ishini to'xtatgandan keyin u connection yopiladi. Pooling'da esa bir necha connection doimiy ochiq holda bo'ladi.

6. Redis: Slow query. Aslida keshlar bazaga beriladigan query'larni vaqtini kamaytirish uchun qilinadi. Ammo yuqoridagi holatdan keyin Redis'ga bog'lanish ham sekinlashib qoladi. (qolibdi) Bunga yechim sifatida Redis'ni "cluster"larga bo'lish orqali yechim topsa bo'ladi. Default holatda Redis 0 raqamni bazasini ishlatadi. Qo'shimcha unda yana 16 ta (0 bilan birga) baza bor. Bu holat qolgan bazalarni ham ishlatish bu muammoga yechim bo'ladi.

7. PHP: Slow Request. Endi PHP scriptni o'zini javob berishga kelsak. PHP intrepeted til bo'lganligi uchun, run qilganimizda kod Parsing qismida undagi error'lar tekshiriladi. Agar xatolar chiqmasa, keyin OpCode'ga ya'ni operatsion kodga o'giriladi. Keyin Zend Engine uni haqiqiy komputer tushunadigan tilda run qiladi. Har safar shu jarayon takrorlana beradi. "OpCache" orqali esa, Zend Engine qismiga bo'lgan qismlarni olib tashlasak bo'ladi. Ya'ni bir marta ishga tushirilgna script endi xotiradan olinadi. Yana bunga yordamchi sifatida "JIT (Just in time)"ni qo'llashimiz mumkin. Bu bizga Zend Engine ishini ham olib tashlashga yordam beradi. Bitta run qilingan script birinchi marta hamma bosqichdan o'tadi va keyingi holatdan faqatgina xotiradan ishga tushadi.

8. Server: Too many connection. Tasavvur qiling xonaga 50 ta odam sig'adi. 51-odam kelib qolsa, bittasi bo'shashini kutadi. Natijada kutish ham bir necha soniya vaqt olib qoladi. Bu muammoga esa, PHP asinxron sifatida ishlatish yordam beradi. "PHP Swoole" yordamida usha kutib turgan 51-odamni ham kirg'izvuradi. Ya'ni 51-requestga ham javob beradi.

Xullas, yuqoridagi amallarni qilish loyihani highload'da ham ishlab berishini ta'minlab beradi. Tajribadan o'tgan narsalari asosida gapirilgan ma'lumotlarni tushunganim bo'yicha yozdim. Rasmlarni quyida topishingiz mumkin: https://t.me/UzGeeksCommunity/483
👍1