Что такое частотность запросов: Что такое частотность запроса и какие ее типы- 1C-UMI

Что такое частотность поисковых запросов

Частотность – это количественная величина, показывающая сколько раз пользователь обращался к поисковой системе с конкретным запросом. Как правило, рассчитывается за последний месяц. Зная спрос, SEO-специалист поймет, есть ли поисковый спрос, нужно ли создавать посадочную страницу, а также сможет спрогнозировать трафик, который получит продвигаемый сайт при ранжировании в ТОП-10.

В данной статье мы расскажем о том, какой может быть частотность запроса и как ее определить.

Виды частотностей в поисковой системе Яндекс

Один из инструментов определения частотностей является сервис от поисковой системы (далее ПС) Яндекс – WordStat. Он показывает популярность фразы в одноименной поисковой системе. Причем, посмотреть можно несколько видов частотностей, в зависимости от операторов, которые применяются. На примере запроса «поисковое продвижение» разберемся подробнее.

• Поисковое продвижение – такой запрос без каких-либо операторов покажет общую частотность по фразе, ее аналогам и словоформам.

Число 23 504 на рисунке выше означает, какое количество показов было со словом «поисковое продвижение» в ПС Яндекс за последний месяц. Нужно учитывать, что в эту цифру входят и более длинные фразы, например, «поисковое продвижение сайтов» и фразы с измененными словоформами, например, «услуги поискового продвижения».

• Оператор «кавычки» («поисковое продвижение») фиксирует количество слов в запросе, а значит фразы формата «поисковое продвижение Москва» учитываться не будут. Как видно ниже, частота спроса стала значительно меньше.

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

• Оператор «квадратные скобки» ([поисковое продвижение]) фиксирует порядок слов. Сюда не войдет фраза «продвижение поисковое помогает». Но необходимо иметь в виду, что будут посчитаны все словоформы, а также не будет зафиксировано количество слов.

• Оператор «кавычки и квадратные скобки» («[поисковое продвижение]») как раз может фиксировать и порядок слов, и их количество в запросе.

При этом словоформы все еще учитываются. Это означает, что сюда могут попасть запросы «поисковому продвижению». Для того, чтобы зафиксировать форму слова используем «!» перед ним, как в примере ниже.

• Оператор «кавычки, квадратные скобки и знак восклицания» («[!поисковое продвижение]») — фиксирует количество и порядок слов в запросе, а также словоформу первого слова, перед которым стоит знак восклицания.

• Спецоператор «плюс» (+в поисковое продвижение) в обязательном порядке фиксирует служебные части речи, местоимения, цифры и другие слова, не несущие дополнительного смысла. В нашем случае обязательным стал предлог «в» и ниже на рисунке видно, как поменялись статистика и список запросов.

В результате можно максимально точно определить, как часто пользователи интересуются той или иной тематикой в поисковой системе Яндекс.

Частотность запросов в поисковой системе Google

ПС Google не дает специального сервиса для определения частотности поисковых фраз в отличие от Яндекс. Для сбора статистики можно использовать «Планировщик ключевых слов» в сервисе для запуска рекламы – Google Ads.

Там есть два варианта: «Посмотреть количество запросов и прогнозы» или «Найти новые ключевые слова». Первый покажет лишь приблизительные значения, а вот с помощью второго их можно уточнить. Как именно это можно сделать описано ниже в пункте «Инструменты для определения частотностей».

Высоко- средне- и низкочастотные запросы

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

• высокочастотные или ВЧ (частотность от 5 000)
• среднечастотные или СЧ (частотность от 1 000 до 5 000)
• низкочастотные запросы или НЧ (частотность от 1 до 1 000)

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

Высокочастотные запросы

Данный вид запросов включает в себя максимально общие фразы. Они состоят, как правило, из 1-2 слов. По такому ключевику не всегда очевидно, что хочет пользователь, из-за этого они часто имеют более низкую конверсионность. Но всегда есть исключения, поэтому рекомендуем анализировать именно конкретную ситуацию. Если сайт молодой лучше начинать с НЧ и СЧ запросов, а ВЧ подключать со временем.

Пример ВЧ запроса показан ниже:

Среднечастотные запросы

Эти запросы содержат более точные фразы, обычно состоят из 3-4 слов. Хотя они все еще и охватывают большое количество пользователей, но имеют уже более понятный интент. Пример указан ниже на рисунке.

Низкочастотные запросы

Это наиболее точные запросы, показывающие намерения пользователя. Как правило, содержат 5 и более слов. Мы советуем всегда добавлять в СЯ часть НЧ фраз, которые привлекут целевой трафик на сайт. При этом они помогают более эффективно продвигать страницы за счет текстовой оптимизации.

Пример НЗ запроса показан ниже:

Отличие частотности от конкуренции

Еще один параметр – это конкуренция поискового запроса. Здесь они делятся на:

• высококонкурентные (ВК)
• среднеконкурентные (СК)
• низкоконкурентные (НК)

Низкочастотный запрос еще не значит, что по нему низкая конкуренция. На показатель конкурентности влияет множество факторов. Например, количество главных страниц в ТОП-10, прямые вхождения ключевой фразы в заголовок страницы, рекламные блоки в выдаче и т.д.

Данная тема будет затронута в другой публикации.

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

Одна из методик определения конкуренции, посмотреть количество результатов по запросу. Например, “продвижение сайтов спб” — 10 млн. подходящих результатов.

Показано ниже на рисунке:

Другая методика – анализировать показатель, рассчитываемый по количеству внешних входящих ссылок/доменов. В разных сервисах он может называться по-разному. Например, в сервисе Ahrefs от компании Google он называется Keyword Difficult.

Пороги значений обозначены ниже:

Что такое сезонность запроса и где её посмотреть

Частотность поисковой фразы часто сильно зависит от сезонности. Например, запрос «купить елку» ежегодно начинает набирать популярность в ноябре, пик в декабре, а в феврале уже не интересен пользователям.

Другой пример – запрос «купить септик». Актуален в течение всего года, но популярность повышается весной и летом, когда люди перебираются в частные дома и на дачи.

Проверить ее можно в Яндекс WordStat . Необходимо:

• зайти в сервис
• ввести запрос
• выбрать регион
• нажать «История запросов»

Под графиком находятся данные по месяцам за последние два года:

Еще один инструмент для определения сезонности – сервис Google Trends .

Необхидимо:

• ввести запрос
• выбрать регион, источник и временной промежуток

Данные можно посмотреть, начиная с 2004 года. Можно сравнить до пяти запросов. Google показывает значения в баллах. Например, курсор на скриншоте ниже наведен на пик популярности поискового запроса – это 100 баллов.

Что такое геозависимость запроса и как ее проверить

Геозависимость запроса показывает нам, зависит ли показ по этому ключевому слову от местонахождения пользователя. Например, по запросу «услуги нотариуса» человек из Санкт-Петербурга увидит одни сайты в выдаче, а человек из Тулы – совершенно другие. Яндекс считает, что до 30 % обращений к ПС являются геозависимыми. Как правило, к ним относятся коммерческие запросы.

Вручную проверить геозависимость запроса можно методом сравнения ТОП-10 по двум разным регионам или подсветке топонима в поисковой выдаче.

Заходим в ПС Яндекс, смотрим выдачу по двум разным регионам и анализируем. Регион можно поменять внизу страницы поиска:

На примере запроса «услуги нотариуса» видим, что выдача для Санкт-Петербурга и Тулы разная и поисковая система в обеих выдачах подсвечивает актуальный для пользователя город.

Ниже представлен пример для г. Санкт-Петербург:

Мы видим преимущественно региональные сайты Петербурга.

На следующем скриншоте показаны результаты для пользователя из г. Тула:

В данном случае преимущественно региональные сайты Тулы.

Инструменты для определения частотностей

А теперь к самому интересному – как же определить частотность?

Для этого можно использовать различные сервисы.

В Яндекс WordStat необходимо ввести запрос, выбрать регион, интересующее устройство, нажать «Подобрать», далее сервис покажет результат:

Можно посмотреть статистику по регионам и городам:

Яндекс.Директ – сервис для запуска рекламы в поисковой системе Яндекс. Посмотреть частотность запроса можно при создании рекламной кампании. Доходим до второго шага «Выбор аудитории», задаем регион и нажимаем «Подобрать фразы». При вводе фразы получаем статистику по ним.

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

В случае снятия данных за год, они могут отличаться от данных в сервисе WordStat и быть некорректными.

Google Keyword Planner – инструмент для подбора ключевых слов при создании рекламы в ПС Google. Поможет при сборе статистики по запросам в Google.

Необходимо зайти в инструмент, авторизоваться и выбрать «Найдите новые ключевые слова»:

Далее нужно ввести слова через запятую и нажать «Показать результаты»:

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

Рядом с каждым запросом появляется зеленый значок «В плане»:

Переходим в пункт меню «Ключевые слова», выбираем корректный регион вверху страницы, раскрываем график по стрелочке, выставляем максимальную цену за клик:

Для анализа нужно использовать столбец «Показы»:

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

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

Ahrefs – еще один сервис для просмотра статистики по ключевому слову и подбора аналогов. Также является платным.

Серверы SemRush, Ahrefs и другие подобные инструменты получают данные о количестве запросов методом покупки сlickstream у крупных провайдеров, поэтому их данные будут отличаться от данных в Google Keyword Planner.

Софт для ручного и автоматического съема частотностей

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

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

KeyCollector – платный софт (есть бесплатный аналог Словоеб), с помощью которого можно быстро собрать ключевые фразы и их параметры, в том числе частотность, конкурентность, стоимость, посмотреть сезонность запроса и т. д.

TopVisor – платный сервис для сбора статистики из Яндекс и Google.

Для проверки частоты необходимо:

• создать проект
• перейти на страницу «Поисковые запросы»
• добавить запросы
• выбрать источник, регион

RushAnalytics – еще один платный сервис, в котором есть инструмент для парсинга ключевых слов и частотностей из Яндекс и Google на высокой скорости.

Serpstat – этот сервис позволяет автоматизировать процесс, оперативно собирать большие объемы данных по запросам и выгружать их в удобном формате. Сервис также платный.

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

Заключение

Есть много нюансов в определении частотности запросов, о каждом из которых важно помнить при составлении и корректировке семантического ядра. Необходимо обязательно

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

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

Частотность ключевых слов — стоит ли использовать — Блог Миралинкс

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

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

Но это отнюдь не так.

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

Эксперты Ahrefs провели эксперимент, поместив около 100 000 запросов в граф, где ось Х отображает частоту запроса, а ось Y — фактический трафик, который получает страница на позиции #1.

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

Почему так происходит, рассмотрим возможные причины.

Проблема в том, что ни один инструмент не дает сверхточных оценок частотности поисковых запросов, даже собственно поисковые инструменты как Keyword Planner и Яндекс. Wordstat. 

Инструменты предлагают обобщенную статистику по запросу за определенный период. Частота обновлений данных в инструментах также варьируется. Даже между своими инструментами Google демонстрирует большую погрешность, которой ну никак нельзя пренебречь. Смотрим пример:

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

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

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

Исследование Ahrefs показывает, что только 19% поисковых запросов переходят в клики по сайтам. Причинами могут становиться как готовые ответы поисковой системы, так и сама выдача, когда пользователь ожидает увидеть другие сайты или ищет какой-то определенный (но забыл его название), а также может получить ответ из сниппета сайта.

Если ранее реклама раздражала пользователей, то сейчас она стала высокорелевантной и даже полезной. 

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

Так, к примеру, опыт самого сервиса Ahrefs показывает, как Google перебивает трафик. Страница с сервисом подбора ключевых слов ранжировалась на позиции #3, но не получала достойного объема трафика. Главной причиной эксперты видят рекламу самого Google над результатами.

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

Рассмотрим запрос “кто основал Google”. Синонимичными запросами становятся:

• кто создал Google
• основатели Google
• создатели Google
• кто сделал Google

Алгоритмы поисковых систем достаточно умны, чтобы понять, что за этими запросами скрывается одно и то же поисковое намерение — узнать, благодаря кому появился поисковик.

В инструментах Ahrefs есть отличная функция — запросы, по которым также ранжируется страница. Она показывает, что в среднем каждую страницу Google ранжирует по сотням других запросов. 

У компании есть целое исследование, посвященное количеству запросов, по которым может ранжироваться страница из топа.  

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

На прогнозируемый трафик определенно оказывают влияние:

• тематика — некоторые тематики настолько узкие, что даже с учетом возможных вариаций основного ключевого слова, надеяться на большой объем трафика не приходится;

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

• обратные ссылки — самый сильный сигнал ранжирования.

Охватить больше поисковых запросов не означает добавить в текст все возможные ключевые слова и вариации. Исследование Ahrefs показывает, что сайты из первой страницы поисковой выдачи в 75% случаев не имеют прямого вхождения ключевого запроса вовсе.

Не надо превращать контент в набор ключевых слов.Что надо сделать:

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

Алгоритмы ранжирования давно способны определять суть запроса и сопоставлять его с более популярным или уже известным системе запросом. Google утверждает, что ежедневно пользователи вводят от 16 до 20% абсолютно новых запросов, неизвестных системе. С этими запросами работает RankBrain — его задачей становится правильная обработка и интерпретация запроса.

Как интерпретирует новый запрос система и к какому более популярному или просто известному запросу она его отнесет — не известно. Более того, эти данные не отображаются ни в одной системе аналитики.

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

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

Частотность (ВЧ, СЧ, и НЧ) и конкурентность (ВК, СК, НК) запроса — проверка и анализ

Здравствуйте, уважаемые читатели блога MonetaVInternete.ru. Сегодня речь пойдет о поисковых запросах, а точнее об их частотности и конкурентности. Из этой статьи вы узнаете о самих понятиях, их видах, а так же об особенностях продвижения под те или иные запросы.

И частотность и конкурентность зависят от тематики запроса. Вообще, оба понятия довольно субъективны, то есть определенной градации по числам (количеству запросов) нет. Однако, большинство веб-мастеров сошлись на некоторых данных, которые я приведу в статье.

Частотность запросов — ВЧ, СЧ и НЧ, как проверить частотность — Яндекс Wordstat и Google Adwords

Итак, для начала определимся, что такое частотность запросов. Частотность — количество запросов за месяц. То есть сколько раз одну и ту же фразу вводили в поисковик за месяц или любой другой промежуток времени. Не путайте понятия «частотность» и «частота». Второе это физический термин, означающий количество повторяющихся действий за единицу времени.

Все поисковые запросы разделяются на три вида, исходя из их количества в месяц:

• ВЧ — высокочастотные запросы — от 1000 или нескольких тысяч, в зависимости от тематики.
• СЧ — среднечастотные запросы — 100 — 1000 запросов.
• НЧ — низкочастотные запросы — обычно до 100 запросов в месяц, в некоторых тематиках может достигать 1000.

Однако эти данные не являются точными, но сойдут в качестве грубого округления. С уверенностью можно сказать только то, что запрос с частотностью 50 является НЧ запросом, а свыше 5000 — ВЧ. Категории СЧ как таковой нет, для каждого она своя, но в большинстве случаев «средние» запросы колеблются в вышеприведенных пределах.

Узнать частотность запроса можно с помощью различных сервисов. Отечественная поисковая система Яндекс создала Wordstat. Вы вводите запрос и получаете данные как по самому запросу, так и по схожим. Для уточнения поисковой фразы, существуют специальные операторы в данном сервисе. Если вы возьмете запрос в двойные кавычки («поисковая фраза»), то получите информацию о частотности запроса, в котором сохранится порядок слов.

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

Можно сказать, что это ВЧ запрос, почти 33 тысячи запросов в месяц. Зеленой чертой выделен похожий запрос, слова в котором стоят в ином порядке. Цифры очень похожи. А теперь возьмем его в кавычки. Вот что получается:

Превращение ВЧ запроса в СЧ. Такой запрос называется точным и похожие результаты не учитываются и не выводятся. Фактически, из-за кавычек вы увидите показатель частотности в 10 раз меньший, нежели при чистом запросе. Теперь Вордстат учел порядок слов. Но и это еще не все. Добавим к каждому слову восклицательный знак. Вот результат:

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

По сравнению с первым случаем, частотность ниже в два раза. Но мы можем здесь увидеть и «смотреть фильмы онлайн 2013 года», и «смотреть фильмы онлайн бесплатно 2013» и еще много разбавлений оригинального запроса. Главное отличие это сами слова. В любом случае слова не меняются ни в падеже, ни в числе, ни в чем либо другом. Из всего вышесказанного можно сделать заключение: чтобы узнать частотность того или иного запроса, заключайте его в кавычки и ставьте восклицательный знак перед каждым словом.

Но все это касается лишь Яндексовского Вордстата. Но как узнать частотность запросов во всемирно известном поисковике Google? Тут все немного сложнее. Чтобы узнать статистику поисковых фраз, вы должны иметь аккаунт в Гугле, а точнее в его системе контекстной рекламы AdWords (это источник рекламодателей для контекстной рекламы Google Adsense).

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

Ну что, рассмотрим статистику все того же запроса:

Инструмент Гугла более функционален: имеется возможность включить в результаты сайты для взрослых, а также добавить некоторые фильтры. Также статистика любого запроса показывается как во всем мире, так и в определенном конкретном регионе. В данном случае в качестве региона выбрана России, а язык — русский. Практически двукратная разница в каждом похожем запросе.

Конкурентность запроса — сервисы и алгоритмы проверки

А теперь рассмотрим не менее важное понятие — конкурентность запросов. Чтобы ее узнать не нужно посещать какие-либо сервисы вообще, все можно найти в поисковой выдаче. В качестве примера будет выступать все тот же запрос — «смотреть фильмы онлайн 2013». Вводим в строку поиска, ищем, и видим следующую картину:

Под логотипом Яндекса всегда показывается количество найденных результатов. Это и есть конкурентность запросов. Любая поисковая фраза может принадлежать одному из трех видов конкурентности:

• ВК — высококонкурентный запрос — результатов от миллиона и более.
• СК — среднеконкурентный запрос — результатов от ста тысяч до миллиона.
• НК — низкоконкурентный запрос — результатов до ста тысяч.

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

Что же касается сервисов, то большинство используют свои алгоритмы, а некоторые и алгоритм Сергея. Но в основном они (сервисы) основаны на платной основе. За анализ придется заплатить. Например, вот здесь за 1 ключевую фразу вам придется заплатить 18 копеек. Только для начала зарегистрируйтесь на сервисе.

Вот, собственно, и все, что я хотел рассказать в этой статье. По всем возникшим вопросам прошу обращаться в комментарии. До скорых встреч на странице блога MonetaVInternete.ru!

Частотность запросов в Гугл и Яндекс — Блог Сергея Кузнецова

Авторский полет фантазии, красивая подача материала и легкий слог это одна из составляющих качественного текста. Но он может навсегда остаться невидимым в сети, если копирайтер пишет текст без использования ключевых слов и не смотрит на частоту запросов. Что такое частотность в Гугл, Яндекс, что делать с этими словами.

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

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

Вч – высокочастотный запрос состоит из общих слов, без конкретики предложения. Для Гугла это не менее 2000 запросов в месяц, для Яндекса не мене 1000. Например, запрос «купить кровать» вбивали в поисковик десятки тысяч раз в месяц.

По Вч запросам нельзя продвигать молодые сайты. Если семантик собирает ядро для статьи только на основе высокочастотных запросов, не учитывая регион и свою аудиторию, продвижения не будет. ВЧ запросы вбивают пользователи, которые не ищут что то конкретное, — «купить кровать недорого в Барнауле», а просматривающие общий список вариантов.

Сч – среднечастотный запрос, это поиск с уточнением. «Где купить кровать недорого» — пример среднечастотного запроса, который пользователи вбивали более 100 раз в месяц. Уточняющие слова позволяют Гуглу сузить результат выдачи и показать посетителю конкретные сайты.

Нч – низкочастотный запрос это не менее 4-5 слов, которые пользователь вбивает, когда точно знает, что ищет. «Купить кровать недорого в Барнауле» классический пример запроса, который пользователи вбивали до 10-20 раз в месяц.

Четкой границы, которая отделяет ВЧ от СЧ и НЧ не существует. Все зависит от конкретной тематики, региона. Если Ваша тема узконаправленная, «Все о сибирских черных хомяках», то запрос с частотностью 100 может быть высоким. Но если рекламная компания строится вокруг проекта «Пластиковые окна», то здесь частота поиска не ограничивается сотней тысяч.

Посмотреть частотность запросов можно в бесплатных сервисах:

• «Букварикс»;
• Яндекс Вордстат;

Для сбора семантики используют автоматический парсинг сайтов или собирают семантику вручную. Есть несколько десятков способов, которые помогают более-менее узнать те слова, которые пользователи вбивают, чтобы решить свою проблему. Почему более-менее?.. Потому что ни Яндекс ни Гугл никогда не раскроют полностью свой алгоритм ранжирования сайтов. Есть общие рекомендации для всех веб мастеров – качественный контент, чистый код и максимальная полезность для посетителя.

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

Общая частотность это база из нескольких слов, которые сервис проверки выдает независимо от слов уточнений. Общая частотность показывает приблизительный показатель. Для расчета веб-мастера используют сервис Яндекс Вордстат. Поисковое слово вписывают без дополнительных знаков.

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

Точную частотность получаем когда используем дополнительные символы, двойные кавычки – » » и восклицательный знак перед словом. Например -«!частотность !проверить». Сервис уберет с проверки все склонения ключа, дополнительные слова и покажет точное количество, сколько раз пользователи вбивали в браузер именно эту фразу. И напоследок, несколько мифов о том, что же такое частота…

Определение частотности запроса | Продвижение бизнеса

Частотность запроса – далеко не самый абстрактный термин в поисковой оптимизацииПоисковая оптимизация — оптимизация, продвижение сайта, поисковая оптимизация, оптимизация сайта, сео, SEO, search engine optimization, также «раскрутка» сайта — набор действий по изменению сайта и элементов внешней среды с целью получения высоких мест в результатах поиска по заданным запросам….. Она характеризует вполне конкретное значение числа поисковых запросов, запрашиваемых пользователем по данной области, теме или сопутствующих данной области или теме. Например, пользователь, интересующийся телевизорами (хочет купить или получить информацию), может сделать следующие запросы:

• телевизор 278613
• схемы телевизоров 19730
• жк телевизоры 19009
• lcd телевизоры 15375
• плазменные телевизоры 13665
• ремонт телевизор 12185
• Samsung телевизор 9383
• philips телевизоры 7908
• sony телевизоры 7426
• телевизор 1g 4928
• автомобильные телевизоры 4723
• купить телевизор 4172
• тест телевизоров 3999

…и так далее (сервис статистики ЯндексаЯша (Яшка). Жаргон. Имеется в виду поисковая система Яндекс.).

Каждое число, стоящее рядом с запросом, отображает степень его популярности с точки зрения частоты употребления в месяц. Здесь следует отметить, что типы частотности запросов по частотности имеют весьма отдаленное отношение к типам запросов по степени готовности что-либо приобрести. Самые высокочастотныеНЧ, СЧ, ВЧ — низкочастотные, среднечастотные и высокочастотные ключевые запросы. Частотность -это количество запросов определенного словосочетания, сделанного пользователями поисковых систем за месяц. Также стоит упомянуть другую характеристику запросов — конкурентность, то есть сложность вывода в ТОП 10 по причине высокой активности, большого количества конкурентов и серьезных бюджетов на SEO. Чаще всего высокочастотные запросы являются одновременно и высококонкурентными, однако это не совсем синонимы…. запросы, как правило, не относятся к целевым запросам, так как у них отсутствует четкое смысловое содержание. Большая часть высокочастотных запросов вообще не имеет какой-либо психологической наполненности. К примеру, что может дать оптимизатору высокочастотныйНЧ, СЧ, ВЧ — низкочастотные, среднечастотные и высокочастотные ключевые запросы. Частотность -это количество запросов определенного словосочетания, сделанного пользователями поисковых систем за месяц. Также стоит упомянуть другую характеристику запросов — конкурентность, то есть сложность вывода в ТОП 10 по причине высокой активности, большого количества конкурентов и серьезных бюджетов на SEO. Чаще всего высокочастотные запросы являются одновременно и высококонкурентными, однако это не совсем синонимы…. запрос “телевизор”? Этот популярный запрос вводит целый ряд представителей самых разных аудиторий, в том числе не целевых. В таком случае оптимизировать сайт под запрос, который может привлечь совершенно ненужных посетителей, просто неразумно. Поэтому оптимизация сайта проводится только после детального анализа всех преимуществ разных типов запросов, а также других параметров, о которых будет сказано ниже.

Высокочастотные запросы.

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

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

Однако существует совсем небольшая часть запросов, которые сегодня уже в полной мере относятся к высокочастотным запросам. Это запросы типа “доставка пиццы”, “заказ такси” и т.д. Буквально еще два-три года назад эти запросы можно было отнести к среднечастотным запросам, однако с ростом популярности Интернета растет и уровень осведомленности в корректной формулировке запроса у большинства пользователей. В итоге среднечастотныеНЧ, СЧ, ВЧ — низкочастотные, среднечастотные и высокочастотные ключевые запросы. Частотность -это количество запросов определенного словосочетания, сделанного пользователями поисковых систем за месяц. Также стоит упомянуть другую характеристику запросов — конкурентность, то есть сложность вывода в ТОП 10 по причине высокой активности, большого количества конкурентов и серьезных бюджетов на SEO. Чаще всего высокочастотные запросы являются одновременно и высококонкурентными, однако это не совсем синонимы…. целевые запросы, которые прежде свободно позволяли оптимизировать сайт без особых затрат, сегодня становятся высокочастотными целевыми. Использовать такой тип запросов приходится обязательно, так как их задают “целевые” пользователи. Однако стоимость работ по оптимизации сайта в связи с высокой конкуренцией запросов существенно возрастает.

Существует несколько мероприятий, проведение которых позволяет выбрать наиболее подходящие высокочастотные запросы с оптимальной конкуренцией. Оценка уровня конкуренции по самым популярным запросам происходит следующим образом: у первых десяти страниц выдачиВыдача (SERP, Search Engine Results Page) — страница выдачи поисковых результатов. Показывается пользователю поисковика в ответ на запрос. Все популярные ПС демонстрируют первые десять наиболее релевантных (соответствующих запросу) результатов — это и есть ТОП10. Попасть в первую десятку по нужным ключевым словам очень важно, так как следующие 10 результатов смотрят менее 20% пользователей (по коммерческим запросам — еще меньше). ТОП 10 «снимает все сливки», борьба за места в нем — основная задача SEO…. определяется средний показатель PageRankPageRank (PR, ПР). Алгоритм расчета «авторитетности» страницы, а также сам показатель «авторитетности» в числовом выражении., среднее количество ссылок с других страниц (в том числе по результатам выдачи с других поисковых систем), средний тИЦ (тематический индексИндекс — база данных поисковой машины, так называемый инвертированный индекс, обычно напоминает индекс терминов, применяемый в учебниках и научных изданиях. Содержит словарь слов, встречающихся на интернет-страницах, с приписанными к ним списками адресов интернет-страниц, содержащих эти слова. Служит для поиска страниц с вхождениями заданных ключевых слов. Индекс пополняется поисковым роботом во время периодических обходов Интернета…. цитирования; подробности в главе 6). Иногда обращаются и к другим параметрам – количеству страниц в Сети, содержащих данный поисковый запрос, в том числе с точной формулировкой запроса (вплоть до кавычек, тире и т.д.).

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

Низкочастотные запросы.

Среднечастотные и низкочастотныеНЧ, СЧ, ВЧ — низкочастотные, среднечастотные и высокочастотные ключевые запросы. Частотность -это количество запросов определенного словосочетания, сделанного пользователями поисковых систем за месяц. Также стоит упомянуть другую характеристику запросов — конкурентность, то есть сложность вывода в ТОП 10 по причине высокой активности, большого количества конкурентов и серьезных бюджетов на SEO. Чаще всего высокочастотные запросы являются одновременно и высококонкурентными, однако это не совсем синонимы…. запросы представляют собой весьма непопулярную группу запросов, которые, как правило, начинаются с третьей-четвертой строчки на листе статистики Яндекса или Рамблера. Для оптимизаторов эти типы запросов ценны тем, что в большинстве случаев они будут целевыми запросами, т.е. фактически указывают на какую-либо потребность представителя целевой аудитории. К среднечастотным и низкочастотным запросам в полной мере можно отнести покупательские сопутствующие запросы, которые указывают на получение какой-либо информации о товаре или услуге. В связи с низкой конкуренцией данные запросы могут быть внедрены в семантическое ядро сайта в большом количестве, но, разумеется, без ущерба для читаемости текста.

Однако не все низкочастотные запросы можно использовать. Некоторые сочетания слов в поисковой фразе могут содержать двойной смысл, скрытый для пользователя, но вполне очевидный окружающим и поисковой машине. Таковы запросы: “мойка купить” (автомойка или посудомойка?), “услуги дизайнера” и т.д. Здесь оптимизатору необходимо воспользоваться сервисами качественной статистики “Rambler-Ассоциации” и количественной Direct.Yandex.

Частота запросов и рекомендации по распределению доступа | Облачное хранилище

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

Автоматическое масштабирование

Cloud Storage — это мультитенантная служба, что означает, что пользователи совместно используют тот же набор базовых ресурсов.Чтобы наилучшим образом использовать эти общие ресурсы, у корзин начальная емкость ввода-вывода:

• Примерно 1000 запросов на запись объекта в секунду, включая загрузку, обновление и удаление объектов.
• Примерно 5000 запросов на чтение объекта в секунду, включая листинг объекты, чтение данных объекта и чтение метаданных объекта.

Эти начальные скорости чтения и записи составляют в среднем 2,5 Пбайт при записи и 13 Пбайт при чтении. месяц для объектов размером 1МБ.По мере роста количества запросов для данного сегмента Облачное хранилище автоматически увеличивает емкость ввода-вывода для этого сегмента путем распределения нагрузки запроса между несколькими серверами.

Время перераспределения нагрузки

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

Индексирование ключа объекта

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

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

Лучшие практики

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

Постепенно увеличивайте частоту запросов

Чтобы гарантировать, что автоматическое масштабирование облачного хранилища всегда обеспечивает наилучшее производительность, вам следует постепенно увеличивать частоту запросов для любого сегмента у которого не было большого количества запросов в течение нескольких недель или у которого есть новый диапазон ключи объекта.Если ваша частота запросов меньше 1000 запросов на запись на в секунду или 5000 запросов чтения в секунду, тогда наращивание мощности не требуется. Если твой ожидается, что частота запросов превысит эти пороговые значения, вам следует начать с частота запросов ниже или близка к пороговым, а затем удвоить частоту запросов не чаще, чем каждые 20 минут.

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

• Ошибки приема с кодами ответа 5xx и 429 .
• Получение ошибок с кодами ответа 408 при выполнении возобновляемых загрузок.

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

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

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

Например, если вы хотите использовать исходные имена объектов:

мой-ведро / 2016-05-10-12-00-00 / file1
мой-ведро / 2016-05-10-12-00-00 / file2
мой-ведро / 2016-05-10-12-00-01 / file3
...
 

Вы можете вычислить MD5-хэш исходного имени объекта и добавить первое 6 символов хеша в качестве префикса к имени объекта. Новый объект имена стали:

my-bucket /  2fa764-  2016-05-10-12-00-00 / file1
my-bucket /  5ca42c-  2016-05-10-12-00-00 / file2
мой-ведро /  6e9b84-  2016-05-10-12-00-01 / file3
...
 

Более длинный рандомизированный префикс обеспечивает более эффективное автоматическое масштабирование при переходе к очень высокая скорость чтения и записи. Например, префикс из 1 символа, использующий случайное шестнадцатеричное значение обеспечивает эффективное автоматическое масштабирование от начальных 5000/1000 операций чтения / записи в секунду примерно до 80000/16000 операций чтения / записи в секунду, потому что префикс имеет 16 потенциальных значений.Если ваш вариант использования не нужен при более высоких скоростях, чем этот, рандомизированный префикс из 1 символа также эффективен при увеличении частоты запросов в виде 2-значного или более рандомизированного префикса.

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

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

Например:

my-bucket / images / animals /  4ce4c6af-6d27-4fa3-8a91-5701a8552705 /  1.jpg
my-bucket / images / animals /  9a495e72-1d85-4637-a243-cbf3e4a90ae7 /  2.jpg
...
my-bucket / images / landscape /  585356ac-ce89-47a8-bdd2-78a86b58fee6 /  1.jpg
my-bucket / images / landscape /  2550ae5b-395e-4243-a29b-bbf5aece60ef /  2.jpg
...
мой-ведро / изображения / облака / 1.jpg
мой-ведро / изображения / облака / 2.jpg
...
 

Приведенное выше обозначение обеспечивает эффективное автоматическое масштабирование объектов на изображений / животных и изображений / пейзаж, , но не изображений / облака .

Случайность после последовательных префиксов не так эффективна

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

Например, если вы записываете файлы с новым префиксом на основе метки времени каждый час:

мой-ведро / 2016-05-10-00 / cf9a7b95-0d2e-4466-9596-840ff388ddbd
мой-ведро / 2016-05-10-00 / f1e16a88-16b8-4c66-ba66-a225c87be80c
my-bucket / 2016-05-10-00 / 646d8272-4a88-4dc2-b2d4-d537c778df41
...
мой-ведро / 2016-05-10-01 / bdcba6de-ac25-4c27-8550-0d08f249e69d
мой-ведро / 2016-05-10-01 / a32c867c-09a9-4d65-9668-ddd4ebe4138b
my-bucket / 2016-05-10-01 / d619485c-5243-4a4e-8ef3-0f7e1d26ce1d
...
 

Хотя автоматическое масштабирование помогает увеличить скорость записи с префиксом выше время, скорость записи сбрасывается в начале каждого часа. Это результаты при неоптимальной скорости записи и периодическом увеличении задержки и частоты ошибок. Если вам нужно со временем писать на разные префиксы, чтобы избежать этой проблемы, убедитесь, что новые префиксы равномерно распределены по всему диапазону ключей.

Изменить порядок массовых операций для равномерного распределения нагрузки по ключевым диапазонам

Иногда вам нужно выполнить массовую загрузку или удаление данных в Облачное хранилище. В обоих случаях у вас может не быть контроля над объектом. имена. Тем не менее, вы можете контролировать порядок загрузки объектов. или удален для достижения максимально возможной скорости записи или удаления.

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

Как справиться с ограничениями скорости API: работает ли ваша интеграция в масштабе?

Вы когда-нибудь ходили в общественный бассейн и замечали знак с указанием максимальной вместимости? Эти ограничения были введены для обеспечения общественной безопасности.API используют аналогичный критерий, называемый «предел скорости», чтобы гарантировать безопасность потребителей API и самого API.

Они могут защитить вас от низкой производительности и атак типа «отказ в обслуживании» (DoS), обеспечить масштабируемость и улучшить общее впечатление пользователя.

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

Зачем нужны ограничения скорости

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

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

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

Под капотом: как работают ограничения скорости

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

При запросах HTTP API эта ошибка обычно проявляется как ответ с кодом состояния 429. RFC 6585 откладывает этот код состояния для представления «Слишком много запросов». Обычно сервер отправляет ответ вместе с дополнительной информацией о разрешенной частоте запросов запрашивающей стороне, а также заголовок, указывающий количество времени, необходимое для ожидания попытки выполнения другого запроса.

Этот заголовок обычно называется «Retry-After» в соответствии с лучшими практиками, описанными в спецификации RFC.Хотя это и не является строго необходимым, это хороший протокол, которому нужно следовать, чтобы пользователи знали о требованиях сети.

Три типа ограничений ставок

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

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

Ограничение скорости пользователя

Самый распространенный тип ограничения скорости, ограничение скорости пользователя отслеживает ключ API пользователя, файл cookie сеанса и IP-адрес для отслеживания количества сделанных запросов. Если количество запросов превышает лимит, пользователь должен дождаться сброса временного интервала, что обычно обозначается количеством времени ожидания, отправляемым через сообщение, прикрепленное к заголовку «Retry-After».

В некоторых случаях пользователи могут обсудить с разработчиками способ увеличения их лимита или сброса временного интервала «Retry-After», позволяющего им получить доступ к сети, не дожидаясь ожидания.

Ограничение скорости на основе времени

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

Ограничение скорости сервера

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

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

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

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

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

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

Этот процесс соответствует первому Алгоритм планирования -in-first-out (FIFO), поскольку запросы, которые поступили первыми, обрабатываются до запросов, которые следовали за ними в очереди. Вода, которая вытекает из отверстий внизу, представляет запросы, которые обрабатывает сервер. Когда количество запросов увеличивается, они сохраняются во временном бэклоге для обработки с постоянной скоростью в пределах корзины.

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

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

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

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

До сих пор я рассказывал, как ограничения скорости регулируют использование API как со стороны потребителя, так и со стороны сервера. Но между этими двумя сторонами существуют и другие технологии, которые также должны соблюдать эти правила.

Единое ограничение скорости

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

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

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

Тактики, которые следует учитывать для унифицированных API

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

Обычно алгоритмы ограничения скорости отслеживают количество запросов за короткий период времени, например, одну секунду или одну минуту. Если запросы превышают пороговое значение, вы обычно увидите ответы об ошибках с кодом состояния 429. Сюда входит заголовок «Retry-After».

Унифицированные API-интерфейсы должны предпринимать шаги для унификации заголовка Retry-After, который возвращается через каждый API, а затем откладывать и повторять запросы на срок до 30 секунд в зависимости от рекомендаций и передовых методов каждого конкретного API.За счет автоматизации этого процесса унифицированный API снимает большую часть ручной работы из рук пользователя, оптимизируя процесс использования API.

Квоты и унифицированные API

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

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

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

Реализация квот

Некоторые API-интерфейсы устанавливают квоту для клиента. Например, Salesforce ограничивает количество запросов на одного клиента в зависимости от версии Salesforce и количества лицензий. Salesforce накладывает это ограничение на использование клиентом запросов API, а не на конкретное приложение разработчика.

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

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

Унифицированные API-интерфейсы должны активно обращаться к этим API-интерфейсам, чтобы запросить увеличение предела, если это оправдано, или дать разработчикам знать, чтобы запросить более высокий предел скорости, если необходимо.

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

Например, для Egnyte API по умолчанию установлено ограничение в 1000 запросов на одного авторизованного пользователя в день.Это в дополнение к ограничению скорости в два запроса в секунду. Поскольку эти запросы устанавливаются на основе отдельного пользователя, превышение ограничения скорости для пользователя не влияет на способность приложения делать запросы к учетным записям других пользователей.

Задайте стратегию ограничения скорости API

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

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

Продолжайте изучать

Пределы скорости API | Узнайте, что они из себя представляют и как они помогают

Ограничение скорости API — это просто контроль количества запросов или вызовов, которые потребитель API может сделать к вашему API.Возможно, вы столкнулись с чем-то связанным как потребитель с ошибками о «слишком большом количестве подключений» или чем-то подобным, когда вы посещаете веб-сайт или используете приложение.

Что такое потребитель API?

Потребителем API может быть мобильное приложение, веб-сайт или даже дверной звонок или термостат! Все, что обращается к API для получения данных, является потребителем API. Это делается через запросы API.

🎬 Дополнительные видеоролики по API можно посмотреть здесь!

Что такое запрос API?

Запрос (или вызов) API — это когда один из этих потребителей, скажем, ваш термостат, запрашивает информацию из «облака» (или серверов в Интернете).

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

Это будет запрос API.

Наибольшее количество запросов к API поступает от мобильных приложений. Одно мобильное приложение может сделать от 10 до 20 запросов API, просто вы открываете приложение и входите в систему!

Как обычно устанавливаются ограничения скорости API?

Пределы скорости API обычно устанавливаются для ограничения количества запросов:

• в секунду
• в минуту
• в час
• в день (или 24-часовые периоды)
• в месяц

An API не ограничивается выбором только одного из них.У вас может быть одно ограничение скорости API в секунду и другое ограничение скорости API в час. Одновременно могут быть активны один или несколько ограничений скорости API.

Ограничение скорости API может быть реализовано по-разному в зависимости от того, аутентифицированы вы или нет. Аутентифицированным пользователям API (или потребителям API, включившим свои учетные данные в вызов API) может быть разрешено больше запросов, чем анонимным пользователям.

Нужно ли мне применять ограничение скорости API?

Скорее всего, да. Но важно понимать причины, по которым они могут вам понадобиться.Если вы собираетесь измерить успех (или неудачу) ограничения скорости, у вас должна быть четкая и определенная цель.

Каковы обычно причины необходимости ограничения скорости API?

Вот несколько причин, которые вы можете услышать, но не все из этих проблем лучше всего решаются с помощью ограничений скорости API!

Защитите свои API от распределенных атак типа «отказ в обслуживании» или DDoS-атак.

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

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

Ограничьте свои внутренние расходы и затраты

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

Хотя это может и не повредить ваш API, это может стоить вам немалых денег, потому что вы тот, кто должен платить за все внутренние серверы и службы, которые заставляют этот погодный API работать! Ограничивая количество звонков для каждого потребителя, вы можете защитить свои ресурсы и деньги!

Обход аппаратных ограничений

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

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

Какие у меня есть варианты реализации ограничений скорости API?

• Существует несколько различных способов обработки ограничений скорости API: Hard Stop : Это означает, что потребитель API получит ошибку 429 при вызове вашего API, если он превысит свой предел.

• Мягкий останов : В этом случае у вас может быть льготный период, когда вызовы можно продолжать делать в течение короткого периода после того, как будет достигнут предел.
• Регулируемая остановка : Возможно, вы просто захотите принудительно замедлить вызовы, сделанные сверх лимита. Таким образом, пользователи могут продолжать совершать звонки, но они будут медленнее из-за превышения лимита.
• Платежная остановка : Здесь вы можете просто взимать плату с потребителя API за вызовы, совершенные сверх установленного лимита.Очевидно, это будет работать только для аутентифицированных пользователей API, но может быть допустимым решением.

💡 Бонусные подсказки для ограничения скорости API!

Если вы не хотите, чтобы пользователи API ненавидели вас, вам нужно сделать три вещи:

1 ️ ⃣ Не жадничайте

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

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

2 ️ ⃣ Будьте прозрачными и информативными

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

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

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

3 ️ ⃣ Сообщите потребителям API, каков статус их ограничений API при каждом вызове.

Есть несколько разных способов реализовать это, но большинство API добавят заголовок к ответу API, который сообщает потребителю, сколько вызовов у него осталось за этот период и когда счетчик будет сброшен.

Таким образом, потребители API могут принимать информированные решения о том, когда (и сколько) вызовов API выполнять.

💡 Подробнее о стратегии API и передовых методах [Бесплатная загрузка]

Что такое ограничение скорости API? | API, которые вы не будете ненавидеть

Что такое ограничение скорости API?

Что-то, о чем клиенты API (приложения, взаимодействующие с API) не часто знают, но часто встречается, ограничивает скорость; API говорит вам немного успокоиться, и замедлить, сколько запросов делается за определенный период времени.Большинство основная стратегия ограничения скорости часто такова: «клиенты могут отправлять только X запросов за второй ».

Многие API-интерфейсы реализуют ограничение скорости, чтобы обеспечить относительную стабильность в непредвиденных случаях. всякое случается. Если по какой-то причине один клиент вызывает всплеск трафика, API должен продолжать работать без сбоев для других пользователей. А некорректное поведение (или вредоносный сценарий) может привести к перегрузке ресурсов или системам API могут столкнуться с трудностями, и им необходимо снизить предел ставки для «более низких приоритетный «трафик».Иногда это происходит потому, что компания, предоставляющая API превзошли самые смелые мечты и хотят брать деньги за увеличение ограничение скорости для пользователей с высокой пропускной способностью.

Часто ограничение скорости связано с «ключом API» или «токеном доступа», и наши друзья из Nordic API очень хорошо объясняют некоторые другие стратегии ограничения скорости:

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

Наконец, разработчик API может реализовать региональные ограничения данных, которые ограничивают звонки по регионам. Это особенно полезно при реализации на основе поведения ограничение; например, разработчик ожидает, что количество запросов во время полночь в Северной Америке должна быть ниже базовой дневной нормы, а любые поведение, противоречащее этому, без уважительной причины может указывать на сомнительные Мероприятия. Ограничивая область на определенный период времени, это может быть предотвратил. — скандинавский API-интерфейсы

Все справедливые причины, но для клиента это может быть немного надоедливым.

Регулирование вызовов API

Существует множество способов ограничения вызовов API, и это очень важно. зависит от того, откуда звонят.

Одной из самых сложных вещей для ограничения является выполнение вызовов API третьей стороне. непосредственно клиенту. Например, если ваши клиенты iOS / web / etc делают Google Map API вызывает непосредственно из приложения, вы можете очень мало сделать, чтобы задушить это. Вам просто нужно будет заплатить за правильное использование уровень для того, сколько у вас пользователей.

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

Если этот процесс обрабатывает вещи синхронно, это может не сработать, и вам может понадобиться что-то вроде 4 процессов, обрабатывающих 5 запросов на второй каждый, но вы поняли идею.

Если бы этот процесс был реализован в NodeJS, вы могли бы использовать Узкое место.

  const Узкое место = require ("узкое место");



const limiter = новое узкое место ({
 maxConcurrent: 5,
 minTime: 1000
});

const fetchPokemon = id => {
 вернуть pokedex.getPokemon (id);
};

limiter.schedule (fetchPokemon, id) .then (result => {
 
});  

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

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

Я ограничен в ставке?

Соответствующий код состояния HTTP для ограничения скорости обсуждался примерно как столько же, сколько табуляции против пробелов, но теперь есть явный победитель; RFC 6585 определяет это как 429, поэтому API-интерфейсы должны использовать 429.

http.cat — замечательный ресурс.

API Twitter существовал за несколько лет до этого стандарта, и они выбрали «420 — Enhance Your Calm». Они отказались от этого и перешли на 429, но некоторые другие скопировали их в то время и, возможно, с тех пор не обновлялись. Вы не можете исключить возможность столкнуться с API-подражателем, все еще используя этот устаревший неофициальный статус.

http.cat показывает нам, как кошка может улучшить их спокойствие.

Google также проявил немного «креатива» с использованием кода статуса.Долгое время они использовали 403 для ограничения скорости, но я понятия не имею, продолжают ли они это делать. GitHub v3 (RESTful API, который был заменен GraphQL, но все еще плавающий) по-прежнему использует 403:

  HTTP / 1.1 403 Запрещено
 60
 0
 1377013266
{
  "message": "Превышен предел скорости API для xxx.xxx.xxx.xxx. (Но вот и хорошие новости: для аутентифицированных запросов устанавливается более высокий предел скорости. Подробнее см. в документации.)",
  "documentation_url": "https: // разработчик.github.com/v3/#rate-limiting "
}  

Получение 429 (или 420) явным признаком того, что предел скорости был достигнут, и 403 в сочетании с кодом ошибки, или, возможно, некоторые заголовки HTTP также могут быть предметом для проверки. В любом случае, если вы уверены, что это ошибка ограничения скорости, вы можете перейти к следующему шагу: выяснить, как долго ждать, прежде чем повторить попытку.

Собственные заголовки

Github использует некоторые проприетарные заголовки, все начинающиеся с X-RateLimit- .Они совсем не стандартные (вы можете сказать по X-) и могут сильно отличаться от любого API, с которым вы работаете. Успешные запросы с Github здесь покажут, сколько запросов осталось, поэтому, возможно, следите за ними и старайтесь избегать запросов, если оставшаяся сумма в последнем ответе была 0.

  $ curl -i https: // api. github.com/users/octocat
HTTP / 1.1 200 ОК
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 56
X-RateLimit-Reset: 1372700873  

. Вы можете использовать общий ключ (возможно, в Redis или аналогичном), чтобы отслеживать это, и он истечет при сбросе, указанном во времени UTC в X-RateLimit-Reset.

Retry-After

Согласно RFC для HTTP / 1.1 (устаревший и нерелевантный RFC 2616 и заменяющий RFC 7230–7235) заголовок Retry-After предназначен только для 503 ошибок сервера и, возможно, перенаправляет. К счастью, RFC 6584 (тот самый, который добавил код состояния HTTP 429) говорит, что для API совершенно нормально использовать там Retry-After .

Итак, вместо потенциально бесконечного количества проприетарных альтернатив вы должны начать видеть что-то вроде этого:

  HTTP / 1.1429 Слишком много запросов
 3600
 приложение / json

{
 "message": "Превышен лимит скорости API для xxx.xxx.xxx.xxx.",
 "documentation_url": "https://developer.example.com/#rate-limiting"
}  

Альтернативным значением для Retry-After является дата HTTP:

  среда, 21 октября 2015 г. 07:28:00 GMT  

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

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

Фарадей, драгоценный камень Ruby, с которым я часто работаю, теперь знает из Retry-After . Он использует значение, помогающее рассчитать интервал между запросами на повтор.Это может быть полезно для всех, кто рассматривает возможность внедрения кода обнаружения ограничения скорости, даже если вы не фанаты Ruby.

Чтобы узнать, , как реализовать ограничение скорости, Google это! Nginx может помочь вы, шлюзы управления API как Конг и Тык молодец, или вы можете попробовать реализовать его на уровне приложения для aaaaallllll вашего API, что немного неудобно. Некоторые фреймворки, такие как Laravel (PHP) поддерживают базовое ограничение скорости вне коробка, которая чертовски круто.

Все это и многое другое в Surviving Other Peoples API , в настоящее время доступны для предварительного заказа, примерно 80% книги доступно для загрузки.

Ограничения скорости веб-службы | api.data.gov

Ограничения накладываются на количество запросов API, которые вы можете сделать с помощью своего ключа API. Пределы скорости могут отличаться в зависимости от службы, но значения по умолчанию:

• Часовой лимит: 1000 запросов в час

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

DEMO_KEY Пределы скорости

В примерах документации используется специальный ключ api DEMO_KEY . Этот ключ API можно использовать для первоначального изучения API до регистрации, но он имеет гораздо более низкие ограничения скорости, поэтому вам рекомендуется подписаться на свой собственный ключ API, если вы планируете использовать API (регистрация выполняется быстро и легко).Пределы скорости для DEMO_KEY:

• Часовой лимит: 30 запросов на IP-адрес в час
• Суточный лимит: 50 запросов на IP-адрес в день

Как я могу увидеть свое текущее использование?

Вы можете проверить текущий лимит скорости и сведения об использовании, проверив заголовки HTTP X-RateLimit-Limit и X-RateLimit-Remaining , которые возвращаются при каждом ответе API. Например, если API имеет часовой лимит по умолчанию в 1000 запросов, после выполнения 2 запросов вы получите следующие заголовки HTTP в ответ на второй запрос:

  X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 998
  

Общие сведения о временных периодах ограничения ставки

Часовой лимит

Почасовые счетчики для вашего ключа API сбрасываются на непрерывной основе.

Пример: Если вы сделали 500 запросов в 10:15 и 500 запросов в 10:25, ваш ключ API будет временно заблокирован. Эта временная блокировка вашего ключа API прекратится в 11:15, после чего вы сможете сделать 500 запросов. В 11:25 вы можете сделать еще 500 запросов.

Ответ об ошибке ограничения скорости

Если ваш ключ API превышает ограничения скорости, вы получите ответ с кодом состояния HTTP 429 (слишком много запросов).

Нужны более высокие лимиты?

Если вы создаете приложение, для которого требуются более высокие ограничения скорости, обратитесь в агентство, ответственное за API, для которого вы хотите установить более высокие ограничения скорости.

Рекомендации по предотвращению ограничения скорости — Zendesk Develop

Рекомендации по предотвращению ограничения скорости

Если вы делаете много запросов API за короткий промежуток времени, вы можете столкнуться с лимитом скорости API для запросов. Когда вы достигнете предела, Zendesk API прекратит обработку любых запросов, пока не пройдет определенное время.

Ограничения скорости для учетной записи Zendesk Support указаны в разделе «Ограничения скорости» в документации API поддержки.Ознакомьтесь с ограничениями, прежде чем начинать свой проект.

В этой статье рассматриваются следующие рекомендации по предотвращению ограничения скорости:

Мониторинг активности API в соответствии с вашим пределом скорости

Вы можете использовать панель управления API в интерфейсе администратора Zendesk Support, чтобы отслеживать активность API в сравнении с лимитом скорости за последние 24 часа. См. Раздел «Отслеживание активности API с учетом вашего ограничения скорости» в Справочном центре поддержки.

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

  Предел скорости X: 700
Остаточный предел скорости X: 699
  

Примечание : эти заголовки недоступны для запросов API Справочного центра.

Ошибки отлова, вызванные ограничением скорости

Для каждого запроса вы можете проверить, не достигли ли вы ограничения скорости. Если вы получили код ответа 429, «Слишком много запросов», вы достигли предела скорости.

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

Например, запрос curl, который наталкивается на ограничение скорости, может вернуть следующий ответ:

Ответ содержит следующую ключевую информацию:

• Статус: 429
• Retry-After: 93

Код состояния 429 означает слишком много запросов. Заголовок Retry-After указывает, что вы можете повторить вызов API через 93 секунды. Ваш код должен перестать делать дополнительные запросы API, пока не пройдет достаточно времени для повторной попытки.

Следующий псевдокод показывает простой способ отлова ошибок ограничения скорости:

  response = request.get (url)
если response.status равно 429:
    alert ("Скорость ограничена. Ожидание повторной попытки…")
    ждать (response.retry-after)
    повторить (URL)
  

Уменьшение количества запросов API

Убедитесь, что вы отправляете только те запросы, которые вам нужны. Вот области, которые следует изучить для сокращения количества запросов:

1. Оптимизируйте свой код, чтобы исключить ненужные вызовы API.

   Например, некоторые запросы получают элементы данных, которые не используются в вашем приложении? Возвращаются ли извлеченные элементы данных обратно в экземпляр продукта Zendesk без каких-либо изменений?

2. Кэшировать часто используемые данные.

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

3. Данные, связанные с неопубликованной загрузкой.

   Вы можете избежать ненужных вызовов API, загрузив один набор записей другим.Неопубликованная загрузка позволяет получить два набора записей в одном запросе. См. Раздел «Загрузка неопубликованных записей».

4. Используйте массовые и пакетные конечные точки, такие как «Обновить множество билетов», что позволяет обновлять до 100 билетов с помощью одного запроса API. См. Раздел «От 100 запросов до 1: знакомство с нашими новыми массовыми и пакетными API-интерфейсами» в блоге Zengineering.

Регулировка количества запросов

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

Чтобы определить, нужно ли реализовать процесс регулирования, проследите за ошибками запроса. Как часто вы получаете ошибку 429? Гарантирует ли частота реализации процесса дросселирования?

Часто задаваемые вопросы

• Существует ли конечная точка, которая возвращает все конечные точки для ресурса, включая различные ограничения скорости и время повторной попытки?

  Нет, мы не предоставляем конечную точку с ограничением скорости.

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

    Предел скорости X: 700
  Остаточный предел скорости X: 699
    

• Что происходит при достижении лимита скорости?

  Запрос не обрабатывается, и отправляется ответ, содержащий код ответа 429 и заголовок Retry-After. Заголовок указывает время в секундах, которое вы должны подождать, прежде чем вы сможете повторить попытку запроса.

• Уменьшит ли пакетная обработка вызовов количество вызовов API? Как насчет параллельных звонков?

  Нет, пакетные вызовы не уменьшат количество вызовов API.

  Однако использование групповой или пакетной конечной точки уменьшит количество вызовов. См. Раздел «От 100 запросов до 1: знакомство с нашими новыми массовыми и пакетными API-интерфейсами» в блоге разработчиков Zendesk.

  {
  "тип": "ошибка",
  «статус»: 429,
  "code": "rate_limit_exceeded",
  "help_url": "http://developers.box.com/docs/#errors",
  "message": "Превышен предел частоты запросов, повторите попытку позже",
  "request_id": "abcdef123456"
}