Характеристики кварца

Кажется, существует ограничение на количество заданий, которые планировщик Quartz может запускать в секунду. В нашем сценарии мы запускаем около 20 заданий в секунду в режиме 24x7, а кварц хорошо работал до 10 заданий в секунду (со 100 потоками кварца и размером пула подключений к базе данных 100 для JDBC JobStore ), однако, когда мы увеличил его до 20 заданий в секунду, кварц стал очень-очень медленным, а его запускаемые задания очень опаздывают по сравнению с их фактическим запланированным временем, вызывая множество осечек и в конечном итоге значительно замедляя общую производительность системы. Интересен тот факт, что JobExecutionContext.getScheduledFireTime().getTime()для таких отложенных триггеров оказывается на 10 -20 и даже больше минут после их запланированного времени.

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

Или я что-то здесь упускаю?

Подробности о том, чего мы хотим достичь:

У нас есть почти 10 000 элементов (, отнесенных к 2 или более категориям, в данном случае у нас есть 2 категории ), для которых нам нужна некоторая обработка с заданной частотой, например. 15,30,60... минут и эти элементы должны обрабатываться с этой частотой с заданным дросселем в минуту. например. скажем, за 60 минут периодичность 5 000 элементов для каждой категории должна быть обработана со скоростью 500 элементов в минуту. Таким образом, в идеале эти элементы должны обрабатываться в течение первых 10 (5000/500 )минут каждого часа дня, при этом в каждую минуту необходимо обрабатывать 500 элементов, которые равномерно распределяются по каждой секунде минуты, поэтому мы бы иметь около 8 -9 элементов в секунду для одной категории.

Теперь для этого мы использовали Quartz в качестве планировщика, который запускает задания для обработки этих элементов. Однако мы не обрабатываем каждый элемент в методе Job.execute, потому что это займет 5 -50 секунд (, в среднем до 30 секунд )на обработку элемента, которая включает вызов веб-службы. Мы скорее отправляем сообщение для каждого обрабатываемого элемента в очередь JMS , а отдельные серверы обрабатывают эти задания. Я заметил, что метод Job.execute занимает не более 30 миллисекунд .

Сведения о сервере:

64-битный сервер Solaris Sparc с процессором на 8/16 ядер/потоков для планировщика с 16 ГБ ОЗУ, и у нас есть две такие машины в кластере планировщика.