67.Асинхронды

өп жұмыс істеуге қарағанда жалпы моделі азырақ, бірақ мүмкіндіктері кем емес. Асинхронды модель оқиға циклына негізделген. Оқиға болған кезде (сұраныс келді, файл оқылды, мәліметтер базасынан жауап келді), ол кезектің соңына қойылады. Осы кезекті өңдейтін ағын оқиғаны кезектің басында алады және сол оқиғаға байланысты кодты орындайды. Кезек бос болғанша, процессор жұмыспен айналысады. Node.js осылай жұмыс істейді. Бізде іс-шаралар кезегін өңдейтін жалғыз ағын бар (кластер модулімен - бірнеше ағын болады). Барлық дерлік операциялар блокталмайды. Блокаторлар да қол жетімді, бірақ оларды қолдану өте қиын. Неге екенін келесіде көресіз. 1 + 2 + 1ms сұранысымен бірдей мысалды алайық: сұранымның келуіне байланысты оқиға хабарламалар кезегінен алынады. Біз сұранысты өңдейміз, 1мм жұмсаймыз. Әрі қарай, мәліметтер қорына блоктан тыс асинхронды сұраныс жасалып, басқару дереу беріледі. Біз кезекті оқиғаны кезектен алып, орындай аламыз. Мысалы, біз тағы 1 сұраныс қабылдаймыз, оны өңдейміз, дерекқорға сұраныс жібереміз, басқаруды қайтарамыз және тағы бір рет қайталаймыз. Содан кейін ДБ жауабы бірінші сұранысқа келеді. Онымен байланысты оқиға кезекке қойылады. Егер кезекте ештеңе болмаса, ол дереу орындалады, мәліметтер беріледі және клиентке қайтарылады. Егер кезекте бірдеңе болса, басқа оқиғалардың өңделуін күтуге тура келеді. Әдетте, бір сұранысты өңдеу жылдамдығы көп ағынды жүйенің өңдеу жылдамдығымен және бұғаттау операцияларымен салыстырылатын болады. Ең нашар жағдайда, басқа оқиғалардың өңделуін күтуге уақыт қажет болады және сұрау баяу өңделеді. Бірақ сол сәтте, бұғаттау операциялары бар жүйе жауап алу үшін жай 2мм күте тұрса, блоктамайтын операциялары бар жүйе тағы 2 сұраныстың тағы 2 бөлігін орындай алды! Әрбір сұраныс жалпы алғанда сәл баяулауы мүмкін, бірақ біз уақыт бірлігінде көптеген сұраныстарды өңдей аламыз. Жалпы өнімділік жоғары болады. Процессор әрдайым пайдалы жұмыстармен айналысады. Сонымен қатар, кезекті өңдеуге және оқиғадан оқиғаға ауысуға көп бұрандалы жүйеде жіптер арасында ауысуға қарағанда әлдеқайда аз уақыт кетеді. Сондықтан, блоктаусыз операциялары бар асинхронды жүйелерде жүйеде өзектер санынан артық ағындар болмауы керек. Node.js бастапқыда тек бір ағынды режимде жұмыс істеді және процессорды толығымен пайдалану үшін бірнеше сервер көшірмелерін қолмен көтеріп, олардың арасындағы жүктемені бөлуге тура келді, мысалы, nginx. Енді бірнеше ядролармен жұмыс істеуге арналған кластер модулі пайда болды (осы жазу кезінде ол әлі де тәжірибелік мәртебеге ие). Осы жерде екі жүйенің негізгі айырмашылығы айқын болады.

Синхронды

Бұл модель бәріне белгілі. Біздің қосымшамыз бірнеше ағындарды (бассейн) жасайды, олардың әрқайсысына тапсырма мен деректерді өңдеуге жібереді. Тапсырмалар параллель орындалады. Егер ағындар деректермен бөліспейтін болса, онда бізде синхрондаудың үстеме ақысы болмайды, бұл жұмысты жеткілікті жылдам етеді. Жұмыс аяқталғаннан кейін жіп өлтірілмейді, бірақ келесі тапсырманы күтіп, бассейнде жатыр. Бұл жіптерді құру және жою үстеме ақысын жояды. PHP бар веб-сервер дәл осындай жүйеде жұмыс істейді. Әр сценарий өз ағынымен орындалады. Бір ағын бір сұранысты өңдейді. Бізде жіптер саны өте көп, баяу сұраныстар ұзақ уақыт ағынды алады, жылдамдары дереу өңделеді, жіпті басқа жұмыстарға босатады. Бұл баяу сұраулардың барлық CPU уақытын алуына жол бермейді, сондықтан тез сұраулар іліп қалады. Бірақ мұндай жүйенің белгілі шектеулері бар. Бізге баяу сұраныстардың көп мөлшері келіп түскен кезде жағдай туындауы мүмкін, мысалы, мәліметтер базасымен немесе файлдық жүйемен жұмыс. Мұндай сұраныстар барлық ағындарды алады, сондықтан басқа сұраныстарды орындау мүмкін болмайды. Сұранысты орындау үшін тек 1 мс уақыт қажет болса да, ол уақытында өңделмейді. Мұны ағындардың санын көбейту арқылы шешуге болады, сонда олар баяу сұраныстардың жеткілікті мөлшерін орындай алады. Өкінішке орай, ағындар ОЖ-мен өңделеді және оған процессордың уақыты да бөлінеді. Сондықтан, біз қанша ағын жасасақ, оларды өңдеуге арналған шығындар соғұрлым көп болады және әр жіпке CPU уақыты аз бөлінеді. Жағдайды PHP өзі қиындатады - мәліметтер қорымен, файлдық жүйемен жұмыс жасауды бұғаттау, енгізу-шығару сонымен бірге процессордың уақытын жоғалтады, қазіргі уақытта ешқандай пайдалы жұмыс істемейді. Мұнда біз бұғаттау операцияларының ерекшеліктеріне толығырақ тоқталамыз. Осы жағдайды елестетіп көрейік: бізде бірнеше ағым бар. Әрқайсысы сұраныстың өзін өңдеудің 1 мс, мәліметтер базасына деректерге қол жеткізу және қабылдау үшін 2 мс және алынған деректерді көрсетуден тұратын сұраныстарды өңдейді. Осылайша, біз әр сұраныс үшін 4 мс жұмсаймыз. Деректер базасына сұраныстар жіберген кезде ағын жауап күте бастайды. Деректер қайтарылмайынша, ағын ешқандай жұмыс істемейді. Бұл сұранысқа 4 мс ішінде бос уақыттың 2 мысы! Ия, мәліметтер базасынан мәліметтер алмай, біз парақ бере алмаймыз. Біз күтуіміз керек. Бірақ бұл жағдайда біз жұмыс істемейтін процессордың 50% аламыз! Сонымен қатар, сіз әр ағынға процессор уақытын бөлуге қосымша ОЖ шығындарын түсіре аласыз. Ағындар қаншалықты көп болса, соғұрлым көп шығындар болады. Нәтижесінде бізде көптеген бос уақыттар болады. Бұл уақыт мәліметтер базасына және файлдық жүйеге сұраныстардың ұзақтығына тікелей байланысты. Процессорды толығымен жүктеуге мүмкіндік беретін ең жақсы шешім пайдалы