Служба Windows или планировщик задач для задач обслуживания?

Question

У меня есть приложение C #, которое выполняет некоторые задачи по обслуживанию. Он должен работать примерно каждый час, хотя это не так уж важно, если он немного выключен. И он должен работать на сервере Win2003, когда никто не вошел в систему.

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

Альтернативой является планировщик заданий Windows, но я не уверен, подходит ли он для использования на сервере, поскольку а) мне нужно было бы хранить расписание в нем, а не в моем app.config, б) я не могу легко контролировать обслуживание через запуск / останов / перезапуск и c) я не знаю, являются ли учетные данные пользователя Windows такими же безопасными, как когда я ввожу их в оснастку MMC службы.

Каково ваше мнение? Возможно ли и полезно иметь неработающий Сервис или вы бы порекомендовали вместо него планировщик задач?

Answer 1

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

Answer 2

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

Кроме того, утилиты, которые работают непрерывно и «спят», рискуют вызвать проблемы, если разработчик «забудет» сделать такие вещи, как закрытые соединения, файлы и т. Д., Которые могут накапливаться со временем. Наличие программы «беги и выходи» является дополнительным защитным покрывалом. : -)

Answer 3

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

Answer 4

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

Для последних проектов я использовал Quartz.NET для настройки запланированной обработки в службах Windows. Это на самом деле не так уж сложно в настройке (хороший учебник), и CronTrigger предоставит вам тонну гибкости с минимальными настройками. Мне больше нравится, чем сырой .NET Timer.

Answer 5

Если вы идете по пути обслуживания, я бы рекомендовал использовать System.Threading.Timer. При этом вы можете настроить запуск события один раз в час. Вы можете поместить интервал в app.config, если считаете, что вам когда-нибудь понадобится его изменить.

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

У меня есть ситуация, когда я на самом деле использую комбинацию обоих. Служба работает постоянно в течение дня, но каждую ночь они выполняют обслуживание сети и базы данных. Итак, я использую две запланированные задачи. Один, чтобы отключить службу в полночь, а другой, чтобы включить его в 4 часа утра. Это делается путем вызова файлов .BAT с помощью команд NET STOP / NET START.

Answer 6

Служба Windows более безопасна: никто не может ее отбросить и никогда не работает. Я обнаружил много проблем с задачами Windows (не выполняются, ...).

Планировщик заданий Windows предназначен для задач конечного пользователя, а не для задач приложения. В любом случае, Windows Backup использует его; -)