Ожидание Интенсивного трафика на веб-сайте.. Как справиться
Ключ к выживанию крупного притока в трафике должен увеличить сумму параллельных запросов, которые можно обработать, который означает a) уменьшение время, которое требуется для рендеринга страниц, таким образом, можно служить большему количеству посетителей быстро, или b) получают платформу хостинга, которая способна к обработке большего количества соединений.
Если Вы ожидаете много трафика данных, совместно использованный хостинг не для Вас. Самое меньшее необходимо временно обновить до VPS или выделенного сервера - это - критическое время для бизнеса (и Вы), и Вы не хотите почтовая проблема и веб-сайт.
Если бы Вы коротки вовремя, я не рекомендовал бы переместиться во что-то как облако - Вы не собираетесь быть горизонтально масштабированием настолько далеко, как знают (но у меня нет почти опыта в том - я мог бы быть неправым). Необходимо было бы также потенциально пройти изменение DNS и изменение хостов - который может быть травмирующим опытом в зависимости от служб поддержки с обеих сторон. Посмотрите, может ли godaddy Вы до выделенного сервера - это предоставило бы Вам выделенное процессорное время и таранило бы и вытащило бы Вас из среды, где Вы потенциально собираетесь быть отключенными для влияния на других пользователей. Вы могли бы только быть на этом плане на месяц или два - затем можно принять решение, если движение назад к общему хостингу является правильным для Вас.
Если у Вас есть время для перемещения копии сайта к выделенному серверу прежде, чем повторно указать на DNS, необходимо видеть, можно ли сравнить той копии сайта, прежде чем это пойдет живое, чтобы видеть, нужна ли Вам дальнейшая оптимизация или если бросок наличных денег в нем был достаточно. Вы можете с чем-то как апачский ab, если у Вас есть доступ к машине Linux (или может захватить дешевый Linux vps) - краткое руководство по на этом может быть найдено здесь: http://www.cyberciti.biz/tips/howto-performance-benchmarks-a-web-server.html
Относительно другой оптимизации, SQL-сервер, вероятно, быстрее, чем доступ и мог, вероятно, быть установкой на Вашей выделенной машине или VPS. Вы захотите вовлечь застройщиков сайта и видеть, могут ли они реализовать какое-либо кэширование или если они могут сделать любую оптимизацию базы данных, поскольку они понизят время, оно берет, чтобы представить страницу и перейти на следующего посетителя.
Я думаю, что необходимо определить интенсивный трафик / объем, и ожидаете ли Вы, что дб доступа мс будет совместно используемым ресурсом. Сайт использует SSL? Без большего количества специфических особенностей это походит на рецепт для отказа, если что-нибудь параллельный доступ и конкуренция на том дб доступа могло бы быть серьезным узким местом. Если дб является локальным ресурсом только т.е. никакой общей пользовательской таблицей, или что-либо той природы затем Вы можете параллелизировать сайт через кластер/облако вообще. Рекомендация Jim выше является хорошим шагом, если это верно, хотя большая часть дб доступа отступила, веб-сайты совсем не горизонтально масштабируемы.
-
1MattyB: 1. " ожидаете ли Вы, что дб доступа мс будет общим resource" Доступ MS, который DB только, содержит данные для дисплея на веб-сайте. Я don' t получают значение совместно используемого ресурса. Я просто хочу использовать дб для веб-сайта только. Никакое параллельное соединение. Я сожалею, если я не характерен для Вашего запроса. – sunny 5 November 2009 в 14:52
-
2Я просто пытаюсь определить, является ли рассматриваемый дб Доступа зависимостью, совместно использованной через экземпляры веб-сайта, т.е. монолитной, или с другой стороны содержит данные это doesn' t должен быть совместно использован через веб-серверы. Таким образом, если бы у Вас было два веб-запроса, входят на двух различных веб-серверах, каждый запросил бы потребность получить доступ к тому же DB по сравнению с его собственной локальной копией. В любом случае существуют некоторые очень хорошие ответы в этом потоке, имеющем дело с веб-масштабируемостью. Я подчеркивал бы, что обычно архитектура/программная проблема не Ваши аппаратные средства, пока Вы не начинаете служить крупному объему. – MattyB 5 November 2009 в 15:18
Я рекомендовал бы надеяться генерировать сайт, максимизирующий количество статических возможных файлов (wget --mirror если Вы имеете к), и рассмотрите помещение его в граничной сети, как CloudFront Amazon.
Это были бы самые простые и самые дешевые вещи сделать и дать большую часть увеличения производительности на человеко-час.
Править: Я настоятельно рекомендую убежать от использования любой базы данных, период. Если это - просто CMS нет никакой причины не генерировать статические файлы и служить им. например, Подвижный Тип.
Большая часть этого сведется к Вашему коду и использованию ресурсов. Если Вы будете ожидать большой объем трафика, то Ваше кэширование будет чрезвычайно важно.
Масштабирование обычно сразу является НЕ аппаратной проблемой. Аппаратные средства являются лейкопластырем, который некоторые люди используют в попытке исправить плохо записанное программное обеспечение.
Сделайте такое же количество своего содержания столь статичным, как Вы можете, и помещать это на другой хост. Добавление сложности кодирования для облачных вычислений сделает меньше для Вас, чем наличие чистого оптимизированного веб-сайта.
Сам Stackoverflow является очень хорошим примером, у них был один веб-сервер, пока они не повредили 1 миллион просмотров страницы в день. Сайт был очень популярен и пережился в течение многих месяцев на единственной части аппаратных средств.
Посмотрите на свой профиль сайтов и любые ограничения, которые Вы можете иметь (как то, как быстро может Вы служить веб-страницам со своей текущей базой данных). Также изучите инструменты как yslow для наблюдения, где узкие места находятся на стороне клиента.
Одной вещью, которую Вы могли бы хотеть рассмотреть, является reverse-proxy/cache/application-management система, такая как устройство Zeus's ZXTM. Это не только reverse-proxys/load-balances, но и является действительно хороший кэш, и самое главное может любая обратная связь уровни загрузки к своим веб-серверам и/или серверам приложений (таким образом позволяющий им изменить их ответы на основе загрузки), или может на самом деле изменить страницы, проникающие через него для сокращения загрузки. Конкретно они могут изменить размер страницы / вес, когда загрузка увеличивается. Веб-сайт Би-би-си использует четыре/шесть из этих устройств для управления, это - все производство внешняя веб-система - когда существует большое событие, загрузка повышается, и сложность страницы снижается, означая, что огромное количество хитов читается 100% из кэша. Это - действительно прохладная система.
Если Вы ожидаете рост трафика с небольшим предупреждением, подписываетесь с CDN. Что-то как (дешевый) SimpleCDN или MaxCDN (лучше, более дорогие партии) может быть включено только с кредитной картой. Необходимо будет внести некоторые изменения DNS для обработки этого, и необходимо будет реализовать некоторую конфигурацию веб-сервера для включения кэширования для статических активов (легкий в IIS).
Затем Вы могли бы хотеть добавить ответ. Истекает для добавления заголовков Управления Кэша все страницы динамического ASP, по крайней мере, краткосрочные, таким образом, CDN может кэшировать их также.
Наконец, если Вы имеете время, выводите MSaccess как базу данных для Вашего сайта и используете свободную SQL Express по крайней мере. Там увеличивают мастера, таким образом, это должно быть довольно безболезненным и потребовать минимального изменения кода.
-
1Это начальные шаги... Я добавил бы, что после того, как Вы заканчиваете это препятствие, необходимо использовать счетчики производительности для обнаружения, где узкие места действительно и затем оптимизируют оттуда. Если Вы don' t имеют доступ к тем, которые через Ваш общий хостинг-аккаунт, it' s время для преуспевания к виртуальному серверу (или облачный сервер), по крайней мере. – rmalayter 28 January 2010 в 15:53
Я соглашаюсь с другими, что это походит на залог провала. С IPO Вы хотите, чтобы веб-сайт Вашей компании возрос и доступен для запросов медиа, инвесторов и получил Ваше сообщение там.
Это также кажется, что у Вас быстро заканчивается время. Лучшее решение в конечном счете состоит в том, чтобы, очевидно, спроектировать это. Но так как Вы коротки вовремя, позволяете мне давать Вам некоторый быстрый совет.
Во-первых, бэкенд Доступа MS будет первым местом ошибки Вашего сайта. Необходимо получить все статическое, и теперь. Используйте HTTrack для загрузки в настоящее время отображаемого кода веб-сайта. Затем выньте части, которые имеет смысл вынимать (например, что-то, что Вы динамично создаете через свой DB, биржевые цены, например). Копируйте файлы в настоящее время на Вашем сайте и заменяйте их "статической" страницей, которую Вы загрузили.
Во-вторых, VPS может или не может быть достаточным для Вашего веб-сайта. Это полностью зависит от трафика, который Вы ожидаете, и в некоторых случаях остающийся на Вашем общем хостинге могло бы на самом деле быть лучше. Зарегистрируйтесь в выделенном сервере от доверяемого поставщика, который может гарантировать время установки. Вы заплатите больше, но необходимо спросить себя, если это стоит даже несколько сотен долларов, чтобы иметь Ваш веб-сайт и доступный потенциальным инвесторам. Я полагаю, что Вы найдете, что ответ, что это определенно стоит того. Я также уверен, что можно найти, что кто-то перемещает сайт для Вас, чтобы сделать его перед IPO. Вы заплатите больше, но снова, это стоит того, чтобы сделать его.