Выводы и основные заключения

В течение пяти тестовых запусков было очевидно, что недостаточно сформированный экземпляр базы данных в первом тестовом запуске заметно ухудшил производительность системы и пользовательский опыт. После того как экземпляр базы данных был правильно оценен в соответствии с рабочими нагрузками, коэффициенты ArcSOC :vCPU меньше влияли на время выполнения рабочих процессов. По таблице ниже мы видим, что соотношение ArcSOC :vCPU 1:1 вводило дополнительные времена ожидания (0,246 с) на рабочие процессы просмотра, но существенно не повлияло на редактирование (см. P99 Waits HS). Вероятно, это связано с загруженными ArcSOC на хост-сервер.

Соотношение 2:1 обеспечивало почти идентичное время выполнения рабочих процессов без значительных ожиданий, но при этом обеспечивало высокую загрузку памяти на ГИС-сервере ООН (82%). Соотношение 2:1 слишком высокое для этих версионных рабочих процессов редактирования, где максимальное количество ArcSOC на ГИС-сервере ООН достигает только 7. Поэтому, увеличивая количество ArcSOC на ГИС-сервере ООН, мы лишь тратим ресурсы сервера. Однако хост-сервер, поддерживающий рабочие процессы только для просмотра, легко поддерживал соотношение 2:1. ГИС-сервер ООН нуждается в большей памяти для поддержки соотношения 2:1 и выше. При 4:1 хост-серверу также требуется больше памяти.

Использование ресурсов

Мы пришли к выводу, что добавление большего числа экземпляров сервисов не привело к улучшению пользовательского опыта для редакторов, хотя это может повысить отзывчивость в рабочих процессах просмотра за счёт сокращения времени ожидания. Мы увидели, что даже не используемые ArcSOC всё равно потребляли ресурсы сервера. В таблице выше показано, что время рабочего процесса немного увеличивается по мере увеличения коэффициента ArcSOC : vCPU.

Это подразумевает, что дополнительные доступные ArcSOC не были необходимы для поддержки пользовательских запросов и излишне потребляли системные ресурсы (в основном память). Таблица выше подтверждает, что рабочие процессы редактирования не использовали дополнительные ArcSOC, но рабочие процессы просмотра с гораздо большим количеством операций в час — да. Таким образом, для нашей системы соотношение 2:1 между ArcSOC и vCPU было наиболее оптимальным для сервисов только просмотра на сервере хостинга, а 1:1 — для ГИС-сервера ООН.

Основные заключения

• Недостаточно сформированная база данных негативно повлияла на всю систему:

  • Для нашей системы мы определили, что больший размер экземпляра базы геоданных (16 vCPU) критически важен

  • ArcSOC, процессор ГИС-сервера и веб-адаптеры были заняты, из-за чего проблемы с производительностью казались системными

  • Время выполнения рабочих процессов занимало примерно вдвое больше времени с небольшой базой данных

  • Недостаточно сформированная база данных больше влияла на производительность, чем плохо настроенные экземпляры карт

  • Простое увеличение ресурсов базы данных значительно улучшило поведение и производительность системы

• При правильно сформированной базе данных увеличение соотношения ArcSOC (экземпляров картографических сервисов) к vCPU не улучшало пользовательский опыт и время выполнения рабочих процессов

• Добавление ненужных экземпляров сервисов может негативно сказаться на системе, потребляя ненужные дополнительные ресурсы

• Увеличение числа запущенных экземпляров карт повлияет на использование памяти ГИС-сервера, даже когда они не заняты

• Разделение рабочих нагрузок остаётся важным — функциональные сервисы, предоставляющие версионные данные, будут использовать больше памяти ГИС-сервера, чем сервисы только просмотра

  • Доступные ресурсы (CPU, RAM и дисковый ввод-вывод) в экземпляре базы данных значительно улучшили способность всей системы справляться с нагрузкой

• Как минимум, отслеживайте процессы базы данных, использование ArcSOC, ресурсы ГИС-сервера и пользовательский интерфейс, чтобы определить оптимальную конфигурацию для вашей системы, особенно после внесения изменений