Какова производительность распределенного кэша KODO JDO? - PullRequest
Новая
       20

Какова производительность распределенного кэша KODO JDO?

0 голосов
/ 07 января 2010

У кого-нибудь есть опыт работы с механизмом распределенного кэша KODO JDO? Я хотел бы знать:

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

2) сколько данных будет передаваться между JVM? если обновление сделано для одного кэша, он просто говорит другим кешам отбросить объекты, сообщая ему первичные ключи объектов для сброса? (проблема в сетевом трафике / накладных расходах на управление распределенным кешем)

3) когда у вас есть внешние фиды, обновляющие вашу базу данных в течение дня (то есть не входящие через ваше приложение), насколько легко вызвать внешнюю очистку кэша?

Наше приложение работает в кластере Weblogic, состоящем из 12 JVMS, и мы рассматриваем возможность включения распределенного кэша для повышения производительности за счет извлечения больших графов объектов из нашей базы данных, которые в настоящее время не кэшируются, но хотелось бы знать некоторые реальный опыт работы с № 1,2 и 3. Спасибо.

1 Ответ

0 голосов
/ 19 января 2010

Это частичный ответ, но я считаю, все еще полезно (с http://docs.oracle.com/cd/E13189_01/kodo/docs303/ref_guide_cache.html):

При использовании вместе с kodo.event.RemoteCommitProvider информация о фиксации передается другим JVM через JMS или TCP, и удаленные кэши становятся недействительными на основе этой информации.

Не указано, означает ли это, что этот коммит включен как часть исходной транзакции (можно было бы надеяться) или и / или каково время задержки или издержки с этой операцией и насколько хорошо она масштабируется (например, как она выполните, если вы координируете 15 JVM, и у вас есть несколько пользователей, обновляющих одни и те же данные)

...