Параллельность в веб-приложениях

Question

В последнее время почти все провайдеры платформ уделяют большое внимание созданию новых инструментов / языковых конструкций для лучшего параллелизма. И это также одна из причин того, что многие идеи из функциональных языков программирования интегрируются в основные языки, такие как C #, Java и т. Д.

Несмотря на то, что они имеют большой смысл сегодня, особенно с введением многоядерных процессоров, я хотел знать, как их можно использовать, особенно в области веб-приложений. В веб-приложениях большая часть параллелизма управляется самим веб-сервером, и очень редко я вижу многопоточность, реализованную на веб-страницах. AJAX также включил парадигму «странички», чтобы помочь в дальнейшем.

Веб-приложения обычно состоят из быстрого получения результатов, и до сих пор мы использовали много тактик, таких как кэширование, резервирование и т. Д. Для достижения этой цели. Если что-то требовало значительных вычислительных ресурсов, это должно происходить в автономном режиме (и клиенты могли запросить результаты позже или могли быть реализованы обратные вызовы).

Параллельный тип уже реализован во многих библиотеках / инфраструктурах, которые обычно используются в веб-приложениях, таких как базы данных, и множественные загрузки в таких структурах, как memcached.

Я не смог найти много примеров сценариев, в которых последние платформы и библиотеки параллелизма могут использоваться в контексте веб-приложений. Поэтому я хотел бы знать, имеют ли они смысл в веб-домене.

Answer 1

Поскольку веб-приложения по умолчанию являются параллельными, вы с меньшей вероятностью будете использовать новые механизмы параллелизма (такие как TPL или PLINQ для .NET) в веб-приложениях. Обычно вы ничего не получите на веб-сервере с высокой нагрузкой (вы могли бы ускорить один запрос, замедляя другой запрос). Однако, когда у вас есть выделенный веб-сервер, который не обслуживает большую часть циклов ЦП (при наличии нескольких ядер), эти методы могут оказаться полезными.

[Обновление:] Просто прочитайте новую статью о Параллельном программировании с .NET blog . Вот две интересные цитаты:

В большинстве случаев, и в частности для Веб-приложения с интенсивным использованием, это вероятно, не нужно вводить дополнительный параллелизм, так как добавление большего рабочие элементы приведут только к конкуренция за процессорное время и в конечном итоге уменьшить пропускную способность запроса.

и

Веб-приложения, которые необходимо выполнить дорогие вычисления еще могут выиграть от параллелизма, если задержка индивидуального запроса важнее, чем общий запрос пропускная способность.

Я думаю, что это отвечает на ваш вопрос.

Answer 2

Строгое представление о том, что все синхронно и согласованно, недостаточно хорошо масштабируется. Тогда возникает тенденция иметь больше вещей асинхронных и принимать возможную согласованность . Это также отражается в том, как спроектированы языки и структура.

Вдохновение черпается из области функционал , потому что она хорошо вписывается в этот режим вычислений. Функциональное программирование помогает рассуждать о , что выполнить, а не как и при .

На самом деле дополняет традиционный механизм борьбы с параллелизмом.

Я не смог найти много образцов сценарии, в которых последние платформы и библиотеки для параллелизма может использоваться в контексте веб-приложений. Так Я хотел бы знать, если они делают много смысла в веб-домене.

Это зависит от того, что вы имеете в виду. Вам не нужно использовать низкоуровневую конструкцию, такую ​​как в java.util.concurrent. Но асинхронность поддерживается лучше и лучше по стекам фреймворка. Например, Servlet 3.0 вводит асинхронный веб-запрос, чтобы упростить разработку приложений AJAX . Как следствие, EJB 3.1 имеет асинхронный вызов метода для интеграции с асинхронным веб-уровнем. Внизу мы имеем низкоуровневую абстракцию функции (или делегата, замыкания), которая абстрагирует само вычисление, и информацию, необходимую для вычисления (его контекст). Я думаю, то же самое верно для .NET.

Функциональное программирование, не связанное с традиционным веб-приложением, а скорее с сетью как «облаком», помогает с распределенными вычислениями по CPU и узлам . Хорошо известный пример - map / lower и подобные, которые нацелены на обработку большого набора данных.

Все это соответствует друг другу, и мы видим веб-приложение, которое остается отзывчивым, в то время как большой набор данных обрабатывается асинхронно.

Но нет, вам не понадобится все это для традиционного веб-приложения!

Answer 3

Да, на высокопроизводительном сервере и в длительных задачах

Извлечение Асинхронные контроллеры in ASP.Net MVC

Answer 4

Придерживаться вашего вопроса ...

Если что-то требовало значительных вычислительных ресурсов, это должно происходить в автономном режиме (и клиенты могли запросить результаты позже или могли быть реализованы обратные вызовы).

Это именно та часть, где иногда требуется фоновый параллелизм (на сервере), и предпочтительнее, чем порожденный Ajax веб-поток:

• Фоновое вычисление может быть слишком длинным для сеанса , поэтому вы не можете использовать веб-нить (вы бы приостановили сеанс).
• Для фоновых вычислений может не потребоваться много информации, которая в противном случае необходима для этого пользователя, может потребоваться гораздо меньше контекста, что хорошо для освобождения памяти .
• Ночные пакеты могут обрабатывать огромные таблицы базы данных кусками и требовать монопольного доступа к этим таблицам. Многопоточность может потребоваться для того, чтобы время вычислений не превышало допустимую продолжительность (позволяя другим задачам следовать или пользователям получать доступ к результатам после приемлемой продолжительности). Нередко останавливать взаимодействия с пользователем во время ночного периода времени и обрабатывать некоторые пакеты, и освоение параллельных взаимодействий в это время может быть критическим.

Answer 5

Насколько я понимаю, вопрос возникает из-за усложнения двух различных значений концепции параллелизм : одновременное обслуживание веб-сайта для пользовательских запросов (макроуровень) по сравнению с одновременным выполнением двух программ / процессы / темы (микроуровень).

Они используют одно и то же слово одновременное , но первое является однородным , если мы просто предположим, что сервер предоставляет только одну услугу, и нет взаимодействия / обобщения между макросами Услуги высокого уровня, предоставляемые различным пользователям. Даже если сервисы для разных пользователей переходят на уровень хранения данных и, таким образом, борются за ресурсы ввода-вывода, это больше проблема микроуровня: два запроса / записи конкурируют друг с другом за общие ресурсы. В качестве абстракции сервисы, предоставляемые пользователям, всегда однородны, поэтому функциональные возможности / библиотеки параллелизма, предоставляемые платформами (я имею в виду Java, .Net и т. Д., Я полагаю), не имеют ничего общего с веб-приложениями, но только с микрооперациями, находящимися ниже их.

Answer 6

О всем параллельности в веб-приложениях основан на многопользовательском опыте. Часто это просто «один процесс на пользователя», без общего знаменателя и, возможно, подключенный только на уровне базы данных, но такие приложения, как Flockdraw, usteream и другие, которые группируют много пользователей в режиме реального времени, поддерживают их взаимосвязь и синхронизацию несколькими потоками, загружая отдельные пользователи, но активно взаимодействуют друг с другом в режиме реального времени.

Answer 7

Конечно, платформы параллелизма имеют большой смысл в веб-приложениях. Взгляните, например, на SO (и на многопользовательскую среду StackExchange ) - во многих случаях один и тот же объект (вопрос, ответ и т. Д.) Обновляется «одновременно». Это было бы большим рассмотрением такого программного обеспечения, которое я себе представляю.