Search
Write a publication
Pull to refresh

Comments 11

Подскажите будет ли предоставлены публичные апи как например в google workspace для возможности создания приложений сторонними разработчиками и размещения в вашем маркетплэйсе?

В этом году мы планируем реализовать открытый SDK для работы с Mailion (почта, календарь, контакты). API в данный момент не предоставляем
6081 RPS (операций в секунду).
которые суммарно были оснащены 636 процессорными ядрами

Выходит, 10 операций в секунду на ядро?

Спасибо за ваш вопрос. Подобный расчет нельзя считать валидным: стенд, на котором проходило нагрузочное тестирование, обладает заведомо большей мощностью, чем необходимо для обработки указанного числа запросов. Т.е. мощность стенда была взята с запасом и не использовалась в полной мере.
Нужен highload — ставь побольше ядер для обработки https трафика. Ставь балансер. Ставь побольше мощностей для базы данных. И получается что мощность зависит не от софта (конечно если он не криво написан, а сейчас с повсеместным async/await это уже трудно сделать), а от железа. Поэтому получается какая то подмена понятий.

Занимался нечто подобным.
Заинтересовала строчка:
6000 необходимых одновременных сопрограмм генератора для создания нагрузки.

Я конечно понимаю что это наверно так написано что бы статья пожирнее и по загадочнее выглядела. Но наверно в реале можно было бы запустить одну программу (по крайней мере в моём случае работало) которая запустит внутри хоть сколько угодно одинаковых потоков для DDOS атаки (конечно пока не упрётся в машинные пределы)?
Спасибо за ваш вопрос. Здесь всё дело в терминологии. По факту у нас действительно есть приложение, которое запускается в одном экземпляре и запускает 6000 потоков для нагрузки на стенд.

Не раскрыт вопрос,сколько ресурсов обслуживало данную нагрузку!

Нагрузку создавал один сервер — c 72 vCPU, 256 GB RAM, 8400 GB HDD, 2 774 GB NVMe

эмулировала процесс реального появления пользователей в системе

частота проверки почты пользователем — один раз в час.

У Вас странные пользователи эмулируются. Если имеется ввиду протокол pop3 - то многие почтовые клиенты имеют интервал проверки 5-15 минут, нередко выставляют частоту проверки в 1 минуту, что бы как можно быстрее получать почту. И на объемах ящиов >100 Гб почтовому серверу начинается веселье.

Тестирование LDA/MTA в контексте данного тестирования мне тоже кажется несколько странным - в любом опенсорс решении оно никогда особо не требовательно к ресурсам, в отличии от постоянной нагрузки от почтовых клиентов.

72 vCPU, 256 GB RAM, 8400 GB HDD, 2 774 GB NVMe

Использование такого железа скорее говорит о желании нивелировать узкие места избыточными мощностями.

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

Кроме общих слов, интереснее было бы чуть подробнее - имеется ли масштабирование, если да, то его сложность, и несколько тестов в подобном плане: "дано - сервер Xeon E5-2650 v3, нагружаем пользователями до предела - на столькои-то пользователях начинается деградация кач-ва, подключаем второй сервер, Эльбрус, масштабируем - и увеличиваем пользователей дальше, снова с хорошими показателями отклика, до 7k rps...".

Тут все-таки более технический ресурс, нежели место, где прокатит маркетинговая реклама и тестирования сферического коня в вакууме.

Вы правы насчёт почтовых клиентов и частоты обращений. Протокол POP3 мы не поддерживаем. Протокол IMAP с расширением IDLE позволяет клиенту эффективно получать push-уведомления о поступлении входящей почты без необходимости делать интервальные опросы сервера.

Тем не менее, наши исследования показывают, что размеры ящиков более 100 Гб используются для небольшого круга лиц в организации, а большая часть имеет квоты куда более скромного размера. По крайней мере, запросов от клиентов на инсталляцию в 600 тыс. пользователей с подобной квотой к нам ещё не поступало. Но мы готовы попробовать! ?

И напомним все же, что данное нагрузочное тестирование специально проводилось на стенде, приближенном к реальности.

Далее к вашим вопросам. «Использование такого железа скорее говорит о желании нивелировать узкие места избыточными мощностями» – и здесь вы тоже правы. Инженеры тестировали стенд, а не нагрузочные инструменты.

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

Однако текущее нагрузочное тестирование преследовало цели, описанные в статье — эмулировать полный рабочий день с нагрузкой в 600 тыс. пользователей.
Sign up to leave a comment.