Первые дни в сети: как не убить свой сайт


14

Предположим, у вас есть этот новый модный сайт с большим количеством данных (например, больших изображений), и вы собираетесь разместить его в сети. Если вы делаете «слишком много» рекламы, в течение первых дней сайт будет перегружен запросами.

Как я могу уменьшить этот риск?

Я думал о

  • постепенно, как SO и SF: «приватная» бета, публичная бета, публичная
  • разрешить X связи сеансов одновременно, так что подключенный пользователь все еще имеет хороший опыт работы с сайтом, а другие имеют приятное сообщение с извинениями

Я не могу

  • купите больше серверов, так как после первых дней на сайте будет намного меньше трафика :)

6
В мои 15 лет разработки и выпуска сайтов. Это то, что все думают ... положить новый сайт на мы и бум! Почти никогда не бывает. Обычно наоборот, что вы получаете меньше, чем ожидали. Но хех, слишком много пользователей - ХОРОШАЯ проблема;)
Чад Грант

1
У меня была эта проблема, и это не очень приятное место, чтобы быть ...
Габриэль Соломон

Ответы:


11
  1. Кеш как можно больше. Все страницы, которые создаются динамически, должны кэшироваться, чтобы пользователи получали статическую версию. В компонентах страницы, которые запрашивают БД, также следует кэшироваться.
  2. Попробуйте использовать внешний сервис, такой как Amazon S3, для обслуживания изображений и мультимедиа (или имейте его готовым к использованию, если на сайт внезапно попадает тонна трафика).

Постепенно начать жить можно для SOF и SF, потому что они уже пользовались популярностью и спросом благодаря популярности блогов Джеффа и Джоэла. Если у вас нет почти гарантированной базы пользователей, как у них, то постепенный запуск может быть фатальным.

Я бы не стал ограничивать одновременные сеансы, так как трудно определить конец сеанса, вызванный бездействием. Если пользователь уходит на 15 минут и пытается перезагрузить свою страницу, только чтобы получить сообщение об ошибке - вы просто потеряли пользователя.


Я имел в виду сеансы, но мои пальцы означали связи. Исправленный.
Матье

5

Сколько планирования ушло в вашу модель данных? Вы разработали схему, которая позволит вам увеличить объем запросов без дорогостоящих сортировок, двоичных столбцов или сложных объединений? Вы настроили свою базу данных (если она у вас есть)?

Как вы обслуживаете свои «большие изображения»? Можете ли вы разделить это на отдельный процесс веб-сервера, даже на отдельный домен?

Вы тестировали свою систему? Такие инструменты, как ApacheBench и Siege, бесценны.

Все ваши настройки в SVN? Ваше развертывание автоматизировано? Вы будете рады этому, когда вам придется выложить наше приложение на второй сервер.


Я согласился с нагрузочными тестами, у нас был веб-сайт, который мы пропустили, потому что у нас был сжатый срок, и он вернулся к нам в задницу. Пришлось немного поработать, пока сайт работал, чтобы снизить нагрузку на сервер до управляемого состояния (нагрузка на ЦП достигла 200% при выделенном сервере с 4 ЦП)
Габриэль Соломон,

1

Система приглашений иногда может быть хорошим способом контроля посещаемости сайта пользователями. Вначале раздайте определенное количество приглашений, чтобы сайт не перегружался. Затем дайте каждому пользователю несколько приглашений для передачи другим, медленно наращивая количество пользователей на сайте. Таким образом, вы не получите слишком много людей, посещающих сайт в начале, и вы не получите огромный пик трафика.

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


1

Я хотел бы убедиться, что у вас есть надежная инфраструктура мониторинга до запуска. Вам нужно иметь данные, на которых вы будете основывать свои решения - это означает, что вы измеряете нагрузку на ЦП на серверах, проверяете, равномерно ли распределяется ваша нагрузка по блокам, и что, если что-то тает, вы знаете, какое это было.

Знание, где проблема, значительно сократит время, необходимое для ответа. Я видел слишком много сайтов, запущенных без какого-либо мониторинга, с намерением, что они будут созданы позже ... после того, как пожар погаснет. Это глубоко неправильно.


1

Возможно, вы захотите посмотреть на сторонний хостинг статического контента, такого как Amazon S3. Возможно, в зависимости от вашего приложения было бы целесообразно использовать некоторые облачные сервисы (как бы я не ненавидел это модное слово) с помощью Amazon EC2.


Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.