Производительность таймера EJB - PullRequest
0 голосов
/ 27 июля 2011

Я пытаюсь решить, использовать таймер java-ee в моем приложении или нет. Я использую сервер Weblogic 10.3.2

Необходимость: После одного часа вызова асинхронного веб-сервиса из EJB, если не был вызван метод асинхронного обратного вызова, необходимо выполнить некоторые действия. Информация о том, был ли вызван метод обратного вызова и дата выполнения вызова, хранится в базе данных.

Я вижу две возможности:

  1. Используя пакетный процесс, который каждые полчаса ищет все вызовы, которые были более одного часа без ответа, и выполняет необходимые действия.
  2. Создайте таймер на один час после каждого отдельного вызова ws и в методе @Timeout проверьте, пришел ли ответ и, если нет, выполните необходимые действия.

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

Есть мысли?

Ответы [ 4 ]

1 голос
/ 28 июля 2011

@ Пау: зачем вам нужно создавать таймер для каждого звонка ... вместо этого у вас может быть один поток таймера, созданный при запуске приложения, который запускается через каждые полчаса (настраиваемый) промежуток времени и просматривает Ваша база данных для всех вызовов веб-сервисов, чей ответ не был получен, а запрошенное время превышает 1 час. А для выбранных записей в цикле for он может выполнить требуемое действие.

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

Если у вас есть Spring Framework в вашем приложении, вы также можете посмотреть его службы таймера. http://static.springsource.org/spring/docs/1.2.9/reference/scheduling.html

1 голос
/ 27 июля 2011

Вам бы лучше иметь более специализированный процесс. Настоящая проблема - проблема 100 000 человек. Это будет зависеть от того, сколько времени займут ваши действия.

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

Кроме того, таймеры сохраняются, поэтому ваша таблица управляемых EJB-таймеров будет сохранять и удалять 30 строк в секунду (всего 60), что предполагает 100 000 транзакций в час.

Итак, очень много работы происходит очень быстро. Я легко вижу, что система просто «отстает» и никогда не догоняет.

Специализированный процесс мог бы быть намного легче, возможно, мог бы пакетировать вызовы действий (вызывать 5 действий на поток вместо одного на поток) и т. Д. Было бы неплохо, если бы вам не нужно было сохранять события таймера, но это то, что есть. Вы можете легко добавить события таймера в файл для безопасности и сохранить их в памяти. При перезапуске системы вы можете перезагрузить этот файл, а затем свернуть файл (каждый час создавать новый файл, удалять старый файл после его использования и т. Д.). Это позволит сэкономить много трафика БД, но вы можете потерять транзакционный характер БД.

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

1 голос
/ 27 июля 2011

Все зависит от того, что использует контейнер. например JBoss использует Quartz Scheduler для реализации функций таймера EJB. Кварц очень хорош, когда у вас есть около 100 000 экземпляров таймера.

0 голосов
/ 27 июля 2011

Может быть, вы могли бы использовать некоторые из этих идей:
Где я нахожусь, мы создали cron-подобный планировщик, который питается от одного таймера. Когда таймер срабатывает, система проверяет, какие кроны должны работать, используя Quartz CronTrigger. Как правило, этим кронам предстоит много работы, и то, как мы справляемся с каждым кроном, приводит к выделению его отдельных задач в виде сообщений JMS, а затем MDB обрабатывают сообщения. В настоящее время это выполняется на одном экземпляре Glassfish, и когда нагрузка на нашу задачу увеличивается, мы должны иметь возможность масштабировать ее с помощью кластера, чтобы несколько узлов обрабатывали сообщения jms. Мы уравновешиваем нагрузку обработки сообщений jms для каждого типа задач, устанавливая max-pool-size в glassfish-ejb-jar.xml (также известный как sun-ejb-jar.xml).

Построить такую ​​систему и правильно продумать все детали - это не тривиально, но оказывается действительно эффективным.

...