По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Одним из ключевых факторов, которые следует учитывать при разработке веб-сайта или веб-приложения, является пропускная способность, которая потребуется вашему сетапу для правильной работы.
Знание требований к пропускной способности поможет вам выбрать правильного хостинг-провайдера и составить план в соответствии с вашими потребностями.
В этом руководстве мы покажем вам, как рассчитать пропускную способность, необходимую для вашего веб-сайта или веб-приложения.
Что такое пропускная способность?
Пропускная способность представляет собой максимальную емкость данных, которые могут быть переданы по сети за одну секунду. Наименьшая единица измерения выражается в битах в секунду. С развитием технологий интернет-провайдеры теперь используют мегабит в секунду (Мбит/с) или гигабит в секунду (Гбит/с).
Пропускная способность - это термин, который описывает объем трафика между вашим сайтом и пользователями через Интернет. Не путайте пропускную способность со скоростью соединения, поскольку они не совпадают.
Пропускная способность против передачи данных
Термин пропускная способность иногда используется как синоним передачи данных. На самом деле это две очень разные вещи.
Пропускная способность определяет максимальный потенциальный объем данных, который вы можете передавать за единицу времени между вашим сайтом и пользователями. Этот термин отражает не фактические данные, которые вы передаете, а теоретический объем данных, который вы можете обработать за одну секунду.
С другой стороны, под передачей данных понимается фактический общий объем данных, которые вы передаете за период, обычно за месяц. Единицы измерения - килобайты (КБ), мегабайты (МБ), гигабайты (ГБ), а для больших приложений - терабайты (ТБ).
Важность пропускной способности
Расчет правильной полосы пропускания для вашего веб-приложения имеет решающее значение на этапе разработки и для обеспечения стабильной производительности. Обязательно учитывайте внезапные всплески трафика. Хорошее правило - на 50% превышать прогнозируемую потребность в пропускной способности.
Однако при выборе веб-хостинга расчет может показаться ненужным, поскольку большинство хостинг-провайдеров предлагают планы с «неограниченной» пропускной способностью.
Примечание: ваша система может со временем расширяться, и требования к пропускной способности могут возрасти. Поэтому выберите масштабируемый план, позволяющий при необходимости изменять пропускную способность.
Что такое неограниченная пропускная способность
Многие провайдеры рекламируют планы с «неограниченной» пропускной способностью. Эта формулировка подразумевает, что вы можете передавать столько данных, сколько вам нужно. Здесь веб-хостинг предлагает фиксированную ставку, которая упрощает покупку и поиск решения для хостинга.
Однако правда в том, что хостинговые компании не могут предложить действительно неограниченную пропускную способность. Затраты и технологические требования были бы слишком высокими для этого.
По этой причине планы с неограниченной пропускной способностью предлагают достаточную пропускную способность, чтобы удовлетворить потребности большинства клиентов. Таким образом, планы кажутся неограниченными для этих пользователей. В большинстве случаев обычные планы покрывают стандартные требования к веб-приложениям. Есть также планы для более продвинутых клиентов, обеспечивающие скорость, превышающую ту, которую предлагают обычные безлимитные планы.
Расчет требований к пропускной способности
Прежде чем рассчитывать требования к пропускной способности, вы должны знать средний размер страницы на вашем веб-сайте.
Чтобы определить размер, используйте тест времени загрузки и учитывайте данные как минимум для десяти страниц. Затем рассчитайте средний размер страницы для вашего сайта.
Имея эту информацию, вам необходимо учесть еще два элемента:
Количество посещений ваших страниц.
Дополнительная пропускная способность может потребоваться в случае всплеска трафика. Это предотвращает потенциальные проблемы с производительностью или даже простои.
Есть две формулы для расчета необходимой пропускной способности.
Требования к пропускной способности веб-сайта без скачиваний пользователем
Если ваш веб-сайт не предлагает посетителям загружаемый контент, используйте следующую формулу для расчета необходимой пропускной способности:
Пропускная способность = Средний размер страницы * Среднее количество просмотров страницы * Среднее количество посетителей в день * 30 * Избыточность
Средний размер страницы - это средний размер вашей веб-страницы.
Среднее количество просмотров страницы - среднее количество просмотров страницы на посетителя.
Среднее количество посетителей в день - среднее количество посетителей в месяц.
30 - число дней в месяце.
Избыточность - фактор безопасности для предотвращения скачков трафика. Диапазон от 1,3 до 1,8.
Расчет немного отличается, когда ваш сайт предлагает загружаемый контент.
Требования к пропускной способности веб-сайта со скачиванием
Чтобы рассчитать необходимую пропускную способность, когда ваш веб-сайт предлагает загружаемый контент, используйте следующую формулу:
Пропускная способность = [(Средний размер страницы * Среднее количество просмотров страницы * Среднее количество посетителей в день) + (Средняя загрузка в день * Средний размер файла)] * 30 * Избыточность
Новые параметры в этой формуле:
Среднее количество загрузок в день - представляет собой среднее количество загружаемых файлов в день.
Средний размер файла - это средний размер загружаемых файлов.
С помощью этого расчета вы знаете прогнозируемые требования к пропускной способности для пользовательских загрузок.
Любая программа – это набор инструкций, будь то добавление 2 чисел или отправка запроса по сети. Компиляторы и интерпретаторы берут понятный для человека код и переводят его на машинный язык, который может прочесть компьютер.
В компилируемом языке целевая машина переводит программу самостоятельно. В интерпретируемом языке исходный код не переводится самой машиной; его читает и выполняет другая программа (интерпретатор).
Подробное объяснение
Представьте ситуацию: вы решили приготовить хумус. Но имеющийся у вас рецепт написан на древнегреческом. У вас, как человека не знающего этого языка, есть два варианта.
Вариант 1: кто-то уже перевел этот рецепт на ваш язык. Поэтому вы (и любой человек, знающий ваш язык) сможете прочесть рецепт в переводе и приготовить хумус. Переведенный рецепт и будет компилированной версией.
Есть и другой вариант: у вас есть друг, который знает древнегреческий. Поэтому, решив приготовить хумус, вы пригласили этого друга к себе. Друг сидит рядом и переводит рецепт – строчка за строчкой, – а вы занимаетесь готовкой. Ваш друг – это интерпретатор (переводчик) для интерпретируемой версии рецепта.
Компилируемые языки
Компилируемые языки сразу переводятся в машинный код, который может выполнить процессор. В результате они выполняются быстрее и эффективнее, чем интерпретируемые языки. Кроме того, в таких языках разработчик лучше контролирует аппаратные средства (управление памятью, использование ЦП и т.д.).
Компилируемым языкам требуется дополнительный этап «сборки», при котором их сначала компилируют вручную. Каждый раз при внесении изменений вам нужно будет «пересобирать» программу. Вернемся к примеру с хумусом. Перевод рецепта делался до того, как попал к вам в руки. Если автор рецепта захочет изменить тип оливкового масла, то весь рецепт придется переводить заново, а затем повторно отправлять вам.
Примеры истинных компилируемых языков: C, C++, Erlang, Haskell, Rust и Go.
Интерпретируемые языки
Интерпретаторы проходятся по каждой строке программы и выполняют все команды. Если автор из нашего примера захочет заменить оливковое масло, то он просто зачеркнет старую запись и добавит новую. А затем ваш друг-переводчик сразу увидит это изменение и переведет его вам.
Интерпретируемые языки гораздо медленнее компилируемых. Но с появлением JIT-компиляции (динамической компиляции) эта разница начинает сокращаться.
Примеры популярных интерпретируемых языков: PHP, Ruby, Python и JavaScript.
Небольшое пояснение
В большинстве языков программирования есть компилируемые и интерпретируемые реализации, а сам язык необязательно относится только к компилируемым или интерпретируемым. Но для простоты и удобства их принято относить к тому или иному типу.
Например, Python можно выполнять как компилируемую программу или интерпретируемый язык в интерактивном режиме. А большинство инструментов командной строки, интерфейсов командной строки и оболочек чисто теоретически относятся к интерпретируемым языкам.
Плюсы и минусы
Плюсы компилируемых языков
Обычно программы, скомпилированные в машинный код, выполняются быстрее интерпретируемых. Это связано с тем, что при переводе кода в процессе его выполнения увеличивается потребление ресурсов, что, в свою очередь, замедляет программу.
Минусы компилируемых языков
Основные недочеты компилируемых языков:
нужно больше времени для завершения полной компиляции перед тестированием;
сгенерированный двоичный код зависит от платформы.
Плюсы интерпретируемых языков
Интерпретируемые языки более гибкие и чаще предлагают такие возможности, как динамическая типизация и меньший размер программы. Кроме того, исходный код программы выполняют интерпретаторы, поэтому сам код не зависит от платформы.
Минусы интерпретируемых языков
Самый главный недочет этих языков – скорость выполнения. Она обычно ниже, чем в компилируемых языках.
Многим организациям необходимо предоставлять и поддерживать большое количество удаленных офисов.
Например:
Розничные сети могут иметь сотни или даже тысячи магазинов по всему миру.
Региональный банк может иметь сотни отделений и тысячи банкоматов.
Когда поставщики услуг фиксированной частной телефонной связи предлагали свои услуги в любом масштабе, такого рода проблемы решались с помощью large-scale и hub-and-spoke сетей. На рисунке показана hub-and-spoke сеть.
Сеть, показанная на рисунке выше, на самом деле довольно мала: три узла в центре удаленных сайтов могут представлять сотни или тысячи дополнительных узлов. Во многих реализациях (особенно старых) каналы связи между двумя маршрутизаторами-концентраторами, A и B, и удаленными устройствами, такими как C и N, являются двухточечными. Это означает, что на концентраторе-маршрутизаторе должен быть настроен интерфейс для каждого удаленного маршрутизатора, фильтры маршрутизации, фильтры пакетов и любые конфигурации Quality of Service. Это не только серьезная проблема с точки зрения конфигурации, но также трудно поддерживать тысячи отдельных соседей с точки зрения использования процессора и памяти.
Чтобы уменьшить объем вычислительной мощности, необходимой для обслуживания такой сети, протоколы были изменены, чтобы исключить обработку удаленных узлов, как если бы они были частью дерева. Вместо этого, эти модификации позволили рассматривать эти удаленные узлы, как если бы они были выходными или тупиковыми сетями. Еще одним шагом на пути к упрощению создания таких сетей и управления ими было использование интерфейса point-to-multipoint (с соответствующей базовой технологией, такой как Frame Relay) на концентраторах-маршрутизаторах. Когда соединения с удаленными узлами настроены как point-to-multipoint, концентраторы-маршрутизаторы A и B обрабатывают все периферийные устройства так, как если бы они находились в одном сегменте широковещательной передачи (фактически, как сегмент Ethernet). Однако каждый spoke маршрутизатор по-прежнему рассматривает свое соединение с маршрутизаторами-концентраторами как соединение point-to-point. Даже с этими модификациями создание и обслуживание таких больших сетей все еще очень сложно. Необходимо проложить каналы на каждый удаленный узел и управлять ими, необходимо настроить удаленное оборудование и управлять им, необходимо управлять конфигурацией маршрутизаторов-концентраторов и т. д.
Программно-определяемые глобальные сети (SD-WAN) изначально были разработаны для решения этой конкретной задачи. Идея DMVPN, зародившаяся в Dynamic Multipoint Virtual Private Network (DMVPN) от Cisco, заключалась в использовании туннелируемой оверлейной сети, работающей поверх общедоступного Интернета. Это позволило удаленным узлам использовать локально доступное подключение к Интернету, а не покупать канал для каждого узла, а также сократить время настройки и обслуживания за счет автоконфигурации и других инструментов.
SD-WAN - это еще один шаг вперед в концепции сети over-the-top. Решение SDWAN обычно строится с использованием нескольких компонентов:
Специализированное устройство или виртуализированная служба для замены маршрутизаторов, обычно размещаемых в центральных и оконечных точках.
Модифицированная версия стандартного протокола маршрутизации для обеспечения доступности (и, возможно, одного из показателей жизнеспособности цепи) и передачи политик по сети.
Реализация либо IP-безопасности (IPsec), либо безопасности транспортного уровня (TLS) для обеспечения безопасной туннельной передачи между оконечными устройствами.
Контроллер для мониторинга состояния каждого виртуального канала, приложений, использующих канал, и количества полезной пропускной способности по сравнению с объемом трафика, а также для динамической корректировки потока трафика и параметров QoS для оптимизации работы приложений в over-the-top сети виртуальной сети.
Есть много разных способов реализации SD-WAN, например:
SD-WAN может заменить "последнюю милю". Вместо того чтобы устанавливать схему на каждом удаленном узле, вы можете использовать решения SD-WAN для достижения точки обмена или коллокации, а затем передавать трафик через более традиционную службу через провайдера обратно к маршрутизаторам-концентраторам (это форма backhaul).
SD-WAN может заменить весь путь от сети организации до удаленных узлов.
SD-WAN можно использовать для привлечения трафика в облачную службу, где может быть выполнена некоторая предварительная обработка или развернуты некоторые приложения, причем только трафик, который должен быть перенесен в сеть организации, переносится остальная часть пути в маршрутизаторы-концентраторы.
Существуют компромиссы с SD-WAN и другими передовыми решениями, как и с любой другой сетевой технологией. Например, передача трафика корпоративного удаленного узла через "обычное" публичное интернет-соединение (или пару услуг, или какую-то другую услугу, завершенную Ethernet) может быть "достаточно хорошей" в некоторых ситуациях, но провайдеры, как правило, лучше относятся к трафику в более дорогих услугах (что вполне естественно), особенно при отключениях.