В крупной компании почта почти незаметна. Она работает фоном. Тысячи пользователей подключаются к серверам, читают письма, отвечают на входящие, запускают рассылки. Всё это происходит одновременно, и каждый рабочий день выглядит одинаково.
Поэтому, если письма доходят, клиенты не зависают, а отклик сервера не «плывёт» в течение дня — система считается здоровой. Пользователи не жалуются. Администраторы не дёргаются. Почта просто есть.
Но у такого спокойствия есть обратная сторона. Когда система годами живёт в проде без инцидентов, доверие к ней строится не на цифрах, а на ощущении стабильности. Мы знаем, что она работает, но не всегда понимаем, при какой нагрузке потеряется устойчивость.
В какой момент фоновая нагрузка перестаёт быть фоном?
Начнут ли расти очереди сообщений?
Появится ли деградация отклика спустя несколько часов работы?
Всё останется предсказуемым, когда пользовательские сессии и поток доставки писем пойдут параллельно?
Привет, Хабр! Меня зовут Владимир Сергеев, я руководитель практики UC и ПО для совместной работы в К2Тех. Мы решили не гадать на кофейной гуще, а проверить это в измеряемых условиях, на сценарии, с которым почтовая система живёт каждый рабочий день, и протестировали наш почтовый сервер CommuniGate Pro под длительной смешанной нагрузкой, близкой к реальной эксплуатации.
Что именно мы тестировали и какие ожидания закладывали
Прежде чем запускать нагрузочный тест, стоит договориться о рамках. Мы не пытались выяснить, сколько сообщений в секунду способен обработать наш почтовый сервер. У любой системы есть предел, но в данном случае он нас не интересовал. Мы хотели воссоздать стандартное поведение в течение самого обычного рабочего дня.
В качестве ориентира взяли типичный корпоративный сценарий. Несмотря на рост мессенджеров и чатов, электронная почта всё ещё остаётся базовым каналом деловой коммуникации. По усреднённым оценкам, один офисный сотрудник обрабатывает порядка 60–70 писем в день без учёта спама. Если перенести этот профиль на инфраструктуру в 100 000 почтовых ящиков, что является показателем высоконагруженной системы в крупной корпорации, система должна ежедневно обрабатывать миллионы сообщений, включая неизбежные пики в рабочие часы.
Но для нас было важно не само число, а то, что за ним стоит. В таком режиме система должна просто держать нагрузку без роста очередей сообщений, деградации отклика и накопления других проблем. Поэтому мы не стали изолированно тестировать отдельные протоколы или компоненты, а смотрели на систему в целом. В тесте одновременно работали пользовательские сессии и доставка писем через SMTP и XIMSS, так что чтение и обработка сообщений шли параллельно с их отправкой.
Ниже показан упрощённый фрагмент такого взаимодействия. Он важен не деталями протокола, а тем, что иллюстрирует конвейерную и асинхронную модель работы, которая создаёт стабильную фоновую нагрузку на сервер даже без всплесков трафика.
Мы сознательно упростили сценарий теста и планировали поддерживать режим рабочей нагрузки без пауз. Если при таких условиях почтовый сервер поведёт себя предсказуемо и не начнёт деградировать, значит выбранная конфигурация подходит для корпоративного сценария, под который рассчитана.
Архитектура тестового стенда
Для теста мы заранее спроектировали распределённый стенд. Корпоративная почтовая система на нём разворачивалась так же, как это обычно бывает в эксплуатации. Поэтому архитектуру сразу разделили на фронтенд и бэкенд узлы. Фронтенд принимал пользовательские подключения, бэкенд отвечал за обработку и доставку сообщений.
Входящий трафик распределялся через отдельный балансировщик, что позволяло разнести приём соединений и основную обработку и посмотреть, как система поведёт себя при горизонтальном масштабировании.
Состав тестового стенда
Роль | Описание | Кол-во |
Фронтенд-серверы (FE) | Принимали пользовательские подключения и распределяли клиентские сессии. | 8 |
Бэ��енд-серверы (BE) | Обрабатывали и доставляли сообщения с возможностью горизонтального масштабирования. | 8 |
Серверы генерации нагрузки | Создавали пользовательскую активность и поток отправки писем, не участвуя в обработке. | 8 |
Серверы каталогов (AD) | Обслуживали аутентификацию и работу с учетными записями пользователей. | 3 |
NFS серверы | Предоставляли общее хранилище для почтовых данных. | 4 |
Балансировщик нагрузки | Распределял входящий трафик между фронтенд-узлами в отказоустойчивой конфигурации. | 1 |
Управляющий сервер (mgmt) | Управлял стендом и запуском тестов. | 1 |
Пользователи | Участвовали в нагрузочном тестировании | 100000 |
Пользователи | На один бэкенд-сервер | 13000 |
Для хранения данных мы взяли общее сетевое хранилище. Такой подход типичен для корпоративных почтовых систем и позволяет увеличивать вычислительные ресурсы и объём хранилища независимо друг от друга. Для теста было принципиально важно, чтобы нагрузка на диски не скрывалась за локальными оптимизациями и не искажала результаты.
Генерация нагрузки выполнялась с отдельных серверов. Они не участвовали в обработке почты, а только имитировали пользовательскую активность и отправку сообщений. Благодаря этому мы избежали конкуренции за ресурсы между тестовым инструментом и самой почтовой системой.
Конфигурация серверов
Роль | CPU | Memory | Disk | Network |
Балансировщик нагрузки | 16 Core | 16 GB | 100 GB | 1 Gb |
Frontend серверы (FE) | 8 Core | 16 GB | 100 GB | 1 Gb |
Backend серверы (BE) | 4 Core | 8 GB | 100 GB | 1 Gb |
NFS серверы | 8 Core | 16 GB | 125 GB OceanStor 400 GB SSD 100 GB | 1 Gb |
Серверы генерации нагрузки | 8 Core | 26 GB | 100 GB | 1 Gb |
Серверы каталогов (AD) | 8 Core | 16 GB | 90 GB | 1 Gb |
Управляющий сервер (mgmt) | 8 Core | 16 GB | 90 GB | 1 Gb |
Все компоненты стенда, за исключением сервисов каталога, работали под управлением Astra Linux. Что отражало типовой для отечественных организаций программно-аппаратный контур и позволяло рассматривать результаты тестирования в реальном эксплуатационном контексте.
В итоге стенд представлял собой не минимальную лабораторную конфигурацию, а полнофункциональную распределённую систему. Именно это позволило опираться на полученные цифры и рассматривать их как ориентир при проектировании и масштабировании корпоративной почтовой инфраструктуры.
Как формировалась нагрузка и какие сценарии мы воспроизводили
Для генерации нагрузки взяли Apache JMeter. Тест запускали распределённо с нескольких серверов, чтобы получить нужное число одновременных подключений и не упираться в ресурсы одного узла. Управление тестами велось с отдельного управляющего сервера.
В тесте одновременно шли два типа активности, характерные для реальной работы почтовой системы.
Первый сценарий отражал пользовательскую работу через XIMSS. Пользователи авторизовались, входили в систему, просматривали и обрабатывали сообщения. Для этого поддерживались постоянные XIMSS-сессии, которые оставались активными на протяжении всего теста и создавали стабильный фоновый поток операций.
Второй сценарий отвечал за отправку почты по SMTP. Он включал авторизацию пользователей и отправку писем с разным числом получателей. Именно этот поток создавал основную нагрузку на доставку сообщений и серверную часть почтовой системы.
Оба сценария работали одновременно и без пауз на протяжении всего теста. В результате пользовательские сессии и отправка писем шли параллельно и нагружали систему так же, как это происходит в рабочие часы в корпоративной среде.
Что показали измерения в ходе тестирования
После запуска тест шёл без пауз с постоянной смешанной нагрузкой SMTP и XIMSS. Пользовательские сессии и поток отправки сообщений работали одновременно: плотно, без разгонов и передышек, что позволяло наблюдать поведение системы в устойчивом режиме.
В первые минуты никаких сюрпризов. Интенсивность обработки быстро вышла на рабочий уровень и дальше держалась ровно. За промежуточный фрагмент времени, равный 4 часам, было выполнено 1 445 259 локальных доставок сообщений. Средняя интенсивность обработки составила около 100 сообщений в секунду. Эти значения сохранялись на протяжении всего теста без заметных провалов или всплесков, которые могли бы указывать на нестабильность или деградацию.
По мере работы мы следили за состоянием серверов. Мониторинг показывал стабильное использование ресурсов. Загрузка CPU и объём используемой оперативной памяти держались в пределах 50–60% и не росли со временем. Очереди сообщений быстро обрабатывались и держались близкой к нулевой отметке и оставались под контролем, даже когда тест шёл уже не первый час.
Важно было и то, как система вела себя с точки зрения отклика. Он не ухудшался по мере длительной работы, что как раз и было для нас ключевым признаком устойчивого режима, а не кратковременного удачного момента.
Надёжность системы обычно не видна сразу. Длительная работа под нагрузкой показывает, является ли это свойством устойчивости или просто удачным экспериментом.
Объём обработанных сообщений и расчёт эквивалентной нагрузки
За четыре часа теста при смешанной нагрузке SMTP и XIMSS система выполнила 1 445 259 локальных доставок сообщений. В среднем это соответствует интенсивности около 100 сообщений в секунду. Этот уровень сохранялся на протяжении всего прогона и не «проседал» со временем.
В более привычных единицах расчёт выглядит так:
общее время теста: 4 × 60 × 60 = 14 400 секунд
средняя скорость обработки: 1 445 259 / 14 400 ≈ 100,37 сообщений в секунду
Именно эту величину можно рассматривать как характеристику устойчивого режима работы системы.
Чтобы соотнести результат с реальной эксплуатацией, можно пересчитать аналогичный профиль нагрузки в месяц:
время за 30 суток: 30 × 24 × 3600 = 2 592 000 секунд
эквивалентный объём доставок: 100,37 × 2 592 000 ≈ 260 159 040 сообщений в месяц
То есть при зафиксированном в тесте режиме система способна обрабатывать порядка 260 миллионов локальных доставок в месяц.
Для ориентира можно взять и более консервативный сценарий, близкий к типовой корпоративной нагрузке. При уровне около 60 сообщений в секунду месячный объём составит:
60 × 2 592 000 = 155 520 000 локальных доставок в месяц
Такое сопоставление показывает, что при тестируемой конфигурации остаётся заметный запас по пропускной способности. Его можно использовать при росте числа пользователей, увеличении интенсивности переписки или перераспределении нагрузки в пиковые часы, в том числе для сглаживания отдельных нетипичных режимов эксплуатации, таких как массовые рассылки или всплески пользовательской активности.
Важно и то, как формировалась эта нагрузка. Часть операций шла через XIMSS и отражала действия пользователей в почтовых клиентах и веб-интерфейсе, другая часть — через SMTP и соответствовала отправке сообщений, в том числе с несколькими получателями. Поэтому полученные значения отражают не синтетический максимум, а работу системы при смешанном, близком к реальному, профиле нагрузки.
При этом тест показал и то, куда логично двигаться дальше. В первую очередь, продолжать оптимизацию использования ресурсов по мере роста нагрузки. Во вторую, расширять рекомендации по масштабированию для крупных инсталляций, где распределение ролей и запас по ресурсам начинают играть более важную роль.
Также очевидна ценность дополнительных тестов на отказоустойчивость и поведение системы при нетипичных, но практических сценариях эксплуатации.
Поэтому результаты этого теста — не окончательная оценка, а скорее точка текущего состояния платформы CommuniGate Pro. В базовом корпоративном сценарии она показывает устойчивое и предсказуемое поведение, при этом остаётся пространство для дальнейших проверок и уточнения границ применимости.
Что из этого следует для компаний, которые проектируют или обновляют почтовую инфраструктуру
При смешанной нагрузке SMTP и XIMSS пропускная способность CommuniGate Pro порядка 100 сообщений в секунду или 260 миллионов локальных доставок сообщений в месяц. По сравнению с типовым корпоративным профилем до 70 писем на пользователя в день это даёт запас пропускной способности порядка 25–45% в зависимости от сценария и распределения нагрузки.
Во время теста загрузка CPU и оперативной памяти оставалась стабильной, очереди сообщений сохранялись на постоянном уровне, как и отклик системы. Это говорит о том, что достигнутые значения соответствуют устойчивому рабочему режиму системы.
Данные получены для конкретной конфигурации и профиля нагрузки и не заменяют проверку под конкретный режим эксплуатации. Они показывают, как почтовый сервер CommuniGate Pro на базе Astra Linux ведёт себя при длительной смешанной нагрузке и какой запас ресурсов остаётся.
Делитесь в комментариях своим опытом:
Как вы обычно тестируете почтовые системы?
Какие компоненты почтовой инфраструктуры чаще всего становились узким местом?
Какие компоненты почтовых систем вы чаще всего ставите на мониторинг?
