Step 6 (S-44756)

From Stepik Wiki
Jump to: navigation, search

Step on Stepik: https://stepik.org/lesson/14825/step/6

Step 6 (S-44756) 1.png

[00:00 - 00:16] теперь давайте обратимся к принципиально важному для веб серверов моментов а момент внутренняя архитектура такой каким образом происходит обработка сетевых соединений а этот вопрос он определяет возможности веб сервера поэтому важно


[00:16 - 00:36] знать какие есть подходы к обработке сетевых соединениях и какие сервера какие из этих подходов использует а начнем с рассмотрения простейшего сервер а что делает этот сервер ну начало нам понятны неинтересно здесь мы открываем слушай


Step 6 (S-44756) 2.png

[00:36 - 00:55] далее мы входим в бесконечный цикл а устанавливаем сетевое соединение с клиентом а далее читай за этого сетевого соединения до 512 байт отчета при этом мы э


[00:55 - 01:10] надеюсь что все данные к нам сразу попадут а декод преобразует кодировку t 8 это не так критично удаляю если есть в конце перевод строки и мы считаем что к нам пришел


[01:10 - 01:28] это такой простейшей она от протокола http возможно какая то его тестовая версия то есть клиент нам присылают угол а мы пытаемся отдать ему file соответственно использует какую то константу подобным трус так называемой


[01:28 - 01:47] а приклеиваем урлов и пытаемся открыть файл а когда файл открыт мы читаем из него данные кодировал t 8 и отправляем обратно клиент после чего


[01:47 - 02:04] файл закрывается соединение закрывается и мы переходим к обслуживанию следующих клиентов итак это простейшей какой сервер раздающий файл а в чем может быть


[02:04 - 02:23] проблема здесь с точки зрения производительности если не говорить про то что то язык python о неси и тому подобное а с точки зрения производительности проблема здесь в следующем в тот момент когда сервер находится


[02:23 - 02:38] внутри цикла он обрабатывает 1 клиента то есть он получил соединения начал с этим соединением работать до тех пор пока он не выйдет из этого цикла остальные клиенты будут его ждать а


[02:38 - 02:56] в принципе это не так страшно если сервер проводят а внутри цикла мало времени например выполняя какие то вычисления а не ни на что не отвлекаясь так скажем а в таком случае понятно что это время оно должно быть


[02:56 - 03:12] потрачено от этого никуда не уйти и а это терпимо но здесь ситуация хуже а по 2 причинам за счет вызовов рекс рид


[03:12 - 03:29] send all вызовы рекс и sandal они работают в сети то есть фоточтение сокета чтение сети sandal отправка данных вызов read работает с диска все эти вызовы могут занять большое


[03:29 - 03:48] большое количество времени то есть они могут быть очень долго а в этот момент наш сервер не будет делать вообще ничего он не сможет не делать полезную какую то работу не обслуживать других клиентов это называется блокирующий вот вывод а


Step 6 (S-44756) 3.png

[03:48 - 04:03] давайте рассмотрим что происходит при блокирующим вводе выводе подробнее на данной диаграмме а здесь нас показано приложение то есть процесс веб сервера с левая то процессов сервера


[04:03 - 04:21] а справа это образно показано ядро операционной системы какой то момент код программы вот здесь ну здесь приходят новые соединения


[04:21 - 04:38] часть времени выполняется код программы ну интерпретатор питона выполняет инструкции создает там переменные под сокета тому подобное потом происходит вызов то есть чтение из сокета а при системном вызове рекс


[04:38 - 04:56] правление рано или поздно отработали все библиотеки обертке продается операционную систему операционная система также выполняются часть своей работы а отрабатывает протокол tcp в частности


[04:56 - 05:13] и если данных в сокете еще нет то есть мы хотим что то прочитать обсудите данных еще нет а процесс переходит в режим ожидания то есть он а заблокирована операции ввода вывода


[05:13 - 05:29] а операционная система такой процесс то есть такое вчера она его усыпляет он не используется процессов ничего не делает ждет пока завершится операция воду через некоторое время данные появляются в софте


[05:29 - 05:48] опять выполняется код операционной системы вероятно этот tcp стек отрабатывает а данные появились процесс пробуждается и происходит возврат происходит возврата системного вызова далее опять отрабатывают


[05:48 - 06:03] приложение и происходит возврат из функции рф имеется ввиду из питомника функций а причем здесь проблемах


[06:03 - 06:21] здесь проблема в том что вот в этом промежутке не процесс а не операционной системы по факту ничего полезного не делают ну ядро операционной сделанному заниматься другими процессами а вот конкретно этот процесс наш вообще он просто спит он ничего не делать


[06:21 - 06:37] для пользователя проходит вот такой вот такой интервал времени и большую часть из него приложение просто заблокированы и бездействовал а какие варианты


[06:37 - 06:55] борьбы с этим есть а вариантов несколько сейчас мы рассмотрим классические подходы это трейдинг и мультипроцессор трейдинг это создание нескольких трейдов внутри 1 процесса создаются


Step 6 (S-44756) 4.png

[06:55 - 07:13] а несколько треков каждый новый клиент обрабатывается в отдельном треде когда а 1 thread засыпает то есть блокируется на операции ввода вывода остальные продолжают работать


[07:13 - 07:32] а процессинг это похоже схема только вместо процентов используется процесс отдельные процессы операционной системы процессинг также часто называют префорк режимом либо воркер


[07:32 - 07:47] то есть ли у меня очень хороший пример когда распускаются не сможет остаться с есть локер воркер это как раз процессы которые обрабатывают


[07:47 - 08:05] сетевые соединения каждый воркер обрабатывать какой то 1 момент времени а в ровно 1 соединение возможно также комбинированный подход при котором запускается параллельно несколько процессов внутри каждого процесс запускается несколько ответов но в этом не очень много смысла


[08:05 - 08:25] а в чем плюсы и минусы таких подходов ну вообще + в том что все таки решает проблему производительности у нас клиенты уже обслуживается параллельно с отвесом дни со временем можно обслужить больше а прошедшего запрос


[08:25 - 08:44] о некоторой степени от решает проблему давайте разберем режим префорк то есть когда спускается несколько а несколько процессов которые обрабатывают клиентов 1 1 клиента но сетевое соединение 1 процент +


[08:44 - 09:02] что разработка очень проста фактически разработка при при for режиме мало отличается от разработке вообще вот вот на по точным однопроцессорном если


Step 6 (S-44756) 5.png

[09:02 - 09:20] что в исходном в исходном коде это можно наверно записать вот так просто соединения полученные делается вызов fork вот в этом месте


[09:20 - 09:38] и у вас появляется новый процесс а оставшиеся процесс то есть и чем занимается обработкой от этого года а оставшиеся процесс а обрабатывают другие соединения а


[09:38 - 09:53] делать for это очень накладно поэтому зачастую префорк делают а почему он называется префорк его делают до цикла вот в этом месте


[09:53 - 10:09] то есть после того как открыть сервер а делается форк обычном делать несколько раз а появляется множество что вдов и каждый судов работает а вот в этом цикле а это решает проблему


Step 6 (S-44756) 6.png

[10:09 - 10:28] + простота разработки то есть добавили а размножения процессов получили параллельную обработку + можно использовать любой библиотеке но фактически все для тебя я программирую который вообще можете использовать вашей программе они будут хорошо работать


[10:28 - 10:46] основной - это потребление памяти поскольку для каждого для каждого пришедшего клиент на каждое сетевое соединение нас порождаются целый процесс операционной системе а он может свободно занимать 10 20 100 мегабайт зависимости от того


[10:46 - 11:03] что находится внутри вашего а вас будет проблема с потреблением памяти при большом количестве конкурирующих клиент а если сервер отрабатывает быстро


[11:03 - 11:22] то есть запросы время отработка на запрос очень небольшое это в принципе не так страшно потому что у вас будет использоваться повторно но если соединение долгоживущий то есть например а 1 клиент загружает файлы в течение 10 минут


[11:22 - 11:38] то этот клиент потребляет ровно для уборки 1000 таких клиент запустят тысяч воркеров что скорее всего сломает конкретно сервер он перестает нормально функционировать


[11:38 - 11:54] а трейдинг по сравнению с при форком более экономичен по памяти то есть потому что вместо отдельных процессов нас порождаются потоке


[11:54 - 12:10] потоке считаются более легковесное структуры но это также зависит от операционной системе системы в линуксе процессы и потоки они довольно близки параллелизации друг другу а основное отличие


[12:10 - 12:28] мультипоточный система в том что у процессов и потоков общая память а не разделена памяти процессов память разделена у потока в память вообще это требует крайне аккуратной работы с общей памятью


[12:28 - 12:44] то есть все проблема с мьютексами блокировками они возникают в полной мере и как следствие использования трейдинг то есть много процента многопоточная система накладывает ограничения на использование библиотек


[12:44 - 12:59] тут все просто нужно использовать и в библиотеке которые хорошо работают много поточном режиме а ну это можно сказать ни про все библиотеки некоторые библиотеки по точно так же он не работает


[12:59 - 13:16] так или иначе процессинг решает задачу параллельной обработки клиентов но к сожалению уводят некоторое ограничение по количеству а параллельно параллельно удерживаемых соединений обрабатываемых клиент


[13:16 - 13:18] в 1 очередь это ограничение по памяти