Clustering - EJBs vs JMS vs POJOs
Saturday, November 25th, 2006Warning: file_get_contents(http://jug.in.ntu-kpi.kiev.ua/glossary/get) [function.file-get-contents]: failed to open stream: HTTP request failed! HTTP/1.1 404 Not Found in /home/www/htdocs/blog/wp-content/plugins/jug-glossary.php on line 40
The entire application was written in Java (JSE and JEE) in a typical 3-tier architecture topology. The application was deployed on 2 application server nodes. All transient and persistent data was pushed into the Database to address high availability. As it turned out, as the user-base grew, the database was the major bottleneck towards RAS and performance. We had a couple of options: pay a major database vendor an astronomical sum to buy their clustering solution, or redesign the architecture to be a high-performing RAS system. Choosing the first option was tempting, but it just meant we were pushing the real shortcomings of our architecture “under the carpet”, over and above having to spend an astrnomical sum. We chose the latter.
Via pojomojo
Перевод.
Приложение было написано с использованием Java SE и Jave EE, типичная трёхзвенная архитектура, и его выполнение было распределено между двумя серверами приложений. В целях обеспечения лучшей доступности как временная, так и нуждающаяся в сохранении информация хранилась в базе данных. Но, как только число пользователей увеличилось, база данных стала узким местом производительности и RAS (Reliability, Availability, Serviceability). У нас было два варианта:
- заплатить астрономическую сумму крупному поставщику решений для баз данных за кластерное решение
- изменить архитектуру самого приложения и превратить его в высокопроизводительную RAS-систему
Первый вариант выглядел заманчиво. Но такой выбор позволял лишь покрыть узкие места архитектуры нашего приложения с помощью уплаты астрономической суммы. Мы выбрали второй вариант.
