Веб-сервер, принимающий до 800 запросов в секунду после отправки новостной рассылки, с относительно небольшим количеством просмотров / кликов новостной рассылки
У меня есть клиент, который отправляет еженедельную рассылку примерно 3000 получателям. Бюллетень построен с использованием около 50-100 изображений в зависимости от шаблона, который они используют (что, как я понимаю, ужасно эффективно, учитывая дизайн бюллетеня).
Однако до недавнего времени отправка заставляла их веб-сервер перестать отвечать на запросы, так как это был один веб-сервер, обрабатывающий запросы как статических ресурсов, так и PHP, в результате чего на веб-сервере заканчивались дочерние элементы Apache и он не мог быстро обслуживать довольно. Измеряя веб-сервер сразу после отправки, мы заметили следующее:
- Время выборки около 15 минут
- Постоянно более 300 запросов в секунду (подавляющее большинство - статические ресурсы, очень мало посетителей сайта)
- Пик около 800 запросов в секунду
- Прибл. 100 записанных просмотров новостей
- Около 50 зарегистрированных кликов по новостным рассылкам (большинство ведет к самому сайту)
Мы временно исправили проблему с помощью вторичного веб-сервера, предназначенного для обслуживания статических ресурсов, с более простой конфигурацией apache. Это привело к рассылке новостной рассылки, которую сам веб-сайт едва не задрожал.
Наше заблуждение связано с тем, что столь значительный всплеск запросов на статические ресурсы не соответствует количеству просмотров и кликов информационных бюллетеней, это кто-то еще видел, и есть ли другие способы справиться с таким трафиком? Я полагаю, что сокращение количества статических активов и отдельного веб-сервера статических активов должно помочь нам в этом, но я бы очень хотел объяснить это явление.
Спасибо за любой совет!
1 ответ
Прибл. 100 записанных просмотров новостей
И как это записано? Я бы посчитал количество просмотров, вставив не кешируемое изображение в новостную рассылку - но здесь это явно не так. Вы, конечно, не можете полагаться ни на SMTP DSN, ни на JavaScript.
Но я все же ожидал бы, что рядом "зрителей" будут сканеры вредоносных программ и сжимающие прокси (вы должны быть в состоянии определить из исходного ip / user agent).
(Кстати, не было бы дешевле поторопить доставку электронной почты или использовать CDN, чем внедрить новый сервер?)