Что сделать параллельно? Что сделает меня лучше? (.net веб-бизнес-приложение, MVC + SL)

Question

Я работаю над каркасом веб-приложений, который использует MSSQL для хранения данных, в основном просто выполняет операции CRUD (но на произвольно сложных структурах), предоставляет интерфейс WCF для многофункционального администратора Silverlight и имеет дисплей MVC3 (и некоторые основныеформы, такие как пользовательские настройки и т. д.).

Он хорошо справляется с возможностью загрузки, отображения, редактирования и сохранения любой (разумно) сложной структуры данных удобным для пользователя способом.

Но я смотрю в будущее и хочу расширить свои возможности (и было бы интересно узнать что-то новое по пути ...) - так что я решила (в свете того, что ждет C# 5 ...), чтобы попытаться получить некоторую параллельную / асинхронную оптимизацию ... Теперь я еще даже не изучил TPL и PLinq, поэтому я рад любым советам там же.

Итак, мой вопрос , каковы возможные области, где параллельная обработка может быть полезной, и где TPL и PLinq помогают мне в этом?

Мои смелости говорят мне, я мог бы попытаться сохранить ветви структуры данных параллельно с базой данных (именно здесь я ожидал наибольшей оптимизации производительности), я мог бы выполнить некоторые сложные операции (загрузка файла)возможно, отправка почты?) в многопоточной среде и т. д. Могу ли я параллельно создавать сложные представления SL UI на клиенте?(Создание 60 связанных с данными полей в представлении может вызвать «мерцание» ...) Могу ли я создать частичные представления (меню, деревья категорий, формы поиска и т. Д.) В MVC сразу?

ps: Если этопревращается в ветку "Расскажи мне все о параллельных вещах", я рад сделать это вики-сообществом ...

Answer 1

Помните, что веб-приложение asp.net по сути является параллельным приложением в любом случае. Запросы могут обслуживаться параллельно, и все это будет управляться средой asp.net. Итак, есть два случая:

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

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

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

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

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

Answer 2

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

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

Получайте удовольствие, но мне интересно, является ли это случаем: 1) решение преследует проблему и 2) преждевременная оптимизация.