Веб-сервер на JavaScript с использованием теории массового обслуживани
25 000 руб. за проект
В работе рассматривается проблема отзывчивости веб-приложений с позиций теоретической информатики и математики. В моем случае теоретической основой работы является теория систем массового обслуживания.
Кое-какой сервер уже есть, но нужно еще тестировать и как-то теорию массового обслуживания прикрутить.
Начать нужно с простого сервера. Можно обойтись и без express, но у меня с ним.
Что с ним, что без него мы получаем сервер, обрабатывающий запрос асинхронно в одном потоке. Его нужно нагрузить запросами и померить время обработки запроса в зависимости от их числа и объема запроса/ответа.
Далее, нужно написать вариант с обработкой запроса в отдельном потоке выполнения и измерить времена обработки запросов при разных нагрузках.
Надо будет выдать обоснованную рекомендацию: в каких случаях надо выбирать асинхронную обработку запроса в одном потоке, в каких — в отдельном потоке.
Варианты ситуаций:
Много маленьких запросов — мало запросов, но больших по объему данных.
То же, но с вычислениями на сервере
То же, но с обращением к базе данных
(немного теории)
JS по умолчанию выполняется в одном потоке.
Для нескольких потоков можно и нужно использовать worker’ы.
Синхронную обработку запроса надо будет писать специально, если такая необходимость возникнет.
Существует три основных модели
обработки запроса клиента к серверу:
- Синхронная в одном потоке выполнения (на практике используется редко, встречается в веб-интерфейсах устройств)
- Асинхронная в одном потоке выполнения (по умолчанию предоставляется node.js)
- Асинхронная с обработкой каждого запроса в отдельном потоке выполнения. Тут тоже возможны 2 варианта, чем именно будет представлен отдельный поток выполнения: легковесным процессом (thread) или полновесным (process).
Браузер может выполнять запросы GET и POST синхронно или асинхронно. Одновременно браузер может выполнять ограниченное число запросов (как правило, 4). JS в браузере выполняется всегда асинхронно в одном потоке. Если выполнение запроса или обработка его результатов требует объемных вычислений на стороне клиента, то имеется возможность выделить их в отдельный поток выполнения, используя worker’ы. (Вообще, абстракцию worker’a следует разобрать с точки зрения целесообразности их применения в различных ситуациях).
Декартово произведение перечисленных вариантов дает множество вариантов, которые надо рассмотреть и сравнить.
Для синхронной обработки запроса это будет простая сумма задержек. А вот уже, например, для рендеринга страницы, данные для которой возвращаются в ответ на несколько асинхронных запросов и обрабатываются скриптом на странице, все может быть гораздо сложнее.
Дальше и глубже — теория систем массового обслуживания.
Нужно нарисовать диаграммы для всех моделей, которые рассмотрели до этого. По ним - формулы общего времени рендеринга страницы.
Кое-какой сервер уже есть, но нужно еще тестировать и как-то теорию массового обслуживания прикрутить.
Начать нужно с простого сервера. Можно обойтись и без express, но у меня с ним.
Что с ним, что без него мы получаем сервер, обрабатывающий запрос асинхронно в одном потоке. Его нужно нагрузить запросами и померить время обработки запроса в зависимости от их числа и объема запроса/ответа.
Далее, нужно написать вариант с обработкой запроса в отдельном потоке выполнения и измерить времена обработки запросов при разных нагрузках.
Надо будет выдать обоснованную рекомендацию: в каких случаях надо выбирать асинхронную обработку запроса в одном потоке, в каких — в отдельном потоке.
Варианты ситуаций:
Много маленьких запросов — мало запросов, но больших по объему данных.
То же, но с вычислениями на сервере
То же, но с обращением к базе данных
(немного теории)
JS по умолчанию выполняется в одном потоке.
Для нескольких потоков можно и нужно использовать worker’ы.
Синхронную обработку запроса надо будет писать специально, если такая необходимость возникнет.
Существует три основных модели
обработки запроса клиента к серверу:
- Синхронная в одном потоке выполнения (на практике используется редко, встречается в веб-интерфейсах устройств)
- Асинхронная в одном потоке выполнения (по умолчанию предоставляется node.js)
- Асинхронная с обработкой каждого запроса в отдельном потоке выполнения. Тут тоже возможны 2 варианта, чем именно будет представлен отдельный поток выполнения: легковесным процессом (thread) или полновесным (process).
Браузер может выполнять запросы GET и POST синхронно или асинхронно. Одновременно браузер может выполнять ограниченное число запросов (как правило, 4). JS в браузере выполняется всегда асинхронно в одном потоке. Если выполнение запроса или обработка его результатов требует объемных вычислений на стороне клиента, то имеется возможность выделить их в отдельный поток выполнения, используя worker’ы. (Вообще, абстракцию worker’a следует разобрать с точки зрения целесообразности их применения в различных ситуациях).
Декартово произведение перечисленных вариантов дает множество вариантов, которые надо рассмотреть и сравнить.
Для синхронной обработки запроса это будет простая сумма задержек. А вот уже, например, для рендеринга страницы, данные для которой возвращаются в ответ на несколько асинхронных запросов и обрабатываются скриптом на странице, все может быть гораздо сложнее.
Дальше и глубже — теория систем массового обслуживания.
Нужно нарисовать диаграммы для всех моделей, которые рассмотрели до этого. По ним - формулы общего времени рендеринга страницы.
В заказе есть исполнитель
При переводе заказа из архивного в актуальный, текущий исполнитель будет снят с задачи.
Выберите тип сделки
С безопасной сделкой вы всегда сможете вернуть средства, если что-то пойдет не так. С простой сделкой вы самостоятельно договариваетесь с исполнителем об оплате и берете на себя решение конфликтов.