Здравствуйте,
Хотелось бы узнать мнение, желательно, основанное на опыте , по следующему вопросу.

Входящие, неизменяемые условия:
Имеется Tomcat 6. Несколько сотен клиентов шлют к нему запросы с частотой не меньше чем 1 запрос за 5 секунд.
Для каждого запроса надо обратиться к нескольким общим ресурсами в памяти. Работа с БД минимальна, при этом она используется либо до исполнения запроса (подгрузить что-то в кеш), либо после (кинуть лог, обновить персистант объект, коих не так много и они не являются общими ресурсами). 

Предлагаемое решение:
В сервлете, на основе аргументов создается задача и возможно происходит загрузка чего-то необходимого из БД для этой задачи. далее в задача кидается в однопоточный(!) Executor, в нем происходит выполнение логики (при этом логика не совершает операций ввода вывода и не требует блокировок). В это время сервлет ждет результата задачи.
Получив его, он, возможно что-то пишет в БД, и отдает ответ. Ответ по объему небольшой.

Ожидаемые преимущества:
1 - резкое уменьшение сложности кода за счет того, что можно спокойно выкидывать все блокировки в бизнес-логики

Интересующий показатель:
Влияние на решения на производительность: как возможное положительное, так и возможное отрицательное.


Это сообщение отредактировал(а) graycrocodile - 6.12.2010, 20:24

Вообще не вижу никаких преимуществ.
1. Откуда в бизнес логике берутся взаимные блокировки? Блокировки могут быть на операциях чтения/записи в кеш/СУБД, но они не в бизнес логике, а в сторонних библиотеках.
2. Сервлет это отдельный поток, и отказ от многопоточного сервера в пользу однопоточного Executor-а, не принесет никаких особых преимуществ.

в данном случае клиентам приходится постоянно оперировать общими данными, и если доступ к этим данным не синхронизировать, то они потеряют целостность. А любая синхронизация (критическая секция), активно используемая, приводит к блокировке.

А что за "общие данные" такие, которые меняются но при этом

не хранятся в БД?

важно что такие данные есть не так ли? 
данные текущих игровых сессий между группами игроков.

Это сообщение отредактировал(а) graycrocodile - 7.12.2010, 19:11

Важен характер этих данных. Просто я не совсем понимаю как происходит работа с этими данными:

И где в этой схеме происходит изменение игровых сессий игроков?

я предполагаю выполнять ее здесь.


Добавлено через 6 минут и 18 секунд
поясню примером.
Имеется куча игроков. Они трепятся у себя в своих чатиках, часто сразу в нескольких (там зональный чат, клан чат, приватный с другом). Далее в это же время игроки используют сервис поиска соперника из желающих сразится. В случае нахождения, игроки на  утюжат друг друга в дуэльном пошаговом бою или групповом, не прекращая своего флуда. 
Реально в БД необходимо коммитить только результат боя, ну и результат похода в магазин перед боем. Все остальное большой информационный шум, не требующий увековечивания его в БД. Однако, требующий использования общих данных, типа списки чатов, поля боев, списки желающих подраться по зонам с желаемыми параметрами соперника и проч.

Мое мнение таково:
- в принципе этот метод может дать прирост производительности если большую времени обработчик тратит на изменение общих объектов.
- на многопроцессорной машине будет эффективно утилизироваться только одно ядро
- если сравнить предложенным метод оптимизации и грамотно реализованные "общие данные" (использование неблокируемых коллекций из java.util.concurent, synchronized блоки заменить на ReadWriteLock и т.д.), то второй вариант будет более производительным и масштабируемым

P.S. Рекомендую почитать Оптимизация производительности: эффективное взаимодействие с виртуальной машиной, раздел про блокировки.

спасибо за ссылку. Почитаю.


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

Это сообщение отредактировал(а) graycrocodile - 7.12.2010, 20:32

"общие данные" - это же, наверное, обычные коллекции, Мап, Лист. Почему бы не использовать синхронизированные коллекции? Например, кеш системы, где кроме синхронизации еще много чего полезного. Автоматический сброс на диск редко используемых обьектов. Или распределенный кеш. Чтобы обшие ресурсы не "жили" в Томкате. ehcache, hazelcast e.t.c. 

да, в подавляющем большинистве списки, массивы, деревья из объектов, которые подвержены частым модификациям.



если делать синхронизации "в тупую", т.е универсально, то это скорее всего негативно отразится на производительности, если делать в каждом случае отдельное решение, то это сильно усложнит код.
Хочется именно универсального решения, которое вынесет все проблемы синхронизации в отдельный слой абстракции и при этом не било кувалдой по производительности.

Сравните размер критической секции и всей бизнес-логики обработки запроса. Первая выполняется 5 мс, вторая - 200. Т.е. в первом случае будут блокировки на 5мс, во втором - на 200. 

Кроме того, синхронизацию с части изменений можно снять с помощью Atomic- переменных.

Добавлено через 51 секунду

Вынос обработки всех запросов в один поток - это не кувалда. Это Царь-бомба. 

и почему же?
реальное преимущество много поточности в производительности проявляется только при наличии частых остановок потоков на операции ввода-вывода.

А многопроцессорные/многоядерные CPU?

тут тоже не все так просто.
В теории да, два процессора работают в два раза быстрее, но только если данные используемые ими, не имеют общих частей, иначе синхронизации обязаны выполнять сброс кеша, и производительность упадет. Что касается моего решения, то многоядерному железу и здесь найдется работа. Ведь помимо этого потока логики, есть пул потоков в которых исполняются сервлеты, и их тоже где-то надо обрабатывать.

Небольшой UPD.
Игроков можно разделить на зоны, игрок в одной зоне не имеет контактов с другими зонами (нет междузональных общих данных), тогда кол-во потоков логики становится равным кол-у зон. Что уже будет выглядеть не так страшно.

Это сообщение отредактировал(а) graycrocodile - 8.12.2010, 14:04