Как изменить rps сайта

обновлено: 2023-02-07 в теме: Техническое SEO

Некоторое время назад Яндекс изменил RPS для XML-поиска, об этом сообщалось каждому клиенту в электронном письме. Если вы письмо пропустили, то воспользуйтесь данной инструкцией.

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

Анализировать крупные объемы данных помогаю сервисы Яндекса. Один из них Яндекс XML:

Процесс продвижения требует изучения обстоятельств на web рынке: результаты выдачи ключевых запросов; отслеживать индивидуальные особенности поведения пользователей сайта и прочая и прочая…

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

Ключевая задача отработки данного сервиса сводится к тому, что «инструментарий сервиса» отправляет (в соответствии с настройками в аккаунте) запросы к поисковой системе Яндекса, ответы на которые получает в формате XML (все это легко копируется и читается).

Чтобы перенастроить опции XML сервиса, необходимо пройтись по ссылке — авторизоваться… либо, если вас еще нет в вебмастере Яндекса, пройти процедуру регистрации. Этот сервис важен!

По кнопке «Тест» возможно пройти тестирование настоек…

к оглавлению

Если Яндекс изменил RPS для XML — то как настроить по-новому

Как сказано в документации: Яндекс ввел некоторые ограничения в работе сервиса — якобы для обеспечения бесперебойности (и безопасности) в работы с сервисом Яндекса.

к оглавлению

XML-лимит – суточное ограничение количества запросов 1 пользователя

XML-лимит включает:

• среднесуточное ограничение количества запросов ОДНОГО пользователя;
• лимит выделяется для каждого сайта автоматически — в зависимости от Индекса качества площадки;
• часовые ограничения — относится к дополнительным. Лимиты высчитываются в процентах допустимых от суточного количества запросов.

Если ограничение (суточное) на количество запросов, скажем, 1000. То в этом случае с 7:00 до 19:00 (на каждый час) разрешается задавать не более 5% запросов от установленного лимита (50 запросов см. на фото выше).

Например, так называемые нерабочие ночные часы: с 0:00 до 7:00 утра не было отправлено НИ одного запроса, то и в этом случае, с 7:00 до 19:00 превышение в 50 запросов недопустимо (т.е. экономия лимита невозможна — «простой» сгорает) — ограничение есть ограничение!

Таким образом в так называемые сутки получается что возможны отправления не более 600 запросов!

к оглавлению

яндекс изменил RPS — ограничения на количество запросов в секунду (RPS)

Обратите внимание на параметр (rps_restriction) — формирование определенного допустимого количества запросов в секунду в полной зависимости от часового ограничения (hourly_limit) — индивидуально для сайта!

Как и говорилось выше — до 20 февраля 2023 г. требуется внести коррекции в настройки XML сервиса.

Ранее почасовая квота (при расчете) зависела от разделения на 2000, теперь же при расчете RPS на 3420.

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

rps_restriction = hourly_limit / 3420

Важно: превышение порога hourly_limit — нарушения правил — как правило ведет к ошибкам!

Подключаем Турбо Страницы Яндекса (на ютюб-канале — есть видео о том, как удалить эти Турбо страницы из индекса Яндекса, если потребуется. Многие подключают, а потом решают избавиться от этих турбо… А задача не так уж и проста!..

Отключаем Турбо страницы Яндекса

…вопросы в комментариях — помогу, в чём дюжу…
mihalica.ru !

Функции

1.Redirect Provisioning Server
Redirect Provisioning Server – Сервер Перенаправления На Сервер Автоконфигурирования (RPS) это промежуточное устройство, которое обеспечивает функцию перенаправления между IP телефоном Akuvox и сервером авто конфигурирования. Телефон пользователя может получить URL для авто конфигурирования от Akuvox RPS, затем скачивать файл common.cfg или MAC.cfg с сервера автоконфигурирования.

2.RPS API протокол
API RPS построен как стандартные XML-RPC сервисы, пользователь может отправлять XML-команды через HTTP POST, используя content-Type: text / xml для изменения данных RPS. Аутентификация пользователя осуществляется с помощью обычной аутентификации с использованием имени пользователя и пароля.

3. URL для службы

http://58.96.188.87/fcgi/do?id=1

4. Пользовательские аккаунты
Для доступа к RPS у пользователя должна быть действительная учетная запись для функционирования команд API, учетная запись предоставляется оператором Akuvox. Если у вас есть какие-либо вопросы, пожалуйста, напишите нам techsupport@akuvox.com

Команды XML-RPC

1.redirect.registerDevice

Регистрация устройства в RPS по MAC ID.

1.Подпись 1XML-RPC
redirect.registerDevice(mac,serverName)

1.2 Параметр
1. mac : MAC адрес, который нужно зарегистрировать в RPS.
2. serverName: Название сервера RPS, в котором будет регистрироваться устройство.

1.3 Возвращаемые значения

1.4 Пример

Request

Примечание
1. Строку ”<![CDATA[ ]]>” можно убрать.
2. Четыре допустимых формата MAC адреса 0C1105002189, 0C 11 05 00 21 89, 0C-11-05-00-21-89, 0C:11:05:00:21:89.

Успешный ответ

Отрицательный ответ

2.redirect.registerDevice

Если устройство, которое вы хотите зарегистрировать, уже добавлено, вы можете перезаписать информацию о нём с помощью параметра “isOverride”.

2.Команда 1XML-RPC
redirect.registerDevice(mac,serverName,isOverride)

2.2 Параметр
1. mac: MAC адрес устройства для регистрации в RPS.
2. serverName: Название сервера на RPS, на котором будет регистрироваться устройство.
3. isOverride：Подтверждение, нужно ли перезаписать существующий MAC.
(1) 1：Подтвердить
(2) 0：Отмена

2.3 Возвращаемые значения

2.4 Пример
Запрос

Положительный ответ

Отрицательный ответ

3.redirect.deRegisterDevice

Можете удалить устройство из RPS через его MAC id.
3.1 Команда XML-RPC
redirect.deRegisterDevice(mac)
3.2 Параметр
mac: MAC адрес устройство RPS
3.3 Возвращаемые значения

3.4 Пример
Запрос

Позитивный ответ

Отрицательный ответ

4. redirect.listDevices

Выводит список всех устройств(MACs), которые вы уже зарегистрировали.
4.1 Команда XML-RPC
redirect.listDevices()
4.2 Возвращаемые значения

4.3 Пример
Запрос

Положительный ответ

Негативный ответ

5. redirect.checkDevice

Вы можете проверить (MACs), зарегистрировано ли устройство в RPS.
5.1 Команда XML-RPC
redirect.checkDevice(mac)
5.2 Параметр
mac: MAC адрес для проверки.
5.3 Возвращаемые значения

5.4 Пример
Запрос

Положительный ответ

Негативный ответ

6.redirect.registerDevices

Пользователь может зарегистрировать устройства по списку из MAC ID.

6.1 Команда XML-RPC

redirect.registerDevices(macList,serverName)

6.2 Parameter

1. mac : MAC адрес устройства для регистрации на RPS. 2. serverName: название сервера, добавленного на RPS, на котором будет регистрироваться устройство

6.3 Возвращаемые устройства

6.4 Пример
Запрос

Позитивный ответ

Отрицательный ответ

7. redirect.registerDevices[2]

Если MAC адреса из списка уже зарегистрированы ранее, вы можете перезаписать их через параметр isOverride.

7.1 Команда XML-RPC

redirect.registerDevices(macList,serverName,isOverride)

7.2 Parameter
1. macList: MAC адреса для регистрации на RPS.
2. serverName: Название сервера, уже добавленного на RPS, на который будет регистрироваться устройство.
3. isOverride：Подтвердить перезапись зарегистрированного устройства.
(1) 1：подтвердить
(2) 0：отмена перезаписи

7.3 Возвращаемые значения

7.4 Пример
Запрос

Положительный ответ

Отрицательный ответ

8.redirect.deRegisterDevices

Вы можете удалить список устройств из RPS с помощью списка MAC адресов.
8.1 Команда XML-RPC
redirect.deRegisterDevices(macList)
8.2 Параметр
macList: MAC адреса, которые нужно удалить из RPS
8.3 Возвращаемые значения

8.4 Пример
Запрос

Положительный ответ

Отрицательный ответ

9. redirect.addServer

Вы можете прописать специальную конфигурацию для сервера на RPS.
9.1 Команда XML-RPC
redirect.addServer(serverName,serverUrl)
9.2 Параметр
1. serverName: Название сервера на RPS, на который устройство будет перенаправлено
2. serverUrl: Специальный URL для конфигурирования.
9.3 Возвращаемые значения

9.4 Пример
Запрос

Положительный ответ

Отрицательный ответ

10.redirect.editDevice

Вы можете изменить сервер, на котором будут регистрироваться устройства
10.1 Команда XML-RPC
redirect.editDevice(mac,serverName)
10.2 Параметр
1. mac : MAC адрес, который будет изменен.
2. serverName: Название сервера, на котором будет происходить регистрация устройства
10.3 Возвращаемые значения

10.4 Пример
Запрос

Положительный ответ

Отрицательный ответ

11.redirect.editDevice[2]

Если MAC адрес устройства, который вы пытаетесь зарегистрировать, уже существует на сервере, вы можете перезаписать его, используя параметр isOverride.
11.1 Команда XML-RPC
redirect.editDevice(mac,serverName,isOverride)
11.2 Параметр
1. mac : MAC адрес устройства.
2. serverName: Название сервера, на котором хотите перезаписать MAC.
3. isOverride: подтверждение процесса перезаписывания .
(1) 1：Подтверждение
(2) 0：Отмена

11.3 Возвращаемые значения

11.4 Пример
Запрос

Положительный ответ

Отрицательный ответ

Хотите, чтобы ваш стартап или IT-проект вырос? Чтобы вашим сайтом пользовалось больше людей и прибыль росла? Но справятся ли ваши серверы, сервисы, базы данных? В этой статье разбираемся, как найти «место», куда нужно подложить соломку, чтобы выдержать нагрузку.

Работа приложений и сайтов обычно зависит от того, сколько людей их используют. То, что работало при посещаемости 100 человек в день, может не выдержать, если тысяча человек попробует одновременно воспользоваться сервисом: база данных не сможет с той же скоростью обрабатывать возросшее число запросов, диски могут не справиться с количеством операций чтения-записи, может не хватить оперативной памяти — словом, вариантов негативного сценария хватает. Но развязка для всех одна: если сервис станет работать слишком медленно, то пользователи, не дождавшись результата, начнут уходить. Ну, а если он просто «упадёт», то вы совсем потеряете клиентов. IT-инфраструктура в этом смысле не отличается от любой другой — у неё есть запас прочности и ресурс нагрузки, которую можно выдержать.

Если провести аналогию с грузоперевозками, то каждому понятно, что на легковой курьерской машине не увезти мебель. Или что даже если в открытый кузов маленького грузовичка можно положить 5 тонн кирпича, он всё равно не сможет их увезти. С IT-системами также — и нагрузочное тестирование нужно, чтобы выяснить «максимальную снаряжённую массу». А еще — чтобы понять, где можно потюнить и в итоге, продолжая аналогию, всё же возить больше: переоборудовать салон, поменять подвеску, поставить грузовые шины или просто-напросто по-другому складывать коробки.

«Надо просто, чтобы предела не было. Тогда и проблем не будет»

Если смотреть с точки зрения заказчика, который покупает услуги разработки, то ожидания, что исполнитель сразу предусмотрит все узкие места и оптимально настроит серверное окружение, вполне понятны. Так же, как и недовольство, если что-то пошло не так. А ещё бывает, что система вроде бы работает, а программисты или админы утверждают: всё нужно переделывать и увеличивать бюджет на инфраструктуру. Как тут не огорчиться?

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

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

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

Тестирование на максимальную нагрузку

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

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

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

Что проверяет нагрузочное тестирование

Как и в любом другом тестировании, в нагрузочном воспроизводят все основные действия пользователей и таким образом проверяют важные для бизнеса сценарии. Для интернет-магазинов это, например, вход в личный кабинет, просмотр и выбор каталогов, добавление товаров в корзину, оформление заказа, оплата. Для СМИ — сёрфинг по новостям, оформление подписки, новостные рассылки и т.д.

Либо, исходя из требований заказчика, в ходе тестирования можно сосредоточиться на каком-то одном элементе системы — том, который наиболее критичен для бизнеса, или том, который выглядит самым узким местом. Это также может быть оформление заказа или, например, регистрация и авторизация пользователей. Вход на сайт часто необходим для полноценной работы с сервисом и при этом легко оказывается бутылочным горлышком — так, например, было у «Тотального диктанта» (о том, как готовили сайт «Тотального диктанта» к нагрузке карантинного 2021-го, смотрите в отдельной статье).

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

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

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

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

Длинные тесты необходимы, чтобы проверить, как сервис будет работать под продолжительной высокой нагрузкой. Они позволяют найти слабые места, которые не проявляются при кратковременном пиковом воздействии. Если продолжать аналогию с автомобилем, то здесь мы проверяем не разгон, а, например, хотим убедиться, что на скорости 200 км/ч у нас не отвалятся колёса и не перегреется мотор. Для веб-сервиса это, скорее, случай органически возросшей нагрузки, когда пользователей много в течение длительного периода, а не в отдельные моменты времени.

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

На скриншоте выше пример длительного теста: при заданной нагрузке сайт сначала работает корректно и с приемлемой скоростью, использование памяти, CPU и других элементов инфраструктуры держится на стабильном уровне, но потом некие запросы к базе данных накапливаются и повышают нагрузку на сервер и БД, приводя к проблемам производительности. В процессе теста мы смогли отследить накопившиеся запросы к каталогу и найти причину — и придумали способ изменить запросы, чтобы они работали быстрее и требовали меньше ресурсов. При этом тест получился условно «длинным», хватило примерно 10 минут, чтобы засечь проблемы. В других случаях мы можем нагружать инфраструктуру по несколько часов — то есть продолжительность определяется, исходя из потребностей и результатов. Вообще, нагрузочное тестирование можно провести с любым сетапом — будь то один «железный» сервер или managed Kubernetes в облаке — и проверить именно те узлы, которые важны в данном конкретном случае.

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

И всё-таки: когда всё это нужно?

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

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

А сценарии, в которых показано нагрузочное тестирование, могут быть такими:

Что делать с результатами?

Главным полезным результатом нагрузочного тестирования должно являться:

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

«А можно я сам?»

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

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