ограничение 3 запроса в секунду

[Zebestov]

сабж еще имеет место или его упразднили?
чего спрашиваю — test_mode: 0, приложение включено, в коде стоят тупо три запроса подряд — и все отлично!
ну не может же быть такого, что у меня на компе/браузере просто чудом все так тормозит?

[udaaff]

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

[Zebestov]

вот ты сейчас... это ППЦ... может поспать 0о
надо как-то спрятать этот топик ))) пока меня не засмеяли...
спасибо )

[Raikary]

так вроде появился способ постить несколько запросов за раз..

execute

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

Поддерживаются арифметические операции, массивы, списки, parseInt, parseDouble, конкатенация (+), фильтр массива по параметру (@.), создание массивов и списков ([X,Y]), вызовы методов API. В данный момент не поддерживаются функции, логические операции, циклы и условия.

[Zebestov]

2udaaff: 5 запросов подряд, полет нормальный... мож все-таки того, упразднили?

UPD:
все. зафлудил api. отбой — ограничение в силе.

[Raikary]

Вопрос в продолжение темы.

Интересно а получится ли использовать AS3 function setTimeout()?

Ведь если ее привязать к вызову обращения к api.. и поставить задержку 333 мсек., то можно подряд поставить хоть 10 запросов - они будут идти по правилу..

[udaaff]

Сообщение от Zebestov

2udaaff: 5 запросов подряд, полет нормальный... мож все-таки того, упразднили?

UPD:
все. зафлудил api. отбой — ограничение в силе.

Ну там от трех до пяти, вообще. А на деле как получится.

Интересно а получится ли использовать AS3 function setTimeout()?

Ведь если ее привязать к вызову обращения к api.. и поставить задержку 333 мсек., то можно подряд поставить хоть 10 запросов - они будут идти по правилу..

Получится. Но лучше следить за тем, чтобы в определенный интервал времени не попадало три запроса, а не после каждого лепить задержку. Потому-что, например, если нам нужно будет отправить в минуту 3 запроса, то нам задержки не нужно будет делать никакие. И, имхо, удобнее Timer использовать. + Если ошибка по количеству запросов, то повторно вызывать тот метод, который вернул ошибку. И такой точности не будет, что ровнехонько через 333 мс контакт их всех нормально проглотит. Через какие промежутки времени эти запросы доберутся до контакта — это не известно никому И как они там обрабатываются тоже. Так что лучше не более трех запросов в 1.5, а то и в 2 секунды отправлять.

[mikhailk]

Там, кстати, ограничения, насколько я помню, звучало не как 3 запроса в секунду, а как обращение со стороны приложения к серверу не чаще, чем 1 раз в 0.5 сек (это, кстати, не одно и то же, поскольку в 2 сек не 6 запросов, а только 5).

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

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

[Zebestov]

2mikhailk:
1. не слышал как звучало про 0.5, читаю как звучит про 0.333: Сервер принимает не более трёх запросов в секунду...
2. никто ничего не снял, все в действии.

2Raikary:
все проще — элегантно расширяешь URLLoader и делаешь свой класс, который сам следит за очередью с помощью определенной логики... я так и хотел делать, а потом лень заставила усомниться, что это надо =)

[mikhailk]

ок, изменили
я читал описание API по этому поводу в декабре, тогда там стояло раз в 0.5 сек
Кстати, не хочу быть занудой, но три запроса в секунду - это не обязательно 0.3333

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