Concurrency в веб-приложениях

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

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

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

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

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

Ответы

Ответ 1

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

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

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

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

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

Не относится к традиционному веб-приложению, а скорее к Интернету как "облако", функциональное программирование помогает с распределенным вычислением между ЦП и узлами. Известным примером является map/reduce и подобные, которые направлены на обработку большого набора данных.

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

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

Ответ 2

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

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

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

и

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

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

Ответ 4

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

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

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

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

Ответ 5

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

Ответ 6

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

Ответ 7

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

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