ВУЗ: Не указан

Категория: Не указан

Дисциплина: Не указана

Добавлен: 12.01.2024

Просмотров: 309

Скачиваний: 1

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
JavaScript-тің негізгі кемшіліктерінің бірі-ғаламдық Объект. Барлық жоғарғы деңгейдегі айнымалылар Ғаламдық объектіге "құлайды" және бір уақытта бірнеше модульдерді қолданған кезде бұл басқарылмайтын хаосқа әкелуі мүмкін. Веб-қосымшалар әдетте әртүрлі ұйымдар жасаған көптеген нысандардан тұратындықтан, Node үшін бағдарламалау бір-біріне қайшы келетін жаһандық Нысандар басып алған мина алаңында жүруге ұқсайды деп қорқуы мүмкін. Алайда олай емес. Шын мәнінде, түйін CommonJS модульдерін ұйымдастыру жүйесін пайдаланады, яғни кейбір модульдің жергілікті айнымалылары Ғаламдық болып көрінсе де, онда Жергілікті болады. Модульдер арасындағы мұндай нақты айырмашылық жаһандық объект мәселесін шешеді.Серверде және клиентте бірыңғай бағдарламалау тілін қолдану веб - әзірлеушілердің арманы болды. Бұл арманның тамыры Java-ның қалыптасу кезеңінде, апплеттер Java-да жазылған серверлік қосымшаларға клиенттік интерфейс ретінде ұсынылған кезде, A JavaScript бастапқыда апплеттермен өзара әрекеттесудің жеңілдетілген сценарий тілі ретінде көрінді. Бірақ бұл жолда бірдеңе болған жоқ, нәтижесінде Java емес, A JavaScript браузер клиентінің негізгі тіліне айналды. Түйіннің пайда болуымен Біз JavaScript - ті клиент пен сервердің веб - жағында қолданылатын тілге айналдыру арманын жүзеге асыра аламыз.Бір тілдің бірнеше ықтимал артықшылықтары бар:бірдей бағдарламашылар қосымшаның екі жағында да жұмыс істей алады;кодты серверден клиентке және кері тасымалдау оңайырақ;клиент пен серверге ортақ деректер пішімі (JSON);Жалпы Бағдарламалық құрал;клиент пен серверге ортақ тестілеу және сапаны бақылау құралдары;веб-қосымшаның екі жағында да жалпы көрініс үлгілерін қолдануға болады;клиент пен серверде жұмыс істейтін топтар арасындағы ортақ байланыс тілі.бұл (және басқа) ізгіліктерді жүзеге асыруды жеңілдетеді, берік платформа мен белсенді әзірлеушілер қауымдастығын ұсынады.Архитектура: оқиғалар басқарылатын ағындар немесе асинхронды енгізу/шығару.Асинхронды оқиғаға бағытталған архитектураның арқасында түйін осындай жоғары өнімділікті көрсетеді деп айтылады. Сонымен, бұған тек V8 JavaScript қозғалтқышының жылдамдығын қосу керек. Дәстүрлі қолданбалы сервер үлгісінде параллелизм блоктау енгізу/шығару және бірнеше ағындарды пайдалану арқылы қамтамасыз етіледі. Әрбір ағын келесі сұрауды өңдеуді бастамас бұрын Енгізу/шығару аяқталғанша күтуі керек.Түйінде мәтінмәндік ауысу немесе енгізу/шығару күтусіз бір орындалу ағыны бар. Кез келген Енгізу/шығару сұрауында өңдеу

функциялары орнатылады, олар кейіннен деректер қол жетімді болған кезде немесе басқа маңызды нәрсе болған кезде оқиғаларды өңдеу циклынан шақырылады. Оқиғаларды өңдеу циклінің моделі және оқиғаларды өңдеуші-бұл кең таралған нәрсе, браузерде JavaScript-те жазылған сценарийлер осылай орындалады. Бағдарлама келесі кезекте тұрған тапсырманы шақыру үшін өңдеу циклін басқаруды тез қайтарады деп күтілуде. Біздің ойларымызды дұрыс бағытқа бұру үшін Райан Даль ("Cincode Node" презентациясында) мұндай кодты орындау кезінде не болатынын сұрайды:

result = query('SELECT * from db);

Әрине, бағдарлама осы сәтте дерекқорға кіру қабаты нәтижені есептейтін және деректерді қайтаратын дерекқорға сұрау жіберген кезде тоқтатылады. Сұраныстың күрделілігіне байланысты оны орындау айтарлықтай уақытты алуы мүмкін. Бұл жаман, өйткені ағын бос тұрған кезде басқа сұрау келуі мүмкін, ал егер барлық ағындар бос болмаса, сұрау жай ғана жойылады. Бұл қандай да бір жолмен ысырап. Мәтінмәндік ауысу тегін емес; ағындар неғұрлым көп жұмыс істесе, процессор олардың күйін сақтауға және қалпына келтіруге көп уақыт жұмсайды. Сонымен қатар, әр ағынның стегі жадта орын алады. Тек асинхронды оқиғаға бағытталған енгізу / шығару арқылы Node осы үстеме шығындардың көп бөлігін жояды, бұл өте аз.

Көбінесе ағындар арқылы параллелизмді жүзеге асыру туралы әңгіме "қымбат және қателіктерге толы", "Java-дағы сенімсіз синхрондау примитивтері" немесе "параллель бағдарламаларды жобалау қиын болуы мүмкін және қателер алынып тасталмайды" (сөз тіркестері іздеу жүйесі берген нәтижелерден алынған) сияқты ескертулермен бірге жүреді. Бұл күрделіліктің себебі ортақ айнымалыларға қол жеткізу және ағындар арасындағы құлыптар мен жарыстардың алдын алудың әртүрлі стратегиялары болып табылады. "Java-дағы синхрондау примитивтері" - бұл стратегияның бір мысалы, және көптеген бағдарламашылар оларды пайдалану қиын деп санайды. Көп ағынды параллелизмге тән күрделілікті жасыру үшін java типті рамалар жасалады.util.concurrent, бірақ бәрібір кейбіреулер күрделілікті жасыруға тырысу мәселені жеңілдетпейді деп санайды.параллелизмге басқаша қарауға шақырады. Оқиғаларды өңдеу циклінен кері байланыс-түсіну үшін де, іске асыру үшін де параллелизмнің әлдеқайда қарапайым моделі.

Асинхронды енгізу/шығару қажеттілігін түсіндіру үшін Райан Даль объектілерге қол жеткізудің салыстырмалы уақытын еске салады. Жадтағы объектілерге қол жеткізу (наносекундтық тәртіп) дискідегі немесе желідегі объектілерге қарағанда жылдамырақ (миллисекундтар немесе секундтар). Сыртқы нысандарға кіру уақыты сағат циклдерінің сансыз санымен өлшенеді және егер клиент парақтың жүктелуін екі секунд күтпестен шолғыш терезесіне қарап, басқа жерге барудан шаршаса, мәңгілікке айналуы мүмкін.


Түйінде жоғарыда аталған сұрау келесідей жазылуы керек еді:query( SELECT * from db', function (result) {// нәтижемен қандай да бір операциялар жасаңыз}):Айырмашылық мынада, енді сұрау нәтижесі функцияның мәні ретінде қайтарылмайды, бірақ кейінірек шақырылатын кері қоңырау функциясына беріледі. Осылайша, оқиғаларды өңдеу цикліне оралу бірден дерлік орын алады және сервер басқа сұрауларға қызмет көрсетуге ауыса алады. Осындай сұраулардың бірі дерекқорға жіберілген сұрауға жауап болады, содан кейін кері қоңырау функциясы шақырылады. Оқиғаларды өңдеу цикліне жылдам оралудың бұл моделі сервер ресурстарын пайдалану дәрежесін арттырады. Бұл сервер иесі үшін өте жақсы, бірақ парақтың мазмұны тезірек ашылатын пайдаланушы одан да көп пайда табады.Бұл күндері веб-беттер ондаған көздерден деректерді көбірек жинайды. Әркім сұрау жіберіп, оған жауап күтуі керек. Асинхронды сұраулар осы операцияларды қатар орындауға мүмкіндік береді-барлық сұрауларды бірден жіберіңіз, әрқайсысына жеке қоңырау шалыңыз және жауап күтпестен оқиғаны өңдеу цикліне оралыңыз. Жауап келгенде, оған сәйкес функция шақырылады. Параллелизацияның арқасында деректерді сұраулар бірінен соң бірі синхронды түрде орындалғанға қарағанда тезірек жинауға болады. Браузердің екінші жағындағы пайдаланушы бақытты, өйткені бет тезірек жүктеледі.2.3.1 Процессордың өнімділігі және қолданылуыNode платформасы өзінің тартымдылығымен ішінара өткізу қабілеттілігіне қарыздар (секундына қызмет көрсетілетін сұраныстар саны). Apache және Node сияқты ұқсас бағдарламалардың салыстырмалы сынақтары өнімділіктің керемет пайдасын көрсетеді.Танымал эталондардың бірі-келесі қарапайым NTTR сервері, ол тек жадтан оқылатын "HelloWorld" хабарламасын қайтарады:var http = require( http');.createServer(function (req, res) {.writeHead(200, {'Content-Type': text/plain'});.end('Hello World\n');}).listen(8124, "127.0.0.1");.log( Server running at http://127.0.0.1:8124/');Бұл Node платформасында құруға болатын ең қарапайым веб-серверлердің бірі. Http нысаны HTTP протоколын және оның http әдісін инкапсуляциялайды.createServer әдіспен берілген портты тыңдайтын толық веб-сервер жасайды .listen. Әрбір сұрау (кез келген түрдегі кез келген URL мекенжайына - кем дегенде GET, кем дегенде PUT) аталған функцияны шақыруға әкеледі. Сервер өте қарапайым және өте аз "салмақ". Бұл жағдайда URL мекенжайына қарамастан, Мәтін/жазық түріндегі "HelloWorld" жолы қайтарылады.Осы минимализмнің арқасында бұл қолданба максималды өткізу қабілеттілігін көрсетуі керек. Сондықтан көптеген жарияланған зерттеулерде эталондық сынақтардың тізімі осы қарапайым NTTR серверінен басталады.
Райан Даль қарапайым тесттің мысалын келтірді (http://nodejs.org/cinco_de_node.pdf), ол 1 Мб екілік деректерді қайтарады; ондағы түйін 822 сұрау/с өткізу қабілеттілігін көрсетті, a nginx - 708 сұрау/с.Дал сонымен қатар nginx 4 Мбайт жадында, aNode - 64 Мбайт жадында ең жоғары өнімділікке қол жеткізді деп жауап береді.Дастин Маккуэй (Dustin McQuay) (http://www.synchrosinteractive.com/blog/9-nodejs/22-nodejs-has-a-bright-future) Node және PHP/Apache платформаларында өте ұқсас екі бағдарламаны көрсетті:PHP/Apache 3187 запросов/с;.js 5569 запросов/с.RingoJS авторы Ханнес Уолтер (Hannes Wallnflfer) өз блогында салыстырмалы тесттер негізінде маңызды шешімдер қабылдаудан сақтандыратын ескерту жазды (http://hns.github.com/2010/09/21/benchmark.htinl), содан кейін Ringojs-ті түйінмен салыстыруға көшеді. RingoJS-Java үшін Rhino JavaScript қозғалтқышына негізделген қолданба сервері. Кейбір сценарийлерде RingoJS және Node өнімділігі өте жақын. Зерттеулер көрсеткендей, буферлерге немесе жолдарға жадты тез бөлуді қажет ететін қосымшаларда түйін RingoJS-ке қарағанда нашар жұмыс істейді. Келесі жазбада (http://hns.github.com/2010/09/29/benchmark2.html) Ханнес JSON жолын талдаудың әдеттегі тапсырмасын сынап көрді және RingoJS әлдеқайда жылдам жұмыс істейтінін анықтады.Микито Такада (Микито Такада) блогта Node және Django өнімділігінің салыстырмалы тестілеуі туралы өзі жазған "48 сағаттық Хакатон" қосымшасының мысалында айтты(http://blog.mixu.net/2011/01/17/performance-benchmarking-the-node-js-backend-of-our-48h-product-wehearvoices-net/). Node үшін оңтайландырылмаған нұсқа сәл баяу болды (жауап беру уақыты бойынша), бірақ қарапайым оңтайландыру (MySQL қосылым пулын қосу, кэштеу және т. б.) айтарлықтай нәтиже берді Django-ны оңай басып озу арқылы өнімділікті арттыру. Соңғы график жоғарыда аталған "HelloWorld" серверіне жақын секундына сұраныс санының мәнін көрсетеді.Түйіннің әлеуетті мүмкіндіктерін толық ашу үшін басқаруды оқиғаларды өңдеу цикліне жылдам қайтару өте маңызды. Егер кері байланыс өңдегіші "тым ұзақ" орындалса,онда түйін ойластырылған өте жылдам сервер болуды тоқтатады. Түйін жобасы туралы алғашқы мақалалардың бірінде (http://four.livejournal.com/963421.html) Райан Даль оқиға өңдеушілері 5 мс-ден аспауы керек деген талапты талқылады. Осы мақалада айтылған идеялардың көпшілігі ешқашан орындалмады, бірақ Алекс Пейн (AlexPayne) бұл туралы өте қызықты мақала жазды (http://а13х.net/2010/07/27/node. HTML), онда "кіші масштабтау" мен "үлкен масштабтау"арасындағы айырмашылық жасалады.Шағын веб-қосымшалар жағдайында ("кішігірім масштабтау") Node-де іске асыру және 'R' (Perl, RNR, Python және т.б.) тілдерінде емес, өнімділікте жеңіске жетуі керек. JavaScript-бұл қуатты тіл, ал қазіргі заманғы жылдам виртуалды машинасы бар түйін ортасы интерпретацияланған РНР типті тілдермен салыстырғанда өнімділік пен параллелизмді ұйымдастыруда артықшылықтарға ие.
Пейн әрі қарай "үлкен масштабтау", яғни кәсіпорын деңгейіндегі қосымшаларды құру әрқашан қиын және қиын болады дейді. Беттерді жүктеудің қажетті жылдамдығын қамтамасыз ете отырып, бүкіл әлем бойынша көптеген пайдаланушыларға қызмет көрсету үшін жүйеге әдетте жүктеме теңгергіштерін, кэштеу серверлерін, аумақтық қашықтықта орналасқан көптеген резервтік машиналарды қосу қажет. Сондықтан даму платформасы жалпы жүйе сияқты маңызды емес шығар.Ірі өндіріс орталарында ұзақ мерзімді орналастырудың мысалын көрмейінше, біз Node платформасының қаншалықты жақсы екенін білмейміз.2.3.2Серверлерді пайдалану, шығындарды үнемдеу және тұрақты ИнтернетМаксималды тиімділік үшін күрестің мәні (секундына өңделетін сұраныстардың көбеюі) тек жақсы орындалған техникалық жұмыстан ләззат алу ғана емес. Сондай-ақ бизнес пен қоршаған орта тұрғысынан нақты артықшылықтар бар. Түйіннің секундына көбірек сұраныстарды өңдеу мүмкіндігі аз серверлерді сатып алуға болатындығын білдіреді. Яғни, аз қаражатпен көбірек жасаңыз.Шамамен айтқанда, серверлер неғұрлым көп болса, шығындар соғұрлым жоғары болады және қоршаған ортаға әсер соғұрлым көп болады және керісінше. Веб-сервер инфрақұрылымының шығындары мен қоршаған ортаға зиянын азайту туралы бүкіл ғылым бар және бұл өрескел ұсыныс барлық мәліметтерді қамти алмайды. Бірақ жалпы мақсат айқын - серверлерді азайту, шығындарды азайту және қоршаған ортаға келтірілген зиянды азайту.Intel корпорациясы жариялаған "increasing Data Center Efficiency with Server power Measurements" мақаласында (http://download.intel.com/it/pdf/Server_Power_Measurement_final.PDF) деректер орталықтарының тиімділігі мен құнын бағалау әдістемесі келтірілген. Ғимараттың құрылысы, салқындату жүйесі және есептеу жүйесінің жобасы сияқты көптеген факторларды ескеру қажет. Оларды тиімді іске асыру (DCD тиімділігі, DCD тығыздығы және DCD тығыздығы) қоршаған ортаға шығындар мен зиянды азайтуы мүмкін. Бірақ мұның бәрін көптеген серверлерді сатып алуға мәжбүр ететін тиімсіз бағдарламалық жасақтама жүйесін қолдану арқылы жоққа шығаруға болады. Керісінше, тиімді бағдарламалық қамтамасыз ету жүйесі DTC тиімді ұйымдастырудың артықшылықтарын күшейтуге мүмкіндік береді.2.4 NODE СипаттамаларыТүйінмен жұмыс жасамас бұрын, даму ортасын зерттеу керек.ол POSIX стандартына сәйкес келетін операциялық жүйелерде жақсы жұмыс істейді. Бұл әртүрлі UNIX клондары (Solaris және т.б.), сондай-ақ UNIX тәрізді жүйелер (Linux, Mac OS X және т. б.). Шын мәнінде, түйінге енгізілген көптеген функциялар POSIX-те сипатталған жүйелік қоңырауларға тікелей интерфейстер болып табылады.