Я хотел бы отслеживать множество веб-страниц/rss-каналов одновременно и опробовать их на регулярной частоте (они могут иметь разные частоты обновления). Я думаю о создании потока для каждого источника, который я хочу отразить, который будет бесконечно зацикливаться, а затем спать до следующего обновления после обработки извлеченных данных.Мониторинг многих веб-страниц/rss-каналов
У кого-то есть лучшая идея или пример того, как это сделать?
Используйте таймер для каждого 1 (или 5) минут. В обратном вызове таймера пройдите по URL-адресам, которые необходимо проверить, и проверьте, должны ли они быть проверены (как вы добавили комментарий, они будут иметь разные времена синхронизации). Вы можете подготовить правильную структуру для хранения URL-адресов и их тайм-аутов, а также в последний раз с тех пор.
Если для синхронизации установлен URL-адрес (время истекло), запустите асинхронный HttpWebRequest, чтобы получить его. Таким образом, вы разгружаете всю принимающую часть потоку threadpool, поэтому она не влияет на ваш поток обратного вызова основного таймера.
Будьте осторожны - если вы выполняете тяжелую обработку ответов, вы можете начать регулярный поток в обратном вызове HttpWebRequest, чтобы выполнить дополнительную обработку, или реализовать какую-то очередь, чтобы освободить поток threadpool, как только возможное.
Вот хорошее объяснение, как сделать запросы асинхронными: http://www.devnewsgroups.net/group/microsoft.public.dotnet.framework/topic23172.aspx
Вы можете Google больше примеров, а также, но это хорошее начало.
Почему бы не просто синхронизировать его на одном такте, например, чтобы все они обновлялись на 10 в течение каждого часа (10, 20, 30 и т. Д.) Вместо того, чтобы все ваши потоки обновлялись случайно в течение 10-минутного периода. Зачем вам нужно создать один поток на страницу/канал?
Используйте объект Timer для запуска процесса с использованием объекта BackgroundWorkerThread, чтобы вы могли обрабатывать объекты в фоновом режиме. В зависимости от количества каналов, которые у вас есть, вы можете подумать о том, чтобы сделать «ступенчатое» обновление за более короткий интервал. Скажем каждые 5 минут, рабочий поток запускается, переходит к следующему фиду в списке фидов, чтобы отслеживать и проверять его на наличие обновлений.
Как я уверен, вы видели из некоторых читателей каналов, обновляя ВСЕ ваши каналы сразу, это не всегда самое приятное решение, поскольку оно может немного зависнуть от пользовательского интерфейса.
Я создал сервис окна, чтобы выполнить то, что вы описываете. Каждые n минут демон просыпается, читает XML-файл с URL-адресами, которые ему нужно извлечь, обрабатывать все данные и снова спать в течение n минут. У меня был один поток для сбора данных, а другой - мониторинг файла XML для изменений. XML-файл может быть обновлен через веб-интерфейс.
Как указано в yx, нет необходимости создавать один поток на странице, однако, если у вас много URL-адресов для fecth, вы можете распространять свои URL-адреса в пакеты из 100 (например), а затем создать один поток для каждый упаковка. Затем вам нужно будет дождаться окончания последнего потока, прежде чем отправить демона в режим сна.
Один поток для каждого источника - это перебор, чтобы начать, во-вторых, спящие потоки - это потеря ценной памяти. Число потоков> количество ядер не оправдано, если у вас нет данных для поддержки того, что у всех из них будет какая-то работа (или большая часть) времени.
Еще одно соображение, когда вы принимаете решение о количестве нитей, не пытайтесь определить цель в какой-либо теме, то есть в будущем развитии кто-то хочет сделать еще 10 вещей, и он добавит еще 10 потоков для каждой вещи. Таким образом, вы можете проверить taskmanager, сколько плохо спроектированных приложений создает столько потоков (каждый поток = 1 МБ памяти + дополнительный ресурс hog), вероятно, 1 ГБ вашего барана просто натолкнулся из-за того, что было создано столько потоков, и на самом деле ничего полезного и спать большую часть времени. Вот почему Threadpool или Async IO - это способ повторного использования системных потоков, когда они вам нужны, и распределяются между несколькими приложениями.
Последующие мои мысли, у меня будет один поток или таймер, который продолжает работать (и спать, если есть необходимость), а затем делать асинхронные вызовы (не блокировать на один вызов) или очередь, каждый из которых вызывает в Threadpool все источник для обновления, чей период обновления достигнут (тогда, вероятно, он будет спать в течение небольшого промежутка времени, если вам действительно нужно).
Дополнительная информация о Asynchronous IO & Threadpool
Любые причины для downvote? –
Я не думаю, чтобы таймеры, они на самом деле достаточно хорошие (и рекламировать все ответы до сих пор), но источники не должны всегда обновлять на той же частоте или в то же время , – Dave
Вы не указали, что каждый ресурс будет иметь свой собственный тайм-аут. Но все же - у вас может быть много таймеров - попробуйте сгруппировать много ресурсов за один таймер с аналогичными тайм-аутами. Кроме того, если вы собираетесь выполнять тяжелую обработку ответов, не делайте этого в обратном вызове асинхронного запроса, а затем запускайте поток для обработки результатов, поэтому потоки бегущей строки будут освобождены достаточно скоро. –
Ответ изменился с учетом новых требований. Пожалуйста, также отредактируйте свой вопрос. –