Как проверить скорость ответа сервера

В статье рассказывается:       

1. Зачем проверять скорость сервера
2. Какие показатели скорости сервера нужно оценивать
3. Нормальное время ответа сервера – сколько
4. Сервисы для проверки
5. Как увеличить скорость ответа сервера

6. Пройди тест и узнай, какая сфера тебе подходит:
   айти, дизайн или маркетинг.

   Бесплатно от Geekbrains

Для повышения позиции сайта в рейтинге выдачи поисковых систем особое внимание следует уделить таким факторам, как скорость ответа сервера, время загрузки контента, размер кода и его качественные характеристики. Эти моменты с точки зрения успешного продвижения интернет-ресурса идут на втором месте после качества и уникальности тексов, а также наличия необходимой ссылочной массы. Чтобы ваш сайт продвинулся на верхние позиции в поисковой выдаче, следует ответственно подойти к вопросу оптимизации скорости ответа сервера.

Зачем проверять скорость сервера

В зависимости от того, как долго загружается контент интернет-страницы, посетитель принимает решение, будет ли он просматривать его или перейдет на сайт конкурентов, где более высокая скорость загрузки сайта.

Приведем простой пример для двух интернет-магазинов, ориентированных на продажу бытовых пылесосов. Один из них (сайт А) открывается для пользователя 400 мс, а второй (сайт В) 5 секунд. Есть высокая вероятность, что потенциальный покупатель, зайдя на сайт В, из-за своей нетерпеливости не будет ждать, пока загрузится страница интернет-магазина А. Этот пример показывает, что низкая скорость ответа сервера становится причиной существенной потери прибыли.

Зачем проверять скорость сервера

В результате исследования, которое проводила компания Skilled.co, было выяснено, что 4 из 5 посетителей медленных сайтов больше не возвращались на такие ресурсы. Причиной этого выступала низкая скорость загрузки.

Какие показатели скорости сервера нужно оценить

Чтобы проанализировать скорость ответа сервера можно воспользоваться двумя вариантами:

TTFB

Название этого метода происходит от фразы «Время до получения первого байта» (Time-to-first-byte). Другими словами, речь идет о временном отрезке от начального обращения посетителя к серверу, до получения ответа и отправки первых данных. Такой показатель можно рассматривать, как время наступления стадии, на которой интернет ресурс начинает отправку информации браузеру относительно разметки и контента страницы.

Полученная величина демонстрирует скорость ответа сервера. При более низком ее значении посетитель быстрее получит отклик на свой запрос. Нормальный показатель не должен превышать 400 мс, но в идеале его следует снизить до 100 мс.

Дозагрузка страницы

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

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

Получив эту информацию, можно провести переработку кода с целью оптимизации базы данных.

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

Нормальное время ответа сервера – сколько

Чем меньше ждать, тем лучше.

• Ответ до трехсот миллисекунд считается отличным результатом. Можно быть спокойным.
• Ответ сервера от трехсот до семисот миллисекунд тоже неплохой результат, не стоит беспокоиться.
• В случае, если время ответа сервера около секунды или более, нужно работать над повышением скорости загрузки сайта.

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

Стоит отметить, что скорость ответа сервера будет влиять не только на то, как пользователи воспринимают ваш сайт.

Задержки с загрузкой страниц всегда вызывают раздражение посетителей, но и поисковые системы будут понижать такой ресурс в рейтинге выдачи.

Сервисы для проверки

Существует несколько сервисов, работающих в онлайн-режиме, способных проверить скорость ответа сервера.

Яндекс.Вебмастер

Основные данные о производительности сайта предоставляет сервис Яндекс. Вебмастер. Регистрация для этого не требуется. Нужно лишь вставить в нужную строку ссылку для проверки, и бот Яндекс-системы определит скорость ответа сервера.

Топ-30 самых востребованных и высокооплачиваемых профессий 2023

Поможет разобраться в актуальной ситуации на рынке труда

Подборка 50+ ресурсов об IT-сфере

Только лучшие телеграм-каналы, каналы Youtube, подкасты, форумы и многое другое для того, чтобы узнавать новое про IT

ТОП 50+ сервисов и приложений от Geekbrains

Безопасные и надежные программы для работы в наши дни

pdf 3,7mb

doc 1,7mb

Уже скачали 21156

1. Вставляем ссылку в поисковой строке на основной странице.
2. Нажимаем «Проверить».

Сервисы для проверки

Система предоставит все основные данные о сервере. Основное на что следует обратить внимание – скорость ответа.

Яндекс.Метрика

Сервис Яндекс.Метрика представляет развернутый отчет по анализу скорости ответа сервера. При этом все данные достаточно достоверны, потому что система учитывает местоположение пользователей и используемые ими устройства.

Что нужно сделать, чтобы проверить скорость ответа сервера?

• Открываем Яндекс. Метрику и находим свой сайт.
• Ищем раздел «Отчеты».
• Находим подпункт «Стандартный отчет».
• Переходим в «Мониторинг».
• Заходим в раздел «Время загрузки страниц».
• Определяем период времени, в котором нам нужно узнать данные.
• Выбираем вид трафика.
• Затем листаем немного ниже и определяем нужные показатели, по которым будет сформирован отчет. К примеру, это может быть пункт «Ответ сервера».

Bitcatcha

Этот ресурс более простой. Он определяет скорость ответа сервера в разных странах. Регистрироваться, подключать плагины и переживать по поводу других заморочек вам точно не стоит. От вас требуется вставить ссылку на свой сайт в нужное поле и нажать на значок «Лупа». Система предоставит вам всю информацию о времени ожидания в различных уголках земного шара.

WEBO Pulsar

Представляет собой очередной бесплатный портал, функционал которого довольно прост в использовании. Этот сервис чем-то напоминает Bitcatcha, однако предоставляет намного больше полезных данных о работе сайта. Это отличный вариант для тех, кто хочет получить полный отчет.

• На этом портале можно наблюдать за скоростью ответа к серверу одновременно с нескольких стран.
• Узнать время, которое было потрачено на формирование зашифрованного соединения.
• Время, когда сервер отвечает на запрос клиента. (TTFB). Чем оно ниже, тем качественнее будет работа сервера.
• Количество информации, которую ресурс передал изначально.

Только до 12.06

Скачай подборку тестов, чтобы определить свои самые конкурентные скиллы

Список документов:

Тест на определение компетенций

Чек-лист «Как избежать обмана при трудоустройстве»

Инструкция по выходу из выгорания

Чтобы получить файл, укажите e-mail:

Подтвердите, что вы не робот,
указав номер телефона:

Уже скачали 7503

GTmetrix

Сейчас этот софт также популярен в России, хотя на нем не наблюдается ни единого узла для проверки времени ожидания ответа сервера именно в РФ. Однако для наблюдения за другими странами он подходит.

Как увеличить скорость загрузки сайта

Время ответа сервера

Чтобы улучшить показатель скорости ответа сервера советуем выполнить ряд шагов:

• Подобрать надежный хостинг с хорошим сервером и качественными каналами связи.
• Взять в аренду выделенный сервер.
• Пользоваться кэшированием данных.
• Провести оптимизацию базы данных.
• Применять кэширование скриптов.
• Устранить обращения к сторонним серверам.

Кеширование

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

К примеру, при переключении страниц, изображение логотипа сохраняется в системе пользователя. Отметим, что пользователь может запретить кеширование. Срок хранения кэша на компьютерном устройстве может варьироваться. Google имеет возможность снизить рейтинг ресурса, если сроки хранения данных будут не достаточно продолжительными. Настроить этот параметр можно при помощи файла дополнительной конфигурации htaccess.

Как увеличить скорость загрузки сайта

Картинки

Размещайте картинки с оптимальным размером, соответствующим особенностям онлайн-страницы. Необходимо предварительно уменьшить все фото и рисунки до тех параметров, в которых они будут отображаться на сайте.

В соответствии с рекомендациями Google PageSpeed Insights для изображения лучше выбирать формат WebP. Учитываете, что его не поддерживает такой ресурс, как Яндекс. Картинки. В связи с этим, если направленность вашего интернет-ресурса предполагает многочисленные переходы с сервиса Яндекс.Картинок, есть смысл применять форматы PNG и JPG, сжимая картинки по максимуму, и не допуская потери качества.

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

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

Скрипты и CSS

Мы уже отмечали ограниченность числа потоков загрузки. При этом, любой скрипт или CSS занимают отдельные потоки. В связи с этим возникает необходимость снижения количества одновременных загрузок таких элементов страницы. Реализовать такую задачу, используя следующий алгоритм:

1. Отключите ненужные скрипты и CSS. Нередки ситуации, когда некоторые из таких элементов уже длительное время не используются, но остаются на страницах и при загрузке занимают потоки. Рекомендуем проанализировать все CSS и скрипты, чтобы отключить неработающие.
2. Все используемые CSS следует собрать в одном файле, чтобы сократить число потоков загрузки.
3. Среди рекомендаций сервиса GooglePageSpeed Insights есть указание к сведению в единый файл всех скриптов. На практике реализация такой идеи невозможна. Чтобы увеличить скорость ответа сервера можно использовать асинхронную или отложенную загрузку скриптов. При таком подходе не блокируется последующая обработка контента. Выполнение скрипта в первом случае происходит после его загрузки, а во втором, после того, как откроется вся страница.

Продвижение блога — Генератор продаж

Рейтинг: 5

( голосов 1 )

Поделиться статьей

Проверка времени ответа сервера — что это, каким должно быть, как улучшить

На что влияет время ответа сервера?

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

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

Проверить время ответа сервера вы можете с помощью специального сервиса от Яндекса или с помощью виджета, расположенного ниже.

Виджет предоставлен сайтом calcus.ru

 

От чего зависит время ответа сервера

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

Не существует универсального способа сократить время ответа сервера. В каждом случае должен быть индивидуальный подход к оптимизации нагрузки.

Нормальное время ответа — это сколько?

Чем меньше, тем лучше.

• До 300 миллисекунд — очень хороший результат, можно спать спокойно.
• От 300 до 700 миллисекунд — тоже неплохо, волноваться повода нет.
• Если время ответа вашего сайта приближается к секунде, или ещё выше — повод принимать меры.

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

Коды ответов HTTP

Код состояния HTTP — это число, состоящее из трех цифр. Первая цифра означает группу, к которой принадлежит код.

Существуют следующие группы:

• 1xx — Информационные коды
• 2xx — Успешные коды
• 3xx — Коды перенаправлений
• 4xx — Коды ошибок клиента
• 5xx — Коды ошибок сервера

Проверка 304 Not Modified

Правильно настроенный сервер должен обрабатывать заголовок If-Modified-Since. Этот заголовок содержит дату и спрашивает, была ли изменена страница после этой даты. Если страница не была изменена, сервер должен вернуть ответ 304 Not Modified. При этом ответ содержит только заголовки и не содержит тело страницы. Это значительно экономит время и трафик при обходе вашего сайта поисковыми роботами.

Помимо этого, для корректной работы этой схемы сайт должен на каждый GET-запрос возвращать заголовок Last-Modified, содержащий дату последнего изменения страницы. Браузеры и поисковые роботы сохраняют эту дату и при следующем запросе используют именно её для заголовка If-Modified-Since — как бы спрашивая, изменилась ли страница с тех пор, нужно ли её скачивать заново.

Была ли наша статья полезной?

Спасибо за отзыв!

Что такое ТТФБ? Как оптимизировать время отклика сервера

Одним из наиболее проблемных аспектов повышения скорости веб-сайта является исправление ошибок, которые говорят вам сократить время до первого байта (TTFB). В этой статье я постараюсь сообщить вам о том, как минимизировать проблему TTFB. Кроме того, я расскажу больше о важности выбора сервера и хостинга для SEO.

TTFB — это период, измеряемый между запросами клиента (HTTP и HTTPS) и первым байтом веб-сайта.

Хорошее значение TTFB очень важно для оптимизации скорости веб-сайта.

TTFB может сильно различаться в зависимости от типа контента (статического или динамического), которым вы делитесь, конфигурации вашего сервера и т. д. Вот почему сложно ответить на вопрос «какое значение TTFB является хорошим?» и это зависит от статуса вашего сайта.

Если значение TTFB примерно меньше 100 мс, это отличное значение. В то время как значения от 200 до 500 мс считаются средними, значения от 500 мс до 1 с могут вообще не считаться идеальными. В некоторых случаях, в зависимости от типа веб-сайта или страницы, значение TTFB может быть неизбежно больше 1 секунды.

Если вы видите эту ошибку в результатах Page Speed, это означает, что значение превышает 600 мс:

Вы можете проверить среднее время ответа сервера в статистике поиска Search Console:

Если у вас есть общий сервер или использовать несколько веб-сайтов на одном сервере, объем веб-сайтов может варьироваться в зависимости от других веб-сайтов на серверах. Конечно, нельзя путать TTFB со временем отклика сервера.

Вот основные факторы, замедляющие значение TTFB:

●  Плохо сконфигурированная структура сервера,

●  Проблема мощности сервера (пропускная способность, оперативная память и т. д.),

●  Динамически создаваемый контент,

●  Вопросы по базе данных.

В результатах Page Speed ​​Insight может появиться ошибка/предупреждение, например «уменьшить время до первого байта»:

Вы можете запустить Lighthouse:

Вы также можете измерить значения TTFB в Google Chrome Сеть:

Вы также можете запустить тест TTFB здесь: https://gtmetrix.com/.

Вы также можете четко контролировать процесс с помощью визуализации скорости:

В этом случае вам также будет полезен этот веб-сайт https://www.webpagetest.org/:

Вы также можете проверить на ежемесячно обновляемом веб-сайте: https://ismyhostfastyet.com/. На основе данных Chrome UX в следующей таблице представлены подробные сведения, в том числе их значения TTFB и количество веб-сайтов, которые у них есть:

Существует несколько способов оптимизации значения TTFB. Предлагая многие из них, я должен предупредить вас о ситуациях, в которых вам, возможно, придется усердно работать с хостинговой компанией или командой разработчиков.

Кэш

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

Если у вас есть веб-сайт, такой как WordPress, вы можете использовать такие расширения, как W3 Total Cache или LS Cache.

Использование HTTP/2

Googlebot обычно сканирует HTTP/1. Однако с ноября 2020 года Search Console начала отправлять сообщения владельцам веб-сайтов, если они могут использовать HTTP/2, говорится, что ваш веб-сайт может быть просканирован в этой версии:

Вы можете определить источники, используя HTTP/2 с Chrome:

Использование CDN

Вы можете оптимизировать значения TTFB с помощью CDN. Если у вас есть веб-сайт с интенсивным трафиком, CDN может стать идеальным решением для более быстрой загрузки источников.

Оптимизация базы данных

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

Если вы используете Cpanel, вы можете увидеть неиспользуемые базы данных и пользователей базы данных и удалить некоторых из них, если они подходят:

Пример пользователей Mysql:

Если вы используете WordPress, с помощью PhpMyAdmin вы можете проверить таблицы, оставшиеся от старых расширений. Таким образом, вы можете уменьшить нагрузку на базу данных, вызванную неиспользуемыми расширениями:

Например, я вижу пустые структуры таблиц в следующем порядке:

выберите table_schema как имя_базы_данных,

    имя_таблицы

   из информации_схемы. таблицы

где table_type = ‘BASE TABLE’

   и table_rows = 0

   и table_schema не в (‘information_schema’, ‘sys’,

                          ‘Performance_schema’, ‘mysql’)

   — и table_schema = ‘sakila ‘ — введите здесь имя вашей базы данных

в порядке table_schema,

      table_name;

Когда я запускаю SQL, он показывает мне результаты:

Результаты SQL могут отличаться от веб-сайта к веб-сайту. В этих примерах вы можете увидеть большее или меньшее количество табличных структур. Прежде чем перейти к этим шагам, не забудьте сделать резервную копию ваших данных:

Такие расширения, как WP Speed ​​of Light и владельцы веб-сайтов WP, могут организовать операции, связанные с БД, еще быстрее. Конечно, вы можете использовать другие расширения или можете продолжить эти процессы без каких-либо расширений:

И если у вас есть сайт с инфраструктурой PHP, вам лучше обновить его до последней версии:

Хотелось бы подробнее остановиться на том, как можно выбрать наиболее подходящий сервер с точки зрения SEO.

Пропускная способность

Одним из самых важных моментов при выборе хостинга является месячная пропускная способность. Не забывайте держать этот домен под контролем в таких сервисах, как купленный сервер, хостинг или VPS. Из-за мгновенного трендового трафика в неожиданное время у вас может закончиться пропускная способность:

Вы можете проанализировать последние 24 часа или последнюю неделю:

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

Если ваша пропускная способность не соответствует трафику, который получает ваш веб-сайт, количество ошибок сервера может увеличиться, и ваш веб-сайт может быть «приостановлен». :

Принимая во внимание все эти моменты, вы можете купить хостинг на внутреннем рынке или на зарубежных рынках, выбрав пакеты, подходящие для вашего сайта:

Если вы используете виртуальный хостинг, вы, скорее всего, будете подвержены определенным ограничениям, даже если указано, что у вас неограниченная пропускная способность. Вот почему вы всегда должны знать ограничения ЦП в пакетах хостинга и сообщать своему менеджеру сервера, насколько сильно вы можете увеличить эти ограничения. Мы не сталкиваемся с этой проблемой в таких пакетах, как VPS/Выделенные серверы/ (, в зависимости от хостинговой компании наверняка ), однако все же рассмотрите вопрос:

Googlebot также может снизить скорость поиска, если пропускная способность сервера низкая. Кроме того, при смене сервера скорость поиска может корректироваться роботом Googlebot, поскольку он попытается понять, в чем разница между новым сервером и старым:

Вы также можете создать свой сервер с такими аппаратными функциями, как SSD-диск. . Кроме того, объем оперативной памяти и характеристики процессора являются одними из ключевых элементов. Сервер с более быстрым процессором может ускорить выполнение нескольких операций:

Причина, по которой я так подробно рассказываю о хостинге, заключается в том, что Google также сделал объявления об этом:

Использование Lite Speed ​​

Вы можете повысить производительность, установив LiteSpeed ​​на свои серверы. LiteSpeed ​​с платной лицензией предлагает лучшие результаты по сравнению с конкурентами.

Вы можете найти пример LiteSpeed, установленного на Cpanel, на изображении ниже. На этом экране можно выполнить все настройки и при необходимости перезапустить веб-сервер LiteSpeed:

Выбирая сервер, убедитесь, что LiteSpeed ​​включен:

Уменьшение HTTP-запросов

Прежде всего, убедитесь, что вы удалили Яндекс Метрику или аналогичные коды, которые вы не используете или редко используете один раз в год от исходного кода. Таким образом, вы можете получить большую выгоду, удалив коды, которые едва работают для вас. Меньшее количество HTTP-запросов приведет к более быстрому времени загрузки.

Если на вашем сайте есть сторонние файлы и несколько файлов CSS и JS, они создадут дополнительные запросы. Чем больше HTTP-запросов создает браузер, тем больше времени требуется для загрузки вашей страницы.

Вы можете проверить количество запросов через Chrome, например, 179 запросов для домашней страницы ZEO:

Вы также можете проверить подробный обзор запросов через GTmetrix:

Для оптимизации количество запросов, удалите, интегрируйте или минимизируйте ненужные файлы JS, CSS. Вы можете планировать использовать элементы изображения вместе или, если есть лишние, уменьшить их количество и максимально минимизировать.

Если вы хотите узнать больше о метрике TTFB, вы также можете ознакомиться с такими темами, как поиск DNS, Premium DNS, согласование SSL и начальное подключение.

Наконец, я хотел бы еще раз напомнить вам, что если вы оптимизируете только TTFB, этого будет недостаточно для полного ускорения вашего сайта. Эта метрика обозначает только одну метрику улучшения скорости.

Полезные ресурсы:

• https://researchashobby.com/time-to-first-byte-ttfb-hosting-speed-tests/
• https://web.dev/time-to-first-byte/

UMS YSR — Примечания к выпуску

3 июня 2022 г.

Выпущен плагин Yandex Speech Recognition (SR) 1.7.1 для сервера UniMRCP (UMS).

Плагин основан на следующих компонентах:

UniMRCP Server 1.7.0
Yandex SpeechKit Speech to Text API v2
gRPC 1. 30.3
Protobuf 3.12.2
Libevent 2.1.9
Rapidjson 1.1.0

В настоящее время двоичные файлы доступны для следующих дистрибутивов Linux:

Red Hat/CentOS 7 (unimrcp-yandex-sr-1.7.3-1.el7.x86_64.rpm)

Red Hat/CentOS 8 (unimrcp-yandex-sr-1.7.3-1.el8.x86_64.rpm)
Ubuntu 18.04 LTS (unimrcp-yandex-sr_1.7.3-bionic_amd64.deb)
Ubuntu 20.04 LTS (unimrcp-yandex-sr_1.7.3-focal_amd64.deb)

В этом выпуске устранена возможная утечка памяти.

Ниже приводится подробный список изменений, внесенных в этот выпуск.

• Нет.

• Исправлена ​​возможная утечка памяти, когда две записи файла (сигналы и/или RDR) имеют одинаковое время создания, что является очень редким случаем, не связанным с обычной работой.

• Нет.

• Нет.

28.12.2021

Вышел плагин Yandex Speech Recognition (SR) 1.7.0 к UniMRCP Server (UMS).

Плагин основан на следующих компонентах:

UniMRCP Server 1. 7.0
Yandex SpeechKit Speech to Text API v2

gRPC 1.30.3
Protobuf 3.12.2
Libevent 2.1.9
Rapidjson 1.1.0

В настоящее время двоичные файлы доступны для следующих дистрибутивов Linux:

Red Hat/CentOS 7 (unimrcp-yandex-sr-1.7.2-1.el7.x86_64.rpm)
Red Hat / CentOS 8 (unimrcp-yandex-sr-1.7.2-1.el8.x86_64.rpm)
Ubuntu 18.04 LTS (unimrcp-yandex-sr_1.7.2-bionic_amd64.deb)
Ubuntu 20.04 LTS (unimrcp-yandex -sr_1.7.2-focal_amd64.deb)

Этот выпуск содержит несколько исправлений и улучшений существующих функций. Релиз создан для более новых версий gRPC и API Google.

Ниже приводится подробный список изменений, внесенных в этот выпуск.

• Добавлена ​​поддержка позднего вызова gRPC. Поздний вызов gRPC позволяет решить проблему, связанную с тем, что «фрагменты должны отправляться не реже одного раза в 5 секунд».
• Время ожидания HTTP-запросов на аутентификацию стало настраиваемым.

• Пропускать события, связанные с речью, когда выполняется ввод DTMF.
• Исправлена ​​возможная ошибка сегментации при обработке поля заголовка Logging-Tag с пустым значением [no].

• Добавлен новый атрибут ‘auth-request-timeout’ для элемента ‘streaming-recognition’. По умолчанию 30 секунд.

• Регистрировать не только код состояния, но и текст состояния, извлеченный из полученных HTTP-ответов.
• Обновлена ​​библиотека gRPC до версии 1.30.3.
• Google API обновлен до версии 1.5.0.
• Обновлено Руководство по использованию, чтобы отразить изменения, внесенные в этот выпуск.

20.08.2020

Выпущен плагин Yandex Speech Recognition (SR) 1.6.0 к UniMRCP Server (UMS).

Плагин основан на следующих компонентах:

UniMRCP Server 1.7.0
Yandex SpeechKit Speech to Text API v2
gRPC 1.30.2
Protobuf 3.12.2
Libevent 2.1.9
Rapidjson 1. 1.0

В настоящее время двоичные файлы доступны для следующих дистрибутивов Linux:

Red Hat / CentOS 7 (unimrcp-yandex-sr-1.7.1-1.el7.x86_64.rpm)
Ubuntu 16.04 LTS (unimrcp-yandex-sr_1.7.1-xenial_amd64.deb)
Ubuntu 18.04 LTS (unimrcp-yandex -sr_1.7.1-bionic_amd64.deb)

Этот выпуск создан для более новых версий gRPC, Protobuf и API Яндекса/Google. В выпуске представлено множество дополнительных функций и улучшений существующей функциональности.

Ниже приводится подробный список изменений, внесенных в этот выпуск.

• Добавлена ​​поддержка фильтра ненормативной лексики.
• Если для параметра конфигурации use-logging-tag установлено значение true, поле заголовка Logging-Tag, если оно указано, используется в качестве суффикса при составлении имен файлов высказываний и RDR.
• Если указан параметр конфигурации stream-creation-timeout, устанавливается таймер для отслеживания создания потока gRPC. Если служба недоступна или недоступна из-за проблемы с сетью, таймер позволяет своевременно ответить ошибкой, не дожидаясь истечения установленного по умолчанию срока gRPC.
• Реализовано перенаправление журналов, созданных библиотекой gRPC. Эта функция по умолчанию отключена, и ею можно управлять с помощью новых параметров конфигурации «grpc-log-redirection», «grpc-log-verbosity» и «grpc-log-trace».
• Добавлена ​​поддержка прокси-сервера HTTP при обмене данными с серверами лицензий, доступными как услуга.
• Добавлена ​​поддержка некоторых параметров, зависящих от поставщика, в том числе «speech-start-timeout». См. раздел 4.7 в Руководстве по использованию.
• Сделана настраиваемая область XML SRGS по умолчанию. По умолчанию область считается «строгой», но может неявно использоваться как «подсказка», если для нового параметра конфигурации «match-srgs» установлено значение «false».
• Добавлена ​​поддержка тайм-аута между результатами. Если указанный тайм-аут истек, ввод считается завершенным. Время ожидания по умолчанию равно 0 (отключено) и может быть переопределено для каждого запроса на распознавание.

• Составьте поле заголовка Waveform-URI на основе версии протокола. Раньше безоговорочно использовался формат, определенный в MRCPv2.
• Установите параметры прокси-сервера HTTP не только для gRPC, но и для запросов аутентификации.
• Заменено «x-request-id» на «x-client-request-id» и «x-enable-data-logging-enabled» на «x-data-logging-enabled», чтобы отразить изменения в Yandex SpeechKit API.
• Изменена обработка окончания высказывания с учетом изменений API Яндекса SpeechKit.

• Добавлен новый атрибут «match-srgs» к элементу «streaming-recognition». Атрибут по умолчанию имеет значение «истина».
• Добавлен новый атрибут «время ожидания создания потока» к элементу «распознавание потоковой передачи». Атрибут по умолчанию равен 0 (не установлен).
• Добавлены новые атрибуты «grpc-log-redirection», «grpc-log-verbosity» и «grpc-log-trace» для элемента «streaming-recognition».
• Добавлены новые атрибуты «http-proxy-address» и «http-proxy-port» в элемент «license-server».
• Добавлен новый атрибут use-logging-tag для элементов utterance-manager и rdr-manager.
• Добавлен новый атрибут inter-result-timeout к элементу streaming-recognition.
• Изменены значения по умолчанию для параметра «время ожидания неполной речи» с 3000 мс до 15000 мс, а для параметра «время ожидания ввода» — с 10000 мс до 30000 мс.

• Обновлена ​​библиотека gRPC с версии 1.20.0 до версии 1.30.2.
• Обновлена ​​библиотека Protobuf с версии 3.7.0 до версии 3.12.2.
• Добавлена ​​зависимость от API Google, используемых внутри API Яндекса.
• Обновлено Руководство по использованию, чтобы отразить изменения, внесенные в этот выпуск.

26.08.2019

Вышел плагин Yandex Speech Recognition (SR) 1.5.0 к UniMRCP Server (UMS).

Плагин основан на следующих компонентах:

UniMRCP Server 1. 6.0
Yandex SpeechKit Speech to Text API v2
gRPC 1.20.0
Protobuf 3.7.0
Libevent 2.1.9
Rapidjson 1.1.0

В настоящее время двоичные файлы доступны для следующих дистрибутивов Linux:

Red Hat / CentOS 7 (unimrcp-yandex-sr-1.6.6-1.el7.x86_64.rpm)
Ubuntu 16.04 LTS (unimrcp-yandex-sr_1.6.6-xenial_amd64.deb)
Ubuntu 18.04 LTS (unimrcp-yandex -sr_1.6.6-bionic_amd64.deb)

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

Ниже приводится подробный список изменений, внесенных в этот выпуск.

• Если для нового параметра конфигурации tag-format установлено значение «расширенный», то элемент экземпляра в результате NLSML объединяет результат транскрипции и имя записанного высказывания с использованием символа «|».
• В целях отладки включите ведение журнала данных на стороне службы, установив для нового параметра конфигурации «регистрация данных» значение «истина». По умолчанию данные не сохраняются.

• Нет.

• Добавлен новый атрибут «формат тега» к элементу «потоковое распознавание».
• Добавлен новый атрибут «регистрация данных» к элементу «потоковое распознавание».

• Обновлено руководство по использованию, чтобы отразить изменения, внесенные в этот выпуск.

09.07.2019

Вышел плагин Yandex Speech Recognition (SR) 1.4.0 к UniMRCP Server (UMS).

Плагин основан на следующих компонентах:

UniMRCP Server 1.6.0
Yandex SpeechKit Speech to Text API v2
gRPC 1.20.0
Protobuf 3.7.0
Libevent 2.1.9
Rapidjson 1.1.0

В настоящее время двоичные файлы доступны для следующих дистрибутивов Linux:

Red Hat / CentOS 7 (unimrcp-yandex-sr-1. 6.5-1.el7.x86_64.rpm)
Ubuntu 16.04 LTS (unimrcp-yandex-sr_1.6.5-xenial_amd64.deb)
Ubuntu 18.04 LTS (unimrcp-yandex -sr_1.6.5-bionic_amd64.deb)

Этот выпуск был создан для более новых файлов определения proto API Яндекса преобразования речи в текст. В выпуске также добавлена ​​поддержка новых параметров службы.

Ниже приводится подробный список изменений, внесенных в этот выпуск.

• Добавлена ​​поддержка нового параметра «модель».
• Добавлена ​​поддержка нового параметра ‘raw-results’.
• Разрешить указывать все основные параметры через параметры производителя. См. раздел 4.9 в Руководстве по использованию.

• Нет.

• Добавлен новый атрибут «модель» к элементу «потоковое распознавание».
• Добавлен новый атрибут ‘raw-results’ к элементу ‘streaming-recognition’.

• Обновлены протофайлы определений Yandex Speech to Text API.
• Обновлено Руководство по использованию, чтобы отразить изменения, внесенные в этот выпуск.

04.06.2019

Вышел плагин Yandex Speech Recognition (SR) 1.3.0 к UniMRCP Server (UMS).

Плагин основан на следующих компонентах:

UniMRCP Server 1.6.0
Yandex SpeechKit Speech to Text API v2
gRPC 1.20.0
Protobuf 3.7.0
Libevent 2.1.9
Rapidjson 1.1.0

В настоящее время двоичные файлы доступны для следующих дистрибутивов Linux:

Red Hat / CentOS 7 (unimrcp-yandex-sr-1.6.4-1.el7.x86_64.rpm)
Ubuntu 16.04 LTS (unimrcp-yandex-sr_1.6.4-xenial_amd64.deb)
Ubuntu 18.04 LTS (unimrcp-yandex -sr_1.6.4-bionic_amd64.deb)

Этот выпуск создан для более новых версий библиотек gRPC и Protobuf. Релиз исправляет несколько мелких проблем.

Далее следует подробный список изменений, внесенных в этот выпуск.

• Добавлена ​​поддержка для типа контента ‘text/grammar-ref-list’.
• URI службы сделан настраиваемым в основном для того, чтобы можно было указать не только адрес, но и номер порта службы, что требуется, когда сервер UniMRCP находится за HTTP-прокси TMG.

• Не устанавливать флаг речи/результата, если детектор уже находится в состоянии завершения. Это может привести к попытке послать другой фрагмент аудио, когда завершение ввода уже было сигнализировано.
• Если для одиночного высказывания задано значение false, добавьте пробел при объединении результатов транскрипции.
• Составьте поле заголовка Waveform-URI на основе версии протокола. Раньше безоговорочно использовался формат, определенный в MRCPv2.

• Добавлен новый параметр конфигурации «service-uri», который по умолчанию имеет значение «stt.api.cloud.yandex.net», а также может быть установлен на «stt.api.cloud.yandex.net:443».

• Обновлена ​​библиотека gRPC с версии 1.7.3 до версии 1.20.0.
• Обновлена ​​библиотека Protobuf с версии 3.4.0 до версии 3.7.0.
• Обновлено Руководство по использованию, чтобы отразить изменения, внесенные в этот выпуск.

19.04.2019

Выпущен плагин Yandex Speech Recognition (SR) 1. 2.0 к серверу UniMRCP (UMS).

Плагин основан на следующих компонентах:

UniMRCP Server 1.6.0
Yandex SpeechKit Speech to Text API v2
gRPC 1.7.3
Protobuf 3.4.0
Libevent 2.1.9
Рапидджсон 1.1.0

В настоящее время двоичные файлы доступны для следующих дистрибутивов Linux:

Red Hat / CentOS 7 (unimrcp-yandex-sr-1.6.2-1.el7.x86_64.rpm)
Ubuntu 16.04 LTS (unimrcp-yandex-sr_1.6.2-xenial_amd64.deb)
Ubuntu 18.04 LTS (unimrcp-yandex -sr_1.6.2-bionic_amd64.deb)

В этом выпуске добавлена ​​поддержка прокси-сервера HTTP, представлены двоичные файлы для Ubuntu 18.04 LTS и исправлено несколько проблем.

Ниже приводится подробный список изменений, внесенных в этот выпуск.

• Добавлена ​​поддержка HTTP-прокси.

• Убедитесь, что отправлено START-OF-INPUT перед отправкой RECOGNITION-COMPLETE с причиной завершения, установленной на «несоответствие» или «успех». Исправлена ​​совместимость с медиасервером Cisco Broadworks.
• При использовании сервера лицензий исправлена ​​обработка события разрыва соединения при отправке запроса на обновление лицензии на сервер лицензий. Это событие может привести к отключению службы на несколько секунд.

• Добавлен новый атрибут «http-proxy» для элемента «streaming-recognition».
• Изменено значение по умолчанию атрибута ‘speech-start-timeout’ с 300 мс на 50 мс.

• Обновлено руководство по использованию, чтобы отразить изменения, внесенные в этот выпуск.
• Исправлена ​​библиотека Libevent для правильной поддержки связи через HTTP-прокси. Полученный пакет основан на 2.1.8 и выпущен как 2.1.9.

14.03.2019

Вышел плагин Yandex Speech Recognition (SR) 1.1.0 к UniMRCP Server (UMS).

Плагин основан на следующих компонентах:

UniMRCP Server 1.6.0
Yandex SpeechKit Speech to Text API v2
gRPC 1. 7.3
Protobuf 3.4.0
Libevent 2.1.8
Rapidjson 1.1.0

В настоящее время двоичные файлы доступны для следующих дистрибутивов Linux:

Red Hat / CentOS 7 (unimrcp-yandex-sr-1.6.1-1.el7.x86_64.rpm)
Ubuntu 16.04 LTS (unimrcp-yandex-sr_1.6.1-xenial_amd64.deb)

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

Ниже приводится подробный список изменений, внесенных в этот выпуск.

• Установите сигнал тревоги в файле состояния, если сервер лицензий недоступен в течение определенного периода времени, но служба еще не затронута. Снимите сигнал тревоги, как только сервер лицензий станет доступен. См. раздел 6.2 в Руководстве по использованию.
• Добавлена ​​поддержка необязательного языкового параметра, передаваемого во встроенную грамматику.
• В запросы gRPC, отправляемые в службу, добавлены метаданные x-request-id, которые можно использовать для сопоставления запросов при устранении возможных проблем со службой.

• Если используется годовая лицензия с привязкой к узлу, срок действия лицензии может быть указан неправильно, что потребует перезапуска службы для продолжения нормальной работы.
• Исправлена ​​обработка искаженных параметров, передаваемых во встроенную грамматику.

• Нет.

• Исправлена ​​ошибка, из-за которой время ответа HTTP в журналах не усекалось до миллисекунд, а представлялось в миллисекундах.
• Обновлено Руководство по использованию, чтобы отразить изменения, внесенные в этот выпуск.

24.12.2018

Выпущен плагин Yandex Speech Recognition (SR) 1.0.0 к UniMRCP Server (UMS).

Плагин основан на следующих компонентах:

UniMRCP Server 1.6.0
Yandex SpeechKit Speech to Text API v2
gRPC 1.7.3
Protobuf 3.4.0
Libevent 2.1.8
Rapidjson 1.1.0

В настоящее время двоичные файлы доступны для следующих дистрибутивов Linux:

Red Hat / CentOS 7
Убунту 16.