Множественные обновления сервиса WEBO Pulsar

В течение последней недели идут большие изменения в архитектуре сервиса WEBO Pulsar, необходимые для стабилизации его работы (в связи со значительно возросшей нагрузкой) и требуемыми изменениями (например, проверка сайтов из множества точек по выбору пользователей). В ближайшее время - ориентировочно 1-2 недели - мы закончим внедрение всех возможностей и окончательно стабилизируем поведение сервиса. Приносим свои извинения за временные неполадки.

WEBO Scout — все о производительности вашего сайта



В WEBO Pulsar теперь встроен новый аналитический инструмент, а по сути, отдельный продукт — WEBO Scout. Сейчас можно не только контролировать реальное время открытия страниц в браузере, но и регулярно получать сводку о текущих проблемах производительности и советами о том, как исправить ситуацию.

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

WEBO Scout же оперирует реальными параметрами загрузки страниц в реальном браузере (пока это только Internet Explorer 8) и позволяет с высокой точностью узнать обо всех проблемах сайта, а также о возможном времени открытия страниц в случае ускорения сайта. Для оценки возможного ускорения мы автоматически применяем наш модуль WEBO Site SpeedUp, таким образом гарантируя максимальную точность полученного результата.

Все что нужно, чтобы получить эту информацию — перейти на страницу Отчеты в WEBO Pulsar, ввести имя сайта или страницы, которую вы хотите проверить и, выбрав нужный тип отчета, нажать кнопку Создать отчет. Отчет будет составлен в течение, буквально, пары минут, после чего будет доступен по постоянным ссылкам. При необходимости можно включить уведомления по e-mail о создании отчетов.

Типы отчетов

  • Простой отчет (пример). Простая проверка времени открытия сайта с расчетом возможного ускорения — быстрые базовые цифры для тех, кто хочет получить измеряемые KPI. Подойдет для регулярного контроля скорости сайта, например, до и после проведения работ по ускорению или при смене дизайна сайта. Стоимость такого отчета минимальна и составляет около 5 рублей.

  • Базовый отчет (пример). Этот отчет чуть сложнее, здесь больше технический данных: время ответа сервера из 4 точек без учета сетевых задержек, диаграмма загрузки файлов и ранжированные советы по увеличению скорости сайта. Такой отчет подойдет для более глубокого исследования проблем сайта и получения точного списка действий по ускорению сайта, причем все советы выстроены по приоритетам. Стоимость Базового отчета сейчас около 20 рублей.

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

Планы на ближайшее будущее

У нас масса идей о том, как улучшить WEBO Scout и разделить с вами тот обширный опыт, что мы имеем в аудите и ускорении сайтов. Надеемся, что вы будете ждать обновлений WEBO Scout с тем же нетерпением, что и мы.

WEBO Scout существует совсем недолго, и мы будем рады любым комментариям по его функционалу или внешнему виду. Любые ваши высказанные соображения для нас исключительно ценны. И конечно, мы уже традиционно поощряем всех активных участников бонусными пополнениями баланса.

Вместе мы делаем сайты быстрее и надежнее!

Как измерить время ответа сервера?

Как измерить время ответа сервера? Конечно, для этого можно использовать команду ping. Но у этого способа есть два существенных минуса. Во-первых, очень часто по соображениям безопасности сервера на ICMP-пакеты не отвечают. Во-вторых, практическую ценность такое измерение имеет очень редко. В самом деле, какая посетителю разница, что ICMP-пакеты до сервера и обратно идут 20 миллисекунд, если страница с каталогом товаров все равно генерируется 15 секунд. Дальше мы покажем, как можно вычислить время отклика сервера на примере протокола HTTP с использованием библиотеки cURL.

Библиотека cURL предоставляет следующую информацию о времени выполнения операций:
  • CURLINFO_REDIRECT_TIME — общее время, которое потребовалось для обработки всех перенаправлений. Каждое перенаправление в HTTP это по сути отправка запроса и получение данных. Таким образом для каждого перенаправления измерение времени лучше проводить отдельно. В дальнейшем будет предполагаться, что никаких перенаправлений не происходит (максимальное количество перенаправлений установлено в 0).
  • CURLINFO_NAMELOOKUP_TIME — время, прошедшее с момента начала выполнения запроса до определения IP-адреса сервера по его доменному имени. Для URL заданных по IP-адресу сервера будет равно 0. В дальнейшем это время нас также интересовать не будет, т.к. оно может сильно зависеть от географического положения пользователя и множества других факторов, которые выходят за рамки данной статьи.
  • CURLINFO_CONNECT_TIME — время, прошедшее с момента начала выполнения запроса до установления соединения с удаленным сервером (получение пакета TCP/ACK).
  • CURLINFO_APPCONNECT_TIME — время, прошедшее с момента начала выполнения запроса до установления SSL-соединения (в рамках данной статьи рассматривается протокол HTTP без SSL).
  • CURLINFO_PRETRANSFER_TIME — время, прошедшее с момента начала запроса до отправки HTTP-запроса.
  • CURLINFO_STARTTRANSFER_TIME — время, прошедшее с момента начала запроса до получения первого байта ответа от сервера.
  • CURLINFO_TOTAL_TIME — общее время выполнения запроса. Это время помимо прочего ззависит от пропускной способности канала пользователя, т.к. включает в себя время загрузки ответа сервера.

Что же из вышеперечисленного действительно представляет практическую ценность? Казалось бы, это STARTTRANSFER_TIME, но оно включает в себя все сетевые задержки. При переносе серверов или точки проверки это время может сильно измениться, но это не будет означать, что сервера стали хуже работать и дольше обрабатывать запросы пользователей.WEBO Pulsar позволяет измерять это время, и если вам интересно полное время, которое пользователь из конкретной географической зоны тратит на ожидание контента, нужно установить переключатель «Способ вычисления времени ответа» в положение «Полное время запроса» при редактировании проверки.

Временем, которое сервер затратил на генерацию ответа является STARTTRANSFER_TIME – PRETRANSFER_TIME, т.е. время, прошедшее между отправкой запроса и получением ответа. В случае с нулевыми сетевыми задержками это время и будет временем, затраченным сервером на генерацию ответа. WEBO Pulsar позволяет измерять и его. Для этого нужно установить переключатель «Способ вычисления времени ответа» в положение «Время обработки запроса сервером + время доступа».

А что же произойдет, если сетевые задержки ненулевые, как это обычно бывает? В этом случае между отправкой HTTP-запроса и получением его сервером пройдет какое-то время, например, t1. А между окончанием обработки запроса сервером и получением ответа пользователем — еще какое-то время t2. Тогда время, затраченное на генерацию ответа будет вычисляться по формуле (STARTTRANSFER_TIME – PRETRANSFER_TIME) – (t1 + t2). В случае, когда на генерацию ответа требуется значительно больше времени, чем на доставку ответа пользователю это некритично. Но если ваш сервер работает быстро и отдает ответ за 2-4 милисекунды, а сетевые задержки между серверами составляют 50 милисекунд, это может существенно повлиять на результаты проверки. Как же вычислить это самое (t1 + t2)?

В идеале для этого нужно использовать утилиту ping, которая покажет среднее RTT (round trip time — время, прошедшее между отправкой ICMP-пакета и получением ответа, которое будет очень близко к t1 + t2). Но в общем случае утилиту ping использовать нельзя, т.к. сервер может не отвечать на ICMP-пакеты. На самом деле, (t1 + t2) ~ (CONNECT_TIME – NAMELOOKUP_TIME). Почему? Потому что обычно между определением адреса сервера и установлением TCP-соединения нужно лишь отправить TCP/SYN пакет и дождаться TCP/ACK пакета.

На обработку TCP/SYN пакета тратится очень малое количество времени (иначе на сервере возникают серьезные проблемы), поэтому это время практически равно RTT. Если же в процессе установления соединения один из пакетов потерялся (на каком-нибудь из промежуточных узлов), то (t1 + t2) ~ (CONNECT_TIME – NAMELOOKUP_TIME)/2. Если потерялось 2 пакета - то делить нужно будет на 3 и т.д.

Чем больше пакетов было потеряно в процессе, тем меньше точность определения RTT. По умолчанию WEBO Pulsar определяет время ответа именно так. Если вычисленное время ответа оказалось отрицательным, это значит, что установление соединения заняло больше времени, чем обычный обмен TCP-пакетами. В этом случае, WEBO Pulsar предполагает, что для установления соединения понадобилось 2 обмена пакетами и делит (CONNECT_TIME – NAMELOOKUP_TIME) на 2. И так вплоть до 5, т.к. дальнейшее приближение уже не имеет смысла из-за сильного падения точности.

Не стоит забывать, что на любом из этапов RTT может отличаться (иногда достаточно сильно) от среднего. Получить точный результат, не имея доступа к серверу невозможно, но данный метод позволяет получить достаточно неплохие результаты. Именно этот метод, «Время обработки запроса сервером», по умолчанию использует WEBO Pulsar для всех проверок.

Весенний бонус

В связи с началом весны и скорым запуском проверки скорости загрузки сайтов в режиме реального времени (точно так же, как сейчас осуществляется проверки доступности ресурсов) мы увеличили баланс всех активных пользователей на некоторую случайную величину. Если бонус до вас по какой-то причине не дошел - пожалуйста, напишите по адресу pulsar@webo.name с указанием вашего логина от WEBO Pulsar - мы обязательно исправим ситуацию.

Быстрое пополнение баланса

В начале февраля мы ввели в работу новую систему для быстрой оплаты сервиса WEBO Pulsar. Теперь с помощью системы PayAnyWay вы можете за пару минут пополнить баланс любой суммой, на любое количество единиц, десятками разных способов. Причем, при использовании большинства способов оплаты, средства будут зачислены на ваш счет буквально за несколько минут. Достаточно трех простых шагов.
  1. Задайте сумму к оплате. На странице Баланса есть удобный калькулятор. Введенная сумма пересчитывается в единицы нашего сервиса и обратно. На той же странице есть сведения о текущих расходах, оценка срока, на который хватит текущих средств, история всех изменений счета. Все это позволяет легко спланировать расход ваших средств.
  2. Выберите способ оплаты. Вы можете легко оплатить услуги WEBO Pulsar с помощью электронных денег, банковской карты или платежных терминалов. Список доступных способов оплаты приведен ниже, а также на сайте PayAnyWay.
  3. Подтвердите оплату. В зависимости от выбранного способа оплаты, укажите в платежном шлюзе данные вашей пластиковой карты, введите платежный пароль, или распечатайте платежную квитанцию.
Доступные способы оплаты
  • Электронные системы
    • Монета.Ру
    • WebMoney
    • Яндекс.Деньги
    • MoneyMail
  • Банковские карты любого банка России или Европы
    • VISA
    • MasterCard
    • Maestro
  • Платежные терминалы
    • QIWI
    • Форвард Мобайл
    • CiberPay
    • NovoPlat
    • PLATiKA
    • pinpay.ru
    • МосКредитБанк
    • Элекснет
    • Comepay - PayAnyWay
  • Банковские системы
    • ФГУП «Почта России»
    • Банк24.ру
    • Банковский перевод
    • Contact
  • Салоны связи Евросеть
Есть вопросы или предложения? Мы всегда рады любым отзывам о нашей системе, напишите нам!