В данном случае не все эти серверы принадлежат Dennis Publishing, поскольку рекламу обслуживают разные провайдеры. Имейте в виду, что типичному одиночному серверу IIS будет сложно обслуживать более 400 HTTP-запросов в секунду, поэтому, если каждый новый посетитель создает более 200 запросов, легко увидеть, как приток нескольких тысяч посетителей может привести к тому, что ранее хорошо работающий сайт стал более эффективным. колени.
Теперь такие сайты, как ПК Про не работают на одном сервере, сайт оптимизирован для работы с большими объемами трафика, но если ваш сайт не имеет такой поддерживающей инфраструктуры, подумайте дважды, прежде чем просить таких, как мистер Фрай, написать твит о ты.
Эта проблема может усугубиться, если ваш сайт динамически генерирует свои страницы.
Эта проблема может усугубиться, если ваш сайт динамически генерирует свои страницы, что практически во всех современных CMS-системах. сайты делают — количество страниц, которые могут обслуживаться в секунду, более ограничено, чем для сайта, созданного с использованием статических HTML. Один из способов обойти это узкое место в производительности — включить кэширование страниц на сервере, что может привести к десятикратному увеличению количества обслуживаемых страниц в секунду практически бесплатно.
Единственным недостатком является то, что если содержимое конкретной страницы быстро меняется, пользователи могут некоторое время не видеть самую свежую информацию.
Однако для большинства сайтов это не будет проблемой; только такие сайты, как сайты спортивных результатов, должны с осторожностью использовать эту технику.
Другой очевидный способ увеличить производительность вашего сайта — увеличить количество физических серверов и построить из них ферму. Однако у этого подхода есть две проблемы: первая заключается в том, что оборудование балансировки нагрузки, которое вы используете, необходимость распределять HTTP-запросы между фермой серверов может оказаться дорогостоящей, если вы покупаете выделенный аппаратное обеспечение.
Загрузить решения
Однако есть более дешевое решение: установить на Linux-систему бесплатное программное обеспечение под названием HAProxy, который превратит этот блок в настраиваемый балансировщик нагрузки с возможностью переключения на второй блок, если вы желание.
Другая проблема большинства решений по балансировке нагрузки заключается в том, что запросы распределяются по серверам по циклическому принципу. ваше приложение использует сеансы для отслеживания переменных, они не будут работать во всей ферме, поскольку каждый запрос страницы будет обслуживаться другим сервер. Вам нужно будет спроектировать свой сайт так, чтобы такие переменные передавались через строку URL-адреса, которая имеет полезный дополнительный эффект, который дает ваше приложение. тогда вам не нужно будет размещать файл cookie в браузере пользователя, и поэтому вам не нужно будет спрашивать его разрешение на это (поскольку сейчас действует закон диктует).
Лазурное замешательство
Конечно, сейчас модный способ справиться с такими объемами трафика — разместить свой сайт в облаке. Учитывая огромное количество серверов, ожидающих предоставления вашего веб-приложения вашей нетерпеливой аудитории, неужели это не составит труда?
Ну, пожалуй: оговорка у меня касается сборов, которые зависят от уровня трафика и, следовательно, трудно прогнозируются. Если вы станете объектом попытки DDoS-атаки, это может стоить вам реальных денег, а в случае с Microsoft Azure таблица сборов является, мягко говоря, лабиринтом.
Я был заинтригован, получив недавно электронное письмо с объявлением о пересмотренной структуре оплаты за Azure, так что, возможно, теперь все будет проще. Некоторое время назад Microsoft сняла плату за загрузку контента на ваш сайт в Azure, что является улучшение, поскольку за базовые анализы, которые я проводил для нашей сестры, с меня брали более 90 фунтов в месяц. заголовок Облако Про.
В том же письме Microsoft заявила, что «повышает гибкость и простоту» своей структуры ценообразования для Azure. но за этим последовал напыщенный кусок текста, в котором пытались объяснить новые ставки, что, должен признаться, оставило меня несколько смущенный.
Пытаясь сделать возможной оценку стоимости хостинга через Azure, Microsoft создал калькулятор в сети, но есть большая оговорка об ее точности, с которой вы должны согласиться, прежде чем использовать эту страницу. Проблема с моделью ценообразования Azure заключается в том, что она основана на передаче данных и количестве транзакций для многих сайтов, и то и другое невозможно оценить заранее.
Структура ценообразования Azure выглядит так, как будто ее сплел самый опасный из существ — технически подкованный счетчик бобов.
В старые добрые времена хостинга через интернет-провайдера использовалась та же самая модель. Теперь, к счастью, стоимость большинства пакетов хостинга зависит от размера сервера, виртуального или другого, с неограниченной пропускной способностью — то, на что может рассчитывать любая компания.
Проблемы ценообразования
Структура ценообразования Azure выглядит так, как будто ее сплели самые опасные существа — «технически подкованные бобы». счетчик», и в результате основан на потребляемых технических ресурсах, которые мало влияют на реальные требования клиенты.
Я знаю, что Microsoft расскажет нам обо всех крупных компаниях, которые подписываются на Azure, но эти громкие имена часто заключаются сделки, которые отличаются от того, что предлагается публике, поэтому я отношусь к таким объявлениям с большой долей скептицизма.
Давай, Microsoft, собери свои коллективные мозги и придумай модель ценообразования, которая не обанкротит компанию и не обанкротит ее. оставить его без веб-сервера, потому что он израсходовал выделенные на этот месяц ресурсы, на которые компания может точно заложить бюджет, слишком.
Структуры ценообразования в облаке почти для всех других провайдеров более просты, и не полагайтесь на попытки определить, какой объем данных ваше приложение должно будет предоставить неизвестному количеству пользователей.
