Какой оптимальный интервал таймера? Служба .NET для Windows

... Кроме того, имеет ли смысл то, что я каждый раз выбираю только 3 элемента для обработки ...

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

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

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

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

Я попытался разделить весь код так, чтобы мне не нужно было использовать lock.

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

У вас не должно возникнуть проблем с 1-секундным таймером, если вы отдаете всю работу другому потоку, отличному от таймера.

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

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

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

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

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

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

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

Если вас интересует обмен сообщениями, загляните в NServiceBus. По сути, это оболочка вокруг MSMQ, которая откроет вам совершенно новый мир идей, касающихся взаимосвязанных систем.

Варианты действительно безграничны.

Я бы использовал интервал в 10 секунд.
Сделайте еще одну проверку, когда пользовательский процесс завершится (чтобы предотвратить ненужное 10-секундное ожидание)

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

Дополнительную информацию о SQLDependecy смотрите здесь:
http://www.codeproject.com/KB/database/chatter.aspx

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

Если вы не хотите гадать, попробуйте реализовать winservice на основе очередей. Эта служба будет читать очередь MSMQ, брать рабочий элемент и обрабатывать его. Итак, вам просто нужно спросить эту очередь, есть ли у вас еще рабочие элементы для обработки, и вы можете делать это с любой частотой, которую хотите, скажем, 1 секунду.

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

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