sirus May 4 2011 at 20:44

Vertical Scaling in Java Cloud

2 min

1.3K

Хочу поделится результатами внутренних тестов вертикального автоматического масштабирования памяти в Jelastic — облачный хостинг для Java приложений.
В данном примере симитировано поведение web приложения, которое работает на базе Tomcat сервера. Измерения проводились при различных нагрузках. Нагрузка изменялась путем увеличения количества подключенных клиентов. Измерения показаний проводились через админку владельца приложения.

Реализация на сервере

Каждому новому пользователю в сессию кладется массив байтов размером 10Мб.


<html>
    <body>
        <h1>Hello!</h1>
        <%
                    byte[] data = (byte[]) session.getAttribute("test-data");
                    if (data == null)  data = new byte[1024 * 1024 * 10];
                    request.getSession().setAttribute("test-data", data);

        %>
        Your session ID <%=session.getId()%><br/>
        Your session data size <%=data.length%> bytes<br/>
    </body>
</html>

Приход клиентов

На графике видно три волны клиентов — 100, 300 и 1000 соотв-но.

Первая волна 100 клиентов (в 1 поток одновременно) потребляет примерно ~ 1.3Gb. После чего идет таймаут сессий (10 минут) == все данные из сессий пользователей выгружаются и память возвращается в платформу.
Вторая волна 300 клиентов (в 10 потоков) ~ 3.5Gb. Опять после таймаута сессий память возвращается в платформу.
Третья волна 1000 клиентов (в 100 потоков) ~ 11Gb. После таймаута сессий память возвращается в платформу.

Как видно из скриншота, приложение берет от платформы только то, что ему реально нужно. Память которая уже не используется, возвращает обратно. Оплата будет осуществляться по факту потребления ресурсов.

Настройки масштабирования

В правой колонке первый ряд указанно число 3/64 (current/limit) — потребление памяти в cloudlet (минимальный неделимый кусок в 256Mb).
Приложение может масштабироваться в пределах от 1 до 64 cloudlets (от 256Mb до 16Gb). Настройки коэффициента масштабирования для данного приложения = x64 раз.

Выводы

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

Для более реальных показателей — каждый, кто прочитал заголовок этого поста, участвует в тестировании на реальных условиях. Верхнее изображение загружает 200Кб в сессию каждого пользователя. Если тема интересна, результаты реального теста будут выложены попозже. Надеюсь установленных лимитов в 16Gb хватит на пользователей Хабра.

— UPDATE

Результаты експеримента

Первый пик — это нагрузочное тестирование для данной статьи — заняло 11Gb памяти.
Второй пик — выход данной статьи на главную — заняло 2Gb памяти.
Хвост — остаточное явление, падение активности — заняло 0.6Gb памяти.

Из расчета того, что на каждого уникального посетителя в память загонялось 200кб памяти, одновременно в течении 10 минут на сервере присутствовало не более 5.000 человек в самый пиковый момент.
Результаты показывают что нагрузить сервере надо еще уметь :), эмуляция нагрузки куда сильнее качнула память чем реальность.
В обоих случаях отработал динамический скалинг по памяти, итоговая цена будет расчитываться относительно реально потребляемых ~~попугаев~~ клаудлетов.

Tags:

Hubs:

Jelastic corporate blog