GemFire не должен иметь проблем с обработкой 15K запросов в секунду / минуту (??).Не уверен, в каком измерении вы находитесь, но секунда / минута действительно не должны иметь значения.Это может потребовать некоторой настройки, но GemFire должен быть в состоянии справиться с этим, будь то минуты или секунды.
Несколько вещей, о которых нужно подумать:
1) Во-первых, посмотрите здесь.
2) Разумеется, вы можете настроить обе стороны топологии клиент / сервер.
На клиенте вы можете использовать PoolFactory для настройки параметров, таких как соединения min / max, prSingleHopEnable, socketBufferSize, threadLocalConnections и т. д.
Используя Spring Session для Pivotal GemFire, этот Pool используется на клиенте (веб-приложение, GemFire ClientCache) настраивается с использованием класса SDG ClientCacheFactoryBean при использовании GemFire * DEFAULT Pool, который вы часто объявляете сами, например so или PoolFactoryBean класс, если вы используете определенный, «именованный» Pool с Spring Session для Pivotal GemFire, в этом случае он будет выглядеть примерно так ...
@SpringBootApplication
@EnableGemFireHttpSession(poolName = "SessionPool", ...)
class MySpringSessionGemFireClientApplication {
@Bean("SessionPool")
PoolFactoryBean sessionPool() {
PoolFactoryBean sessionPool = new PoolFactoryBean();
sessionPool.setMaxConnections(..);
sessionPool.set...
return sessionPool;
}
}
На сервере,это действительно зависит от того, как вы запустили узлы (например, Gfsh , uпеть весна и т. д.).Но, по сути, все сводится к настройкам CacheServer.Например: loadPoolInterval, maxConnections, socketBufferSize, maxThreads и т. Д.
3) Я бы также сказал, что сначала нужно собрать информацию, чтобы определить, где может быть проблема, просматривая журналы сервера, статистику и т. Д. И т. Д.Эта информация должна быть рекомендована в пункте 1 выше.
4) Есть и другие факторы, о которых следует подумать, например, размер данных.
5) Есть вещи, которые вы должны рассмотреть с точки зрения сети.и добавление «контейнеров» добавляет целый другой уровень сложности, поэтому он будет зависеть от UC, архитектуры, инфраструктуры.
В любом случае, все это означает, что трудно сказать наверняка, в чем проблемаучитываются все факторы (например, топология, архитектура, размер данных, конфигурация, дизайн приложения и т. д. и т. д.).Предоставление журналов, статистики и т. Д. Может пролить некоторый свет.
Не уверен, почему вы думаете, что дамп потока выше - "ошибка".Да, " Cache Client Updater Thread " удерживает блокировку объекта, однако поток также остается в состоянии RUNNABLE (в обслуживании).Тот факт, что этот поток удерживает блокировку, является проблемой только в том случае, если другой поток (1 или более) находится в состоянии ожидания или блокировки, ожидает этой блокировки и начинает использовать ресурсы или блокирует / ухудшает некоторые рабочие процессы приложения.
Я подозреваю, что у вас есть проблема между GemFire и контейнером, но я не могу сказать это наверняка.