Ожидается высокий трафик на сайте.. Как управлять
Я ожидаю большого трафика на корпоративном веб-сайте, которым я управляю. В настоящее время веб-сайт размещен на общем хостинге godaddy.
Поскольку это будет IPO для моей компании-клиента, я не имею ни малейшего представления, какой будет трафик.
Как я должен планировать и на какой хостинг план я должен пойти в Godaddy или на любом другом хостинге.
Является ли облачные вычисления актуальными для этой ситуации. Какое было бы лучшее / экономически эффективное решение.
Сайт представляет собой очень маленькую CMS в классическом ASP и MsAccess DB.
Также предложите, если мне нужно проверить какие-либо проблемы, связанные с программированием, чтобы сделать сайт доступным во время большого трафика безупречно.
С уважением, солнечный
7 ответов
Ключом к выживанию от огромного притока трафика является увеличение количества одновременных запросов, которые вы можете обрабатывать, что означает: а) сокращение времени, необходимого для отображения страниц, чтобы вы могли быстрее обслуживать больше посетителей, или б) получение платформы хостинга, которая способен обрабатывать больше соединений.
Если вы ожидаете много медиа-трафика, виртуальный хостинг не для вас. По крайней мере, вам следует временно перейти на VPS или выделенный сервер - это критическое время для вашего бизнеса (и для вас), и вы не хотите проблем с веб-сайтом и электронной почтой.
Если у вас мало времени, я бы не советовал переходить на что-то вроде облака - вы не собираетесь масштабировать горизонтально настолько, насколько вам известно (но у меня почти нет опыта в этом - я могу ошибаться). Вам также, возможно, придется пройти через изменение DNS и смену хостов, что может быть травмирующим, в зависимости от групп поддержки с обеих сторон. Посмотрите, сможет ли Godaddy подключиться к выделенному серверу - это предоставит вам выделенное время процессора и оперативную память и выведет вас из среды, где вас потенциально могут отключить за влияние на других пользователей. Вы можете участвовать в этом плане только месяц или два - тогда вы можете принять решение, если переход на общий хостинг вам подходит.
Если у вас есть время переместить копию своего сайта на выделенный сервер, прежде чем переназначить DNS, вы должны посмотреть, сможете ли вы сравнить эту копию своего сайта до ее запуска, чтобы узнать, нужна ли вам дополнительная оптимизация или если вы потратите деньги на этого было достаточно. Вы можете использовать что-то вроде apache ab, если у вас есть доступ к Linux-машине (или вы можете получить дешевый Linux-VPS) - краткое руководство по этому вопросу можно найти здесь: http://www.cyberciti.biz/tips/howto-performance-benchmarks-a-web-server.html
Что касается других оптимизаций, SQL-сервер, вероятно, быстрее, чем доступ, и, возможно, может быть настроен на вашем выделенном компьютере или VPS. Вы захотите привлечь разработчиков сайта и посмотреть, смогут ли они реализовать какое-либо кэширование или оптимизировать базу данных, так как это сократит время, необходимое для отображения страницы и перехода к следующему посетителю.
Я думаю, что вам нужно определить высокий трафик / объем, и ожидаете ли вы, что MS Access DB будет общим ресурсом. Использует ли сайт SSL? Без дополнительных подробностей это звучит как рецепт сбоя, если одновременный доступ и конфликт на этой базе данных могут стать серьезным узким местом. Если база данных является только локальным ресурсом, т.е. не имеет общей пользовательской таблицы или чего-либо подобного, то вы можете распараллелить сайт в кластере / облаке. Приведенная выше рекомендация Джима - хороший шаг, если это так, хотя большинство веб-сайтов с поддержкой БД не масштабируются по горизонтали.
Если вы ожидаете всплеска трафика с небольшим предупреждением, зарегистрируйтесь с CDN. Что-то вроде SimpleCDN (дешево) или MaxCDN (лучше, намного дороже) можно включить только с помощью кредитной карты. Вам нужно будет внести некоторые изменения в DNS, чтобы справиться с этим, и вам потребуется выполнить некоторую настройку веб-сервера, чтобы включить кэширование для статических ресурсов (легко в IIS).
Затем, возможно, вы захотите добавить response.Expires, чтобы добавить заголовки Cache-Control на все ваши динамические страницы ASP, по крайней мере, на короткий срок, чтобы CDN тоже мог их кэшировать.
Наконец, если у вас есть время, создайте дамп MSaccess в качестве базы данных для вашего сайта и, по крайней мере, используйте бесплатный SQL Express. Существуют мастера изменения размера, поэтому они должны быть достаточно безболезненными и требовать минимального изменения кода.
Я согласен с другими, что это звучит как рецепт катастрофы. При проведении IPO вы хотите, чтобы веб-сайт вашей компании работал и был доступен для запросов средств массовой информации, инвесторов и для распространения вашего сообщения.
Это также звучит так, как будто у вас быстро заканчивается время. Лучшее решение в конечном счете состоит в том, чтобы очевидно спроектировать это. Но поскольку у вас мало времени, позвольте мне дать вам несколько советов.
Во-первых, бэкэнд MS Access станет первой точкой отказа вашего сайта. Тебе нужно сделать все статично и сейчас. Используйте HTTrack для загрузки отображаемого в данный момент кода вашего сайта. Затем извлеките части, которые имеет смысл извлечь (например, что-то, что вы динамически создаете через свою БД, например, биржевые котировки). Сделайте резервную копию файлов, находящихся в данный момент на вашем сайте, и замените их на "статическую" страницу, которую вы скачали.
Во-вторых, VPS может или не может быть достаточно для вашего сайта. Это полностью зависит от ожидаемого трафика, а в некоторых случаях оставаясь на вашем общем хостинге может быть лучше. Зарегистрируйтесь на выделенном сервере от надежного поставщика, который может гарантировать время установки. Вы будете платить больше, но вы должны спросить себя, стоит ли даже несколько сотен долларов, чтобы ваш сайт был доступен и доступен для потенциальных инвесторов. Я верю, что вы найдете ответ, что оно того стоит. Я также уверен, что вы можете найти кого-то, кто перенесет сайт, чтобы вы сделали это до IPO. Вы заплатите больше, но опять же, это стоит того, чтобы сделать это.
Одна вещь, которую вы, возможно, пожелаете рассмотреть, - это система управления обратным прокси / кешем / приложениями, такая как устройство Zeus ZXTM. Это не только обратные прокси-серверы / балансировки нагрузки, но и действительно хороший кеш, и что самое важное, он может либо передавать уровни нагрузки на ваши веб-серверы и / или серверы приложений (что позволяет им изменять свои ответы в зависимости от нагрузки), либо фактически может изменить страницы, проходящие через него, чтобы уменьшить нагрузку. В частности, они могут изменить размер страницы / вес при увеличении нагрузки. Веб-сайт BBC использует четыре / шесть таких устройств для управления всей своей производственной внешней веб-системой - когда происходит большое новостное событие, нагрузка возрастает, а сложность страницы снижается, а это означает, что огромное количество обращений считывается из кэша на 100%. Это действительно крутая система.
Многое из этого зависит от вашего кода и использования ресурсов. Если вы ожидаете большой объем трафика, ваше кэширование будет чрезвычайно важным.
Масштабирование обычно НЕ является аппаратной проблемой сразу. Аппаратное обеспечение - это бандит, который некоторые люди используют для исправления плохо написанного программного обеспечения.
Сделайте как можно больше статичного контента и поместите его на другой хост. Сложность кодирования для облачных вычислений принесет вам меньше пользы, чем чистый и оптимизированный веб-сайт.
Stackoverflow сам по себе является очень хорошим примером, у них был один веб-сервер, пока они не нарушали 1 миллион просмотров страниц в день. Сайт был очень популярен и несколько месяцев выживал на одном оборудовании.
Посмотрите на профиль вашего сайта и любые ограничения, которые у вас могут быть (например, как быстро вы можете обслуживать веб-страницы с вашей текущей базой данных). Также посмотрите на такие инструменты, как yslow, чтобы увидеть узкие места на стороне клиента.
Я бы порекомендовал вам посмотреть, чтобы создать сайт максимально возможное количество статических файлов (wget --mirror если нужно), и рассмотрите возможность подключения к периферийной сети, например AmazonF CloudFront.
Это были бы самые простые и дешевые вещи, которые позволили бы максимально повысить производительность в час.
Изменить: я настоятельно рекомендую отказаться от использования любой базы данных, точка. Если это просто CMS, то нет причин не создавать статические файлы и обслуживать их. например, Подвижный Тип.