Нагрузочное тестирование Geoserver

Аватар пользователя Ульянов Дмитрий
Ульянов Дмитрий

Поскольку современные тенденции работы с геоинформацией все больше тяготеют к веб-решениям, а также ввиду постоянной потребности совершенствовать возможности ГИС-компоненты нашего приложения, возникла идея более серьезно и плотно использовать возможности серверного приложения для предоставления геоинформации — Geoserver.

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

Исследованию этого вопроса и посвящена данная статья.

1. Цели


  1. Определить среднее время реакции Geoserver на http-запросы.
  2. Определить пороговые значения параметров нагрузки, при которых запросы корректно обрабатываются Geoserver.

 2. Подготовка к тестированию


В качестве тестового стенда был использован Geoserver 2.5.1, развернутый на виртуальной машине, имеющей два виртуальных ядра процессора и 4Гб оперативной памяти, ОС Linux с установленными Java и NativeJAI.

Для Geoserver были заданы оптимальные параметры JVM соответствующие конфигурации сервера:

JAVA_OPTS="-server -Xms2048m -Xmx2048m -XX:MaxPermSize=512m -XX:+UseParallelGC".

 3. Исходные данные


В качестве исходных данных использовались 3 векторных слоя одного из проектов.

Данные слои имеют одну общую систему координат — EPSG:3857 и их отображение не будет требовать репроецирования данных и дополнительных операций. Для большей оптимизации слои были объединены в групповой слой.

Полномасштабная проверка на неоптимизированных данных не проводилась.

 4. Виды запросов


При тестировании использовались 4 вида запросов:

  1. WMS запрос тайла 256х256 малой площади территории (случайного размера (до 500х500 метров) и положения в рамках МБР слоя) — далее именуется Close Scale Request;
  2. WMS запрос тайла 256х256 большой площади территории (случайного размера и положения в рамках МБР слоя) — Far Scale Request;
  3. WMS запрос GetFeatureInfo семантики объекта в случайных координатах — WMS GetFeatureInfo Request;
  4. WFS запрос GetFeature малой площади территории (случайного размера и положения в рамках МБР слоя) — WFS GetFeature Request.

 5. Виды тестирования


  1. Benchmark — тестирование на условиях, приближенных к реальным, с целью выяснения производительности системы. В качестве числа одновременно работающих пользователей было выбрано максимально возможное число в 50 пользователей. Время теста — 10 минут. Данный тест имитирует активную непрерывную работу 50 пользователей в течении 10 минут, что отражает предполагаемую максимальную нагрузку на Geoserver в текущих условиях.
  2. Стресс–тестирование — нагрузка большим числом пользователей, с целью определения условий отказа системы и автоматического восстановления её нормальной работы. В рамках данной работы также оценивается нагрузка на физические ресурсы системы.

6. Полученные результаты


  • Benchmark

График нарастания числа пользователей в данном тестировании приведен на рисунке ниже.

Как видно из графика, максимальное число одновременно работающих пользователей составило 68 человек.

При этом график среднего времени отклика представляет собой рисунок, приведенный ниже (на легенде вверху графика приведена расшифровка графиков запросов).

Как видно из графика среднего времени отклика, максимальное время отклика дает WFS запрос, что обусловлено необходимостью возвращения информации по ряду объектов в области и размеру этой информации. Максимальное время отклика остальных запросов не превышает 13 секунд. При рассматриваемой нагрузке в 50 пользователей время отклика не превышало 7 секунд.

Статистические данные теста приведены в таблице ниже.

Тип Запроса Число запросов Ср. время отклика, мс Мin время отклика, мс Маx время отклика, мс Процент ошибок Объем передаваемых данных, KB/с
WMS GetFeatureInfo Request 2114 2448 48 9556 0% 13.36
Close Scale Request 1133 4586 151 13155 0% 103.29
Far Scale Request 1172 4435 153 12392 0% 106.15
WFS GetFeature Request 809 6437 56 20130 0% 2683.23
ОБЩЕЕ 5228 3974 48 20130 0% 2905.06

Как видно из таблицы, среднее время отклика на запрос составляет 4 секунды, максимальное — 8 секунд, минимальное — меньше секунды.

  • Стресс-тестирование

Для проведения стресс-тестирования необходимо задать максимально жесткие условия для работы системы. Одним из таких условий является повышенное число обращений к системе.

При проведении долгосрочной четырехчасовой нагрузки, план которой приведен на рисунке ниже, была достигнута ситуация  полного зависания Geoserver по причине недостатка памяти.

На графике отражена модель нагрузки для каждого из запросов, таким образом общее число одновременно работающих пользователей следует воспринимать увеличенным вдвое (использовались только запросы  Close Scale Request и Far Scale Request).

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

Это произошло в момент, когда общее число пользователей, одновременно работающих с системой, превысило границу ~530 пользователей. Процессор на сервере в этот момент был задействован на 100%, также как и оперативная память. Спустя час работы после первого сбоя было решено остановить тест, поскольку ожидаемого освобождения памяти и восстановления работы системы не произошло.

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

После этого был проведен ряд коротких стресс-тестов длительностью в 10 минут, содержащих все 4 вида запросов и имеющих модель нагрузки, приведенную ниже.

Максимальное количество пользователей, работающих с Geoserver согласно плану составило 1000 пользователей.

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

Однако видно, что внесенные изменения в настройках сервера и Geoserver привели к тому, что спустя 5 минут система смогла восстановиться (произошло освобождение памяти) и часть последних запросов все же выполнилась успешно без ошибок.

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

Тип Запроса Число запросов Ср. время отклика, мс Мin время отклика, мс Маx время отклика, мс Процент ошибок Объем передаваемых данных, KB/с
Close Scale Request 1914 43571 1843 88746 61% 66,37
Far Scale Request 1865 44995 1047 88208 56% 69,84
WMS GetFeatureInfo Request 2099 39626 81 82473 65% 8,50
WFS GetFeature Request 1566 53136 644 141694 69% 1418,16
ОБЩЕЕ 7444 44828 81 141694 62% 1558,36

7. Повышение быстродейсвтвия


Поскольку основным показателем быстродействия системы, работающей с картографической информацией, предоставляемой из удаленного источника, является показатель времени отклика, была поставлена задача снизить имеющееся время отклика Geoserver.

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

Для пробы решено было провести нагрузку длительностью в 1 час с максимальным числом пользователей — 250 и всеми 2-мя видами запросов (используются только запросы Close Scale Request и Far Scale Request, поскольку только они будут использовать возможности кэширования). Модель этой нагрузки приведена ниже:

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

Ниже приведены результаты в виде графика среднего времени отклика и таблицы статистической информации.

Тип Запроса Число запросов Ср. время отклика, мс Мin время отклика, мс Маx время отклика, мс Процент ошибок Объем передаваемых данных, KB/с
Close Scale Request 2615825 91 1 30055 0% 4885,12
Far Scale Request 2566043 92 1 627 0% 992,63
ОБЩЕЕ 5181868 91 1 30055 0% 5877,65

Максимальное значение отклика составило 30 секунд против более чем минуты без кэша. Однако стоит учесть, что среднее время отклика было значительно ниже и составило 91 миллисекунду против более чем 40 секунд без кэша. Следовательно, можно сказать, что использование кэширования в сотни раз ускоряет процесс отображения тайлов.

8. Выводы и рекомендации


По результатам проведенных тестов можно судить, что Geoserver при правильной настройке является достаточно надежной системой, обеспечивающей неплохие значения отклика при высоких значениях нагрузки. Стоит отметить, что значения количества пользователей, рассмотренные в обоих тестах, характерны для значительно нагруженных систем. В реальности же активная одновременная работа с Geoserver будет вестись не более чем 10-20 пользователями. Речь идет именно о одновременной непрерывной, длительной работе.

Таким образом установлено, что можно использовать Geoserver в качестве поставщика картографической информации.

В качестве рекомендаций следует отметить, что Geoserver должен размещаться на высокопроизводительных ПК и скорость отклика напрямую зависит от их производительности.  Потому для хороших значений отклика и стабильности следует использовать мощное «железо» исходя из нормы 2 ядра процессора и 4 Гб оперативной памяти на 100 пользователей.

При выполнении этих условий обеспечивается нормальная работа пользователей. И, в случае работы 15 пользователей и менее, достигается время отклика, не превышающее секунды, что должно обеспечивать комфортную работу пользователей с картографическими данными.

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

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

Комментарии

Аватар пользователя Гость

Подскажите пожалуйста, а каким приложением проводили тестирование??

Аватар пользователя Ульянов Дмитрий

Тестирование проводилось с использованием Apache JMeter http://jmeter.apache.org/ и нескольких дополнений к нему для более удобного управления нагрузкой

Аватар пользователя Гость

Есть ли сравнение работы GeoServer с промышленным софтом, например, ArcGIS SERVER?

Аватар пользователя Ульянов Дмитрий

В интернете есть немало статей и подобных вещей на тему сравнения различных серверов работы с пространственными данными. Однако, все они конечно же на иностранных языках. Если вам интересно вот несколько из них:

http://www.esdm.co.uk/mapserver-and-geoserver-and-tilecache-comparison-s...

http://www.digital-geography.com/arcgis-server-vs-open-source-gis-soluti...

http://www.slideshare.net/gatewaygeomatics.com/wms-performance-shootout-...

http://comments.gmane.org/gmane.comp.gis.geoserver.user/22144

Ну и добавлю, что согласно большинству источников Geoserver, это такой твердый середнячок, умеющий более-менее всё, но одинаково хорошо. А вот Arc в сети не жалуют, отдавая предпочтение OpenSource, и аргументируя это именно показателями производительности, в том плане что цена/качество не очень оправдывается.

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

Но тут как говорится на вкус и цвет товарищей нет. Это как Window и Unix-платформы. Каждому своё

Аватар пользователя Ульянов Дмитрий

Ответы на вопросы по статье можно посмотреть по данной ссылке:

https://www.facebook.com/permalink.php?story_fbid=471380829667995&id=100...

Аватар пользователя Гость

Отличный обзор!
Не хватает обзора с построением кластера Geoserver'ов, это и есть решение распараллеливания нагрузки. Ждём!
Филиппов В.Г.

Отправить комментарий

Содержимое этого поля является приватным и не будет отображаться публично.
АНТИСПАМ
Этот вопрос задается для того, чтобы выяснить, являетесь ли вы человеком или представляете из себя автоматическую спам-рассылку.
X
Вы можете войти с зарегистрированным именем пользователя или вашим e-mail адресом.
Пароль чувствителен к регистру.
Загрузка