Вы можете обнаружить, что пакетирование нескольких изменений в одной области блокировки будет работать лучше. Каждый синхронизированный блок / метод формирует транзакцию записи (при условии, что вы используете блокировку записи), которую необходимо отправить на сервер (и, возможно, обратно на другие узлы). Изменяя несколько полей, возможно, для нескольких объектов под одной блокировкой, вы сокращаете издержки на создание транзакции. По крайней мере, с чем поиграть.
Разделение также является ключевым способом повышения производительности. Изменения нужно отправлять только на узлы, которые фактически используют объект. Таким образом, если вы можете разделить, какие узлы обычно касаются определенных объектов, это уменьшает количество изменений, которые необходимо отправить по кластеру, что повышает производительность.
Хорошие предложения unnutz по использованию CHM или CSM. CHM обеспечивает больший параллелизм (поскольку каждый внутренний сегмент может быть заблокирован и использоваться одновременно) - обязательно поэкспериментируйте с большим количеством сегментов. CSM имеет фактически одну блокировку для каждой записи, поэтому фактически имеет N разделов в таблице размера N. Это может значительно снизить конкуренцию за блокировку (за счет управления большим количеством объектов внутренней блокировки). Изменения, которые скоро появятся в CSM, значительно снизят стоимость блокировки.
Как правило, мы находим хорошую стратегию:
- Создайте тест производительности (должен быть многопоточным и многоузловым, похожим на ваше приложение (или ваше реальное приложение!)
- Настройте объекты - посмотрите на свой кластеризованный граф объектов в консоли разработчика, чтобы найти объекты, которые вообще не нужно кластеризовать - иногда это происходит случайно (удалите или обрежьте кластер с помощью переходного поля). Иногда вы можете кластеризовать Date, где будет делать long. Небольшое изменение, но это один объект на карту, и это может иметь значение.
- Настройка блокировок - используйте профилировщик блокировок в консоли разработчика, чтобы найти горячие блокировки или блокировки, которые слишком узкие или слишком широкие. Регистратор кластерной статистики также может помочь в анализе размера транзакции.
- Настройте GC и DGC - настройте сборку мусора JVM, затем настройте распределенный GC Terracotta, включив изменение частоты молодого поколения gc.
- Tune TC server - здесь очень много подробных настроек, но обычно они того не стоят, пока не настроены все вышеперечисленные.
Не стесняйтесь спрашивать на Терракотовых форумах , а также - все о инжиниринге, полевом инжиниринге, продукции mgmt смотрите их и отвечайте там.