Регистрация  |  Вход

Новый подход к расчету лимитов для асинхронных процессов. Daily asynchronous limit

Привет друзья. Сегодня хочу поделиться с вами новостью по поводу изменения лимитов с приходом новой версии API Summer 13. Каждый новый релиз приносит приятные изменения в лимитах SF в сторону их увеличения, что позволяет нам спокойнее себя чувствовать при разработке "тяжелых" алгоритмов. На этот раз команда Salesforce отошла от традиции и внесла изменения не в размер лимитов, и в подход их расчетов. Я говорю про лимиты по количеству вызовов асинхронных процессов (asynchronous processes).



До последнего релиза лимиты на вызовы @future методов и запуск batch считались по разному. Количество вызовов @future методов рассчитывалось на сутки и зависело от количества купленных лицензий, количество вызовов batch за сутки  было постоянным. Это приводило к тому что в разработке применялись различные "костыли", когда вместо @future методов запускались batch и наоборот.



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



В релизе Summer 13 от обоих лимитов (@futur and batch) отказались и вели новый лимит - Daily asynchronous limit. Теперь это позволит разработчикам выбирать правильный подход к реализации асинхронных процессов независимо от того каких лицензий на орге больше. Новый лимит рассчитывается следующим образом - для каждого орга берется наибольшее из двух предыдущих значений. Т.е. у вас есть минимум 250 000 асинхронных вызовов на сутки независимо от количества лицензий. Но если у вас на орге более 1 250 лицензий (qualifying licenses), то к вышеуказанной цифре добавляется по 200 асинхронных вызовов за каждую дополнительную лицензию.



!Но если вдуматься, то получается что количество лимитов в Summer '13 УМЕНЬШИЛОСЬ. Правильно получается :( Взяли два типа лимитов, объединили и поставили цифру максимальную из двух. Salesforce этот факт подтверждает, но уверяет, что согласно статистическим данным ни один текущий орг не должен пострадать (перестать работать).



! Важно Более того с объединением всех асинхронных вызовов в один лимит, Salesforce также включили сюда вызов start и finish методов batch, а также выполнение запланированных задач (scheduled jobs executions). Ранее scheduled jobs не учитывались вообще. Чтобы загладить данный не очень приятный факт Salesforce увеличили лимит запланированных задач (scheduled jobs) на орге c 25 до 100.



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



Данные лимиты будут применены ко всем оргам и в том числе клиенты Salesforce в Москве смогут ощутить их прелесть в своих аккаунтах.