Просмотр полной версии : [Вконтакте] ограничение 3 запроса в секунду
17.03.2010, 21:21
сабж еще имеет место или его упразднили?
чего спрашиваю — test_mode: 0, приложение включено, в коде стоят тупо три запроса подряд — и все отлично!
ну не может же быть такого, что у меня на компе/браузере просто чудом все так тормозит?
17.03.2010, 21:25
Три запроса никак не могут превысить лимит трех запросов в секунду 🙂 Вот четыре могут.
17.03.2010, 21:31
вот ты сейчас. это ППЦ. может поспать 0о
надо как-то спрятать этот топик ))) пока меня не засмеяли.
спасибо )
17.03.2010, 21:34
так вроде появился способ постить несколько запросов за раз..
Универсальный метод, который позволяет запускать последовательность других методов, сохраняя и фильтруя промежуточные результаты.
17.03.2010, 21:42
2udaaff: 5 запросов подряд, полет нормальный. мож все-таки того, упразднили?
UPD:
все. зафлудил api. отбой — ограничение в силе.
Автопостинг ВК | Получение access token, выполнение запроса, извлечение шуток
17.03.2010, 22:17
Вопрос в продолжение темы.
Интересно а получится ли использовать AS3 function setTimeout()?
Ведь если ее привязать к вызову обращения к api.. и поставить задержку 333 мсек., то можно подряд поставить хоть 10 запросов — они будут идти по правилу..
17.03.2010, 23:41
2udaaff: 5 запросов подряд, полет нормальный. мож все-таки того, упразднили?
UPD:
все. зафлудил api. отбой — ограничение в силе.
Ну там от трех до пяти, вообще. А на деле как получится.
Интересно а получится ли использовать AS3 function setTimeout()?
Ведь если ее привязать к вызову обращения к api.. и поставить задержку 333 мсек., то можно подряд поставить хоть 10 запросов — они будут идти по правилу..
Получится. Но лучше следить за тем, чтобы в определенный интервал времени не попадало три запроса, а не после каждого лепить задержку. Потому-что, например, если нам нужно будет отправить в минуту 3 запроса, то нам задержки не нужно будет делать никакие. И, имхо, удобнее Timer использовать. + Если ошибка по количеству запросов, то повторно вызывать тот метод, который вернул ошибку.
И такой точности не будет, что ровнехонько через 333 мс контакт их всех нормально проглотит. Через какие промежутки времени эти запросы доберутся до контакта — это не известно никому 🙂 И как они там обрабатываются тоже. Так что лучше не более трех запросов в 1.5, а то и в 2 секунды отправлять.
17.03.2010, 23:55
Там, кстати, ограничения, насколько я помню, звучало не как 3 запроса в секунду, а как обращение со стороны приложения к серверу не чаще, чем 1 раз в 0.5 сек (это, кстати, не одно и то же, поскольку в 2 сек не 6 запросов, а только 5).
Но я подозреваю, на самом деле они это ограничение банально сняли в целях повышения производительности.
К тому же сейчас все пользуют в основном execute, так что многократные запросы нужны только если делать чат на базе ВК.
18.03.2010, 00:03
2mikhailk:
API для начинающих. Пример VK. [1/5]
1. не слышал как звучало про 0.5, читаю как звучит про 0.333: Сервер принимает не более трёх запросов в секунду.
2. никто ничего не снял, все в действии.
2Raikary:
все проще — элегантно расширяешь URLLoader и делаешь свой класс, который сам следит за очередью с помощью определенной логики. я так и хотел делать, а потом лень заставила усомниться, что это надо =)
18.03.2010, 00:23
ок, изменили
я читал описание API по этому поводу в декабре, тогда там стояло раз в 0.5 сек
Кстати, не хочу быть занудой, но три запроса в секунду — это не обязательно 0.3333
Относительно того, как эта кухня устроена внутри, думаю, снаружи все равно не угадать. Подозреваю, что для каждого экземпляра приложения создается переменная с временем жизни 1 сек (например, в том же мемкеше), которая инкрементится при каждом обращении экземпляра приложения. Это проще, чем контролировать интервал между обращениями. Если я прав, то при определенном стечении обстоятельств сервер может принять до шести запросов в секунду — когда первые три запроса придутся на вторую половину первой секунды серверного времени, а вторые — на первую половину второй. Просто первые три запроса будут учтены в одном счетчике, а вторые три — во втором.
18.03.2010, 04:21
хм. я читал это в сентябре 0о — было три запроса. в декабре какого года? 😉
относительно второй части рассуждений. если ты будешь посылать запросы с таймаутом в .34 (с запасом идем) — ты технически не сможешь послать больше 3 запросов в любые 1000мс, как бы ни был устроен счетчик на стороне сервера.
18.03.2010, 19:14
а зачем контролировать таймаут?
контролировать количество обращений существенно менее трудозатратно.
Но это все пустой разговор. )))
18.03.2010, 19:52
ну тут не посоветую, не занимался анализом того, «как у них там».
я сделал проще (как для меня). расширил URLLoader. новый запрос смотрит, есть ли текущий запрос в работе. если да — подписывается на его OPEN и после этого считает до 340 и спрашивает «по своим делам». и так каждый.
т.е. я вообще «снаружи» не заморачиваюсь — частим/не_частим. пользуюсь как обычным URLLoader-ом.
18.03.2010, 22:41
по теме, наткнулся на след информацию:
ВОПРОС: Сколько запросов в секунду можно делать к api из приложения и со стороннего сервера?
ОТВЕТ:
3 запроса в секунду от каждого уникального пользователя, запустившего приложение со стороны приложения. Количество запросов от сервера зависит от количества пользователей, установивших приложение. Если приложение установило меньше 10 000 человек, то можно совершать 5 запросов в секунду, до 100 000 – 8 запросов, до 1 000 000 – 20 запросов, больше 1 млн. – 35 запросов в секунду. Числа могут поменяться со временем.
21.03.2010, 13:19
Практика показывает, что таких ограничений не имеет места быть! у приложения в 3.5млн можно 4мя запросами с паузой 0.34 получить ошибку to many requests.
если ты будешь посылать запросы с таймаутом в .34 (с запасом идем) — ты технически не сможешь послать больше 3 запросов в любые 1000мс, как бы ни был устроен счетчик на стороне сервера.
Послать — действительно не получится. Но как вконтакт их сможет принять — вопрос. Особенности tcp-ip таковы, что на премной стороне не гарантируется даже соблюдение последовательности между последовательными запросами, не то что задержки. И по опыту скажу — нарушение последовательности имеет место быть очень часто, и зависит оно, как правило, от конфигурации сети.
То есть у Васи всегда срабатывает так, а у Маши — иначе. И поэтому даже если у вас оно работает, то это еще ничего не значит.
Я стараюсь делать так, чтобы больше 3х запросов не слалось впринципе. У меня это получается.
если НАДО слать много запросов — делаем очередь, и следующий запрос отправляем только после получения ответа от предыдущего и истечения паузы 0.34 между отправкой и текушим моментом. как-то так.
21.03.2010, 13:26
Особенности tcp-ip таковы, что на премной стороне не гарантируется даже соблюдение последовательности между последовательными запросами, не то что задержки.
Вообще-то именно TCP/IP гарантирует и доставку и правильную последовательность, в отличие от UDP.
И по опыту скажу — нарушение последовательности имеет место быть очень часто, и зависит оно, как правило, от конфигурации сети. То есть у Васи всегда срабатывает так, а у Маши — иначе. И поэтому даже если у вас оно работает, то это еще ничего не значит.
Почему-то у нас с 3 млн. пользователями такого никогда не случалось, а у вас вдруг TCP/IP виноват. Это ваши руки, а не Вася или Маша.
21.03.2010, 14:41
Послать — действительно не получится. Но как вконтакт их сможет принять — вопрос.
Ну вообще-то время я начинаю отсчитывать после события OPEN предшествующего запроса. А это, если я правильно понял доки (и в любом случае убедился на тесте), гарантирует не просто бомбардировку сервера контакта с интервалом 0.34, а соблюдение интервала с учетом отклика. Т.е. сервер не может из-за каких-то тормозов сплошной стопкой получить то, что я честно отделил временным промежутком.
поскольку при ошибке ВКонтакт возвращает все данные о запросе, то в ответе можно выловить нужную инфу нужную для запроса (если она не постоянна, а в цикле, либо функции)
а кто-нибудь знает, поговаривают, что есть ограничение на количество запросов в час?
Источник: flasher.ru
Ограничения VK API для крупного сервиса
Всем привет! Подскажите, кто-то сталкивался с ограничениями VK API (3 запроса в секунду)? Такая проблема всплывает потихоньку: планируется вызов API каждую минуту для списка юзеров, в будущем юзеров будет много (больше 1000) и для каждого нужно делать запросы каждую минуту. Получается, что в эти ограничения я не вписываюсь никак. Что посоветуете сделать?
Сам вижу пока единственный вариант – использовать для API не одно приложение ВК, а множество, и распределять юзеров равномерно между приложениями.
- Переходы по ссылкам на сайтах от ботов
- Facebook добавил в Messenger API поддержку Instagram
- Как размножить статью?
На сайте с 12.04.2015
21 апреля 2017, 12:33
расскажите свой кейс? Нельзя ли группировать запросы? почему раз в минуту? и так далее. Вам запросы нужны только для тех кто онлайн? Или для всех независимо (тогда опять же зачем 1 раз в минуту)?
Мне кажется вам для начала нужно продумать архитектуру взаимодействия с апи ВК.
Разработка проектов на Symfony, Laravel, 1C-Bitrix, UMI.CMS, OctoberCMS
На сайте с 06.09.2012
21 апреля 2017, 13:17
Aisamiery, раз в минуту сервис делает определенные действия для пользователя. Группировать можно, но опять же, для одного пользователя будет одна группа запросов, API не позволяет делать для нескольких сразу.
На сайте с 12.04.2015
21 апреля 2017, 14:02
так а чем обусловлена такая частота? что за кейс то? 🙂
На сайте с 17.08.2010
21 апреля 2017, 17:30
в саппорт писали?
Всё ещё лучший способ заработка для белых сайтов: GoGetLinks (https://www.gogetlinks.net/?inv=fahbn8).
На сайте с 06.09.2012
21 апреля 2017, 22:58
TF-Studio, execute не подходит. Вроде разобрался, буду тестировать еще. Походу это ограничения на один токен, то есть должно все работать, так как у меня для каждого пользователя свой токен имеется.
Источник: searchengines.guru
Три запроса в секунду к VK API, давайте разберемся
Не помню точно где вычитал, но есть такая тема — запросы к VK API можно посылать не чаще чем 3 раза в секунду.
Сначала я не использовал никаких пауз и запросы(audioSearch) шли один за одним. Где-то в каждом 6-ом ответе получал «Too many requests per second»
Затем сделал паузу в 340 мс. «Too many requests per second» исчезли. Но естественно приложение стало работать медленнее.
Но именно в такой версии отправил приложение на одобрение. Его одобрили.
Затем делал эксперименты — изменил код по следующему принципу — сначала Pause = 0, но как только приходит «Too many requests per second» Pause += 100; это миллисекунды. Если придет «Too many requests per second» еще раз еще Pause += 100;
Скорость увеличилась в два раза.
Но одобрит ли это администрация не знаю.
Кто что знает о количестве запросов в 1 секунду? Насколько плохо часто получать ответ «Too many requests per second»?
Почему спрашиваю! Заметил в одном приложении как динамично подгружались данные о кол-ве аудиозаписей моих друзей. И там явно было больше 3-х запросов в секунду.
Источник: flapps.ru