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.