Как стать автором
Обновить

Обращение к облачным хостинг-провайдерам и их потенциальным клиентам

Время на прочтение 3 мин
Количество просмотров 1.1K
Как очень правильно озвучил автор приведённой картинки, перед многими начинающими (и не очень начинающими) стоит проблема высокого входного порога на знание и понимание.


Непонятно выражаюсь?
Вот и мне, как неопытному молодому человеку с идеей, которая перевернёт мир, непонятно: откуда взять все эти количества GET, POST, INSERT, а главное CPU.

Есть масса решений этой проблемы


Например, публиковать стандартные кейсы типа «сайт на вордпрессе с 10к хостов в день генерирует вот такой профиль загрузки». Удобно? Да. Просто и недорого для хостера? Да. Широко применимо, точность оценки достаточна? Как отметил один из участников дискуссии в предыдущем посте, «один модуль в вордпрессе может повысить нагрузку на процессор в десять раз».

Можно давать демо-доступ (или, с другой стороны, купить у облачного хостера стакан семок погонять недорогой вариант начального уровня). Просто? Относительно. Широко применимо? Да, ведь сайт можно перенести туда целиком и прогрузить тестовым ab'ом. Удобно? Отнюдь нет.

И вот тут мне пришла в голову мысль, которая давно уже стучала пеплом Клааса в сердце


А если создать виртуальный сервер на хостере, залить туда сайт целиком и натравить на него стресс-тестер, но не извне, а изнутри? Если скормить стресс-тестеру не абстрактный список URLов и правил, а живой лог веб-сервера?

Для сайта такой тест не будет отличаться от реальной загрузки: можно даже не выключать защиту от DoS, банящую «прожорливые» адреса — ведь стресс-сервер может прикидываться для сайта всем интернетом целиком.

Этот стресс-тест не будет нагружать внешние каналы хостера (и тестирующего свой будущий сайт клиента), моделируя не сферического коня в вакууме, а реальный табун в вакууме «сверхбыстрых каналов», ведь нам в контексте обсуждаемой задачи требуется прежде всего не стресс-тест «на выносливость», а количество ресурсов, съеденных реальными клиентами на реальном сайте.

Этот тест можно запустить как «ускоренно», прогружая весь лог ASAP, так и на скорости 1 к 1, да и вообще на любой выбранной. Да, тестирование суточного лога займёт сутки, но так ли это мешает? Зато хостер может распланировать тест так, штобы максимальное количество запросов из лога было обработано в момент минимальной загрузки площадки. Более того, пока задержки не начинают влиять на логику работы самого сайта, такое тестирование можно заприоритезировать в минус бесконечность: ну, получат «виртуальные» пользователи свою страницу не за 2 секунды, не за 0.2, а за 22. Зато количество тактов CPU, запросов к базе, IOPS, трафика будет посчитано верно.

Входной лог можно и нужно править, моделируя слешдот-моменты (и сделать это достаточно просто — взять и подмешать копии реальных сессий с модифицированными IP-адресами).

Все шаги вполне прозрачны и понятны даже полному новичку.

Недостатков у этого способа масса


Это создаёт нагрузку на хостера, сравнимую с реальным хостингом. Минус выходные каналы, плюс выравнивание по суточной загрузке, плюс приоритеты — это всё равно съест CPU, IOPS и тому подобного на вполне реальные деньги.

Это достаточно трудоёмко в разработке: надо будет создать структуру виртуальных серверов, оторванную от интернета, заизолированную и уприоритезированную. Не ракетная хирургия, возможно, но разработка стоит денег.

Это поднимает немало вопросов по Персональным Данным — загрузка реальных логов на хостера, даже пропущеных через какой-нибудь обфускатор (который ещё надо разработать), есть дело тонкое.

Это налагает немало условий к клиенту: уже не просто стартапер, а мигрант с имеющимся сайтом и живым логом. Каковой лог ещё не с каждого шаред-хостера можно получить. «Неживой» лог трудно создать с нуля, не каждый сможет предугадать, какая часть сайта будет посещаться наиболее часто. Пресловутый «один плагин в вордпрессе» может сидеть на странице, куда заходит 1 пользователь из 1000 — а может на странице, где сидят 999 из 999 (а на остальные разделы они и не ходят вовсе).

Ну и, разумеется, далеко не всякий сайт можно перенести на облако простым копированием — то есть даже для того, штобы оценить стоимость хостинга, клиент-вебмастер должен потратить время и/или деньги на работу кодера по адаптации.

Есть вариант-паллиатив


Хостер выкладывает образ виртуалки (точнее, связку из двух машин, хостера и стрессера), который клиент запускает у себя на ноутбуке, на NASе, да на чём угодно — это уже вопрос для клиента-вебмастера.

Плюсы по сравнению с вышесказанным: нет утечки юзерских данных, нет расхода ресурсов хостера.

Минусы тоже вполне очевидны: во-первых, если у вебмастера домашняя машина справится с такой нагрузкой на сайт (хотя бы и в «очень низком темпе»), то ему, скорее всего, не нужен облачный хостинг. Во-вторых, утечка системы биллинга и собственно хостинга в предоставляемом образе виртуалки; однако можно отдавать урезанную версию, годную только для подсчёта ресурсов. В-третьих, надо очень тонко учитывать влияние виртуализации на неизвестном заранее железе.

Дополнительный бонус — возможность разработки под конкретную платформу хостера.



И последнее: оба варианта, как мне кажется, были бы полезны и для не-облачных хостеров.
Теги:
Хабы:
+27
Комментарии 57
Комментарии Комментарии 57

Публикации

Истории

Ближайшие события

Московский туристический хакатон
Дата 23 марта – 7 апреля
Место
Москва Онлайн
Геймтон «DatsEdenSpace» от DatsTeam
Дата 5 – 6 апреля
Время 17:00 – 20:00
Место
Онлайн