Допустим, у меня есть приложение, которое позволяет клиентам создавать учетные записи и размещать на своем сайте форму, позволяющую людям создавать билеты. С участием 475 клиентов у кого есть сайты с формами. Они получают около 100 отправок форм в день на одну учетную запись (Всего 47500 билетов в день в среднем). Если предположить, что все это происходит только в течение 8 часов в день, то это всего лишь 1,6 или около того билетов в секунду.
Если я покупал балансировщик нагрузки, значит ли это, что мне нужен только тот, который может 5 SSL TPS? Мне это кажется смешным?
Среднее количество подключений в секунду не имеет значения; это пик, о котором вам нужно беспокоиться. Для этого вам нужна более точная статистика того, как будут выглядеть ваши шаблоны нагрузки. Если у вас этого нет, я обычно использую соотношение пик / среднее 4: 1 для 24-часового среднего (так что вы смотрите на 1,6 / 3 * 4` - 3, чтобы добраться до 24-часового среднее, 4 для получения пика от среднего - чуть больше двух соединений в секунду в пике).
Это соотношение, кстати, просто исходит из моего опыта работы с сайтами с географически локализованными базами пользователей (как вы предлагаете). У меня есть другие соотношения для глобальных баз пользователей и "известных пиковых" сайтов. Если вы возьмете наихудший случай, действительно пиковый сайт, я использую соотношение 10: 1, так что вы все равно просматриваете чуть больше пяти подключений в секунду.
Как говорит Эндрю, при такой громкости не стоит даже напрягаться на одной машине. У меня есть сайт, который обрабатывает несколько сотен HTTP (S)-соединений в секунду на каждую машину (динамический сайт с большим количеством SSL-соединений) - очевидно, это будет сильно зависеть от вашей кодовой базы, но если вы нужно балансировать нагрузку пять SSL-соединений в секунду, что-то очень, очень неправильно.
Лично мне не нравятся балансировщики нагрузки с ускорением SSL, поскольку, по моему опыту, они создают совершенно новое узкое место - когда ваш сайт станет достаточно популярным, ускоритель SSL не сможет поддерживать его (и при обновлении этих вещей происходит дорого). Я предпочитаю простой балансировщик нагрузки TCP, в котором я могу просто масштабировать свои серверные ВМ по мере достижения ими емкости (будь то из-за SSL-соединений или просто обработки запросов).
Ваша математика верна. Вам вообще нужен балансировщик нагрузки при таком объеме?