Вы, абсолютно верно заметили, что на планшетах не обязательно должен быть браузер Chrome. Главное, чтобы движок был на Chromium.
Автор пишет:
На данный момент приложение работает только в браузере Chrome.
Это требование всё таки больше для разработки, тестирования и демо. А вот в продакшине для запуска веб-приложения на киоске используется не обычный браузер, а так называемые Kiosk Management Tools для управления Android, iOS или Windows устройством типо KioWare Client или ScaleFusion, которые предоставляют возможность отображать содержимое веб-приложения в своем веб-вью без возможности выполнять навигацию как в обычном браузере (закрывать окно, вводить новый Url). В итоге конечные пользователи даже не будут знать, что это приложение работает в браузере. Для них всё будет выглядеть как Native.
В MotoGP уже несколько лет используются комбинизоны со встроенными подушками безопасности. Марку Маркесу в прошлом году такой комбез спас жизнь на грант-при Италии. Хорошо, что умные вещи постепенно приходят в массы =)
Реальный пример, когда может понадобиться использовать ConcurrentBag — это параллельный поиск заданного элемента из нескольких источников и подсчет его вхождений в каждом из них. В данной коллекции удобно хранить промежуточные значения результатов поиска с учетом того, что эти значения могут совпадать.
Да, книга что надо +1.
Stephen Cleary пишет очень толковые вещи. Я постоянный читатель статей с его сайта. Вся информация структурированная и читается легко.
Посмотрел ваш проект. Видимо очень давно писали тест для проверки. С такой асинхронной реализацией вы не получите никакого преимущества от async/await подхода в ASP.NET:
Это очень плохой код. Вместо Thread.Sleep() надо использовать await Task.Delay(), а вместо Task.Factory.StartNew() новый метод HostingEnvironment.QueueBackgroundWorkItem(). Результаты тестов будут другими.
Просто оборачивая синхронный код в Task.Run(), а ещё хуже в Task.Factory.StartNew(), в ASP.NET мы не получим ожидаемых результатов. Эти методы только выглядят асинхронно. Такой код всё равно будет блокировать рабочий процесс в пуле на время выполнения задачи. При этом, мы получаем проблемы с SynchronizationContext. Правильный подход заключается в вызове асинхронных методов и использовании async/await.
Task.Run() полезно использовать для выполнения CPU-нагруженных задач в асинхронном режиме для UI-приложений, но не в ASP.NET.
В .NET 4.5.2 появился новый метод QueueBackgroundWorkItem, который позволяет надежно планировать и выполнять фоновые процессы в ASP.NET в случае необходимости.
dreik, вы указали важный момент, на который стоит обратить внимание и ссылка очень хорошая :)
Однако всё таки в данном случае слово «немедленно» нужно понимать буквально.
Поясню: параметры minIoThreads/minWorkerThreads необходимо задавать для обеспечения работоспособности приложения в случае, когда происходит «взрыв нагрузки» (Burst Load), т.е. количество пользователей возрастает по экспоненте. Если до часа «Х» нагрузка на сайте была невысокая, то в пуле имеется небольшое количество потоков. Таким образом, CLR ThreadPool используя собственный алгоритм распределения потоков может не иметь достаточно времени, чтобы достичь оптимального уровня потоков, т.к. на создание пары новых потоков в пуле уходит около 1сек. Установка параметров minIoThreads/minWorkerThreads позволяет пулу справиться с возросшей нагрузкой в штатном режиме, т.к. минимальное заданное количество «Worker» и «IO» потоков будут созданы и использованы пулом «немедленно».
Причём, начиная с .NET Framework 4, пул потоков создает и уничтожает потоки в целях оптимизации производительности, поэтому количество текущих потоков в пуле может быть ниже минимального заданного значения minIoThreads/minWorkerThreads. Однако по требованию необходимые потоки для пула могут быть созданы очень быстро до минимальных значений, а при снижении нагрузки они опять удаляются. На MSDN в разделе ThreadPool Class можно починать подробнее про это.
p.s. В реальной жизни наглядный пример такой ситуации — это получение зарплаты/премии сотрудниками какой-нибудь крупной компании в определённое время, когда все спешат на сайт побыстрее увидеть, сколько же им начислили деньжат ))
Автор пишет:
Это требование всё таки больше для разработки, тестирования и демо. А вот в продакшине для запуска веб-приложения на киоске используется не обычный браузер, а так называемые Kiosk Management Tools для управления Android, iOS или Windows устройством типо KioWare Client или ScaleFusion, которые предоставляют возможность отображать содержимое веб-приложения в своем веб-вью без возможности выполнять навигацию как в обычном браузере (закрывать окно, вводить новый Url). В итоге конечные пользователи даже не будут знать, что это приложение работает в браузере. Для них всё будет выглядеть как Native.
Stephen Cleary пишет очень толковые вещи. Я постоянный читатель статей с его сайта. Вся информация структурированная и читается легко.
Это очень плохой код. Вместо Thread.Sleep() надо использовать await Task.Delay(), а вместо Task.Factory.StartNew() новый метод HostingEnvironment.QueueBackgroundWorkItem(). Результаты тестов будут другими.
Task.Run() полезно использовать для выполнения CPU-нагруженных задач в асинхронном режиме для UI-приложений, но не в ASP.NET.
В .NET 4.5.2 появился новый метод QueueBackgroundWorkItem, который позволяет надежно планировать и выполнять фоновые процессы в ASP.NET в случае необходимости.
Однако всё таки в данном случае слово «немедленно» нужно понимать буквально.
Поясню: параметры minIoThreads/minWorkerThreads необходимо задавать для обеспечения работоспособности приложения в случае, когда происходит «взрыв нагрузки» (Burst Load), т.е. количество пользователей возрастает по экспоненте. Если до часа «Х» нагрузка на сайте была невысокая, то в пуле имеется небольшое количество потоков. Таким образом, CLR ThreadPool используя собственный алгоритм распределения потоков может не иметь достаточно времени, чтобы достичь оптимального уровня потоков, т.к. на создание пары новых потоков в пуле уходит около 1сек. Установка параметров minIoThreads/minWorkerThreads позволяет пулу справиться с возросшей нагрузкой в штатном режиме, т.к. минимальное заданное количество «Worker» и «IO» потоков будут созданы и использованы пулом «немедленно».
Причём, начиная с .NET Framework 4, пул потоков создает и уничтожает потоки в целях оптимизации производительности, поэтому количество текущих потоков в пуле может быть ниже минимального заданного значения minIoThreads/minWorkerThreads. Однако по требованию необходимые потоки для пула могут быть созданы очень быстро до минимальных значений, а при снижении нагрузки они опять удаляются. На MSDN в разделе ThreadPool Class можно починать подробнее про это.
p.s. В реальной жизни наглядный пример такой ситуации — это получение зарплаты/премии сотрудниками какой-нибудь крупной компании в определённое время, когда все спешат на сайт побыстрее увидеть, сколько же им начислили деньжат ))