Всем привет. Я заметил что сейчас очень часто начал очень часто вылетать данная ошибка при работе с массивами по 20к строк где в циклах выполняются простейшие операции(+-/*). В основ такое массивы обрабатываются для кастомных отчетов. Года 3-4 назад я делал кастомные отчеты где участвовало в расчете 100000+ записей и все было ок. Мне кажется или SF как то замедлили что ли?
Встречал такую ошибку только там где много вложенных циклов, т.к. они съедают очень быстро cpu лимиты.
В своём коде такого не видел. Чужой переписываю. Если вижу, что расчёты очень ресурсоёмкие, то пробую их переносить на java script - там уже всё упирается в производительность пользовательской системы. Если и там тяжело считать, то самое время подумать над архитектурой, особенно, если проект писали до тебя и ты лишь добавляешь какие-то фичи. :)
Имхо, такие операции не имеют право на жизнь. Даже 10к итераций уже много.
Такие задачи должны решаться асинхронно с помощью батча, а результаты кэшироваться.
Потому что надо заранее предусматривать объемы данных - там где 10к, а тем более 20к там легко будет и 100к и 200к записей/итераций. Зачем проектировать систему которая заведомо будет работать на пределе своих возможностей???
Согласен, это жизнеспособно если отчеты делается за прошедший период и статичны. Однако если надо что бы клиент наблюдал результат в реальном времени, это решение не подойдет.
Я пришел к выводу что лучше перенести расчет на js используя apex как источник данных.
Однако вопрос был не в решении, а в том что что я наблюдаю снижение производительности самих оргов по сравнению с тем что было 4 года назад.
Я уже представляю как ваши расчеты на жабаскрипте вешают браузер и как рад по итогу будет ваш заказчик:)
Не знаю что происходит в SF по части тормозов.
НО вот это
Это тоже звиздец. Еще хуже чем пытаться все просчитать за одну сессию.
Это еще надо все данные передать на сторону JS, даже если это происходит пачками чтобы там посчитать.
Асинхронный просчет пачками в батче ничем не отличается реалтайм просчета. Просчитать 100к записей в реалтайме практически тоже самое что запустить батч на 10итераций по 10к. А клиент получит отчет как только данные подготовятся - для этого можно задействовать Streaming API.
Тем более что значит
Это вообще нонсенс - это получается как? Гонять просчеты на пределе лимитов каждую секунду?
Ну ладно! Это все лирика. Поделился впечатлениями. Как раз сейчас сражаюсь с одной проблемой из-за просчета в архитектуре API. Есть один эндпоинт который собирает все данные по записи (включая всех детей на 3 уровня вниз) в JSON чтобы отдать клиенту. Удивляются какого запрос работает больше 5 секунд. Спрашивается накой хер все эти данные собирать и отдавать? Если так, то почему не сделать кэширование? Ответ простой - кэширование не катит, данные нужны актуальные, все что собирается в ответ пусть остается даже если клиенту нужна только 1/100 часть. Но запрос надо оптимизировать. Млять, что там оптимизировать? 1 SQL с кучей JOINs? Это к тому что проблема не в лимитах, она в головах!
Сколько раз приходилось запускать батчи прямо со страницы, на которую зашёл клиент, чтобы глянуть актуальный отчёт? 
Тогда пусть запрашивают только то что нужно, а не каждый раз всё. Иначе скоро и за 50 секунд не получат результат. :D
Не совсем понял вопрос. В смысле за карьеру? Это какой-то вопрос с подвохом?
Я не проектировал ЭТО! А те кто проектировали не хотят признаваться что проблема в изначальной архитектуре :)
Сорян, наверное сильно категорично выразил свою мысль. Конечно JS способ тоже имеет право на жизнь (я тоже использовал). Но меня как перфекциониста немного напрягает что так расточительно расходуются ресурсы. Это мало что надо все данные из базы достать, запаковать, передать на клиент, загрузить клиент расчетами. С батчем как-то оно приятнее звучит, хотя решение немного сложнее в разработке. Зато все данные остаются в базе, просто небольшими пачками достаются, анализируются и убиваются. А если еще для расчетов привлечь саму базу (запросы-агрегаторы) - тогда вообще мы с вами спасем пару деревьев которые пойдут на дрова для выработки электричества 
Вставлю свои пять копеек...
1. Я не удивлюсь если реально производительность просела, любит SFDC помучать разработчиков
2. Под real-time скорее всего подразумевается up-to-date т.е. на текущий момент, плюс часто бывает что хотят ещё и подкручивать какие-нибудь параметры таких репортов, что в случае с батчами крайне затрудняет запланированную обработку и кеширование данных
3. Я лично приверженец того чтобы по-максимуму использовать apex, а по-поводу - в этом и задача выжать по максимуму, на пределах возможности.
4. По-поводу батча - я бы всё же избегал по максимуму их, потому что надо помнить что батчи-то тоже не резиновые и может получится так что с ними вы упрётесь в гораздо менее приятный чем CPU timeout лимит.
Не один я такой, оказывается.
Никаких зменений я не вносил, но раз в день падает триггер
А пэкаджей новых никаких не ставили? Лимит-то сквозной...
Нет. 2 месяца назад был установлен DupeCatcher от Symphonic Source. Но дискотека с лимитом началась около месяца назад.
Когда-то была озвучена идея злого хода конём - немного заранее до какого-то главного релиза в продукт заведомо добавляется "тормозилка", вдруг продукт то тут-то там начинает лагать... А потом с главным релизом эта "тормозилка" опять убирается и с гордостью в release notes добавляется "significant performance improvements". Буду долго ржать если с новым релизом форса эти баги уйдут и мы прочитаем в release notes что-то в этом духе
Это под новый компилятор! Они птм скажут, в 2 раза быстрей! Эмэйзинг!
Из того, что сам проходил. На 100к+ записях батч валился в ЦПУ лимит. Оказалось, все пожирал запрос с "дитями". Т.е. SELECT Id, (SELECT ....) FROM ... хавал весь лимит процессора.
По теме топика - Может данных уже много стало?
Интересный момент:
CPU time is calculated for all executions on the Salesforce application servers occurring in one Apex transaction. CPU time is calculated for the executing Apex code, and for any processes that are called from this code, such as package code and workflows. CPU time is private for a transaction and is isolated from other transactions. Operations that don’t consume application server CPU time aren’t counted toward CPU time. For example, the portion of execution time spent in the database for DML, SOQL, and SOSL isn’t counted, nor is waiting time for Apex callouts.
Может там просто циклы были по всему этому счастью?
1й потребитель cpu limits это вложенные циклы.
Момент конечно интересный, но я убил в свое время пол дня, чтобы найти причину. Как итог в старте всегда пишу очень простые запросы. Остальное выношу в основную обработку.
Нет. Эксперимент был чистый. Т.е. Функционал был убран и правился только запрос.
если проблемы с CPU в первую очередь надо убедиться что не пользуетесь воркфлоу фиелд апдейтами или, упаси боже, процесс билдером. Может какойто админ добавил под шумок field update?
видео на тему, есть и про оптимизацию апекса
кстати вычисление formula fields тоже идет в CPU limit. То есть и простой запрос в базу будет есть CPU лимиты если идет злоупотребление формулами
у нас такое было когда ушлые админы(несколько штук), каждый под себя намутил нное количество воркфлоу + процесбилдеров, которые по сути дублировали работу тригерров....
Огромное спасибо за наводку на видео!
видео здорово помогает искоренить проблему с CPU
я просто был на этой сессии вживую потому и запомнил единственная сессия на дримфорсе где я чтото вынес
