Но дело тут не только в кеше, кеши я уже отключал для этой сущности - скорости прибавило, но не сильно, видимо на другие обработки и проверки тратится много ресурсов перед тем как "просто записать 3 значения в базу".

А если это в транзакции обернуть - то становится лучше? У меня вроде поживей с ними стало прям.

Не, я всё создавал канонично по апи через Node::create() и $node->save(). Там вроде фиг сделаешь транзакции. А на прямые запросы там если переписать, то непонятно, как это сопровождать потом - там сущности с параграфами, энтити референсами, картинками и т.д.

Так, стопэ, там же внутри сучностей уже есть транзакции, емнип, что тогда внешнее оборачивание даст?

Оно должно вроде как обернуть запись всех 100 сущностей в одну большую транзакцию. В результате базе будет попроще писануть сразу 100 значений в базу, чем по очереди каждое писать. И кеш (надеюсь) тоже прочищаться будет только 1 раз, а не 100 раз подряд.

А ты создаёшь или обновляешь? Мне кажется, создание нескольких сущностей в одну транзакцию не получится, потому что там автоинкрементные поля

сучностей - это ты отлично сказал ;))

и то и другое, но в основном - обновление идёт ежедневное (прайслист от курса шекеля зависит и цены скачут). Авто-инкремент в транзакции точно так же сработает, как без неё, так что норм должно быть. Т.е. прям весь цикл с кучей node-create-save попробуй обернуть в транзакцию, и сравни. Единственное, что может случится - что в двух параллельных процессах авто-инкременты будут не вперемешку идти (как сейчас), а по-очереди группами, т.к. сначала выполнится одна транзакция и займёт 100 автоинкрементов, а уже после её завершения - вторая.

господи, зачем такие сложности? Не проще ли сразу задавать цены в нормальной валюте, а на морде прайс ресолвить через икченджь рейт?

это уже тут обсуждали, у менеджеров своя логика ценообразования, не поддающаяся арифметическим формулам ;)

А почему бы тогда не сделать батч?

дык это батч и есть, по 100 штук. Если там мильён позиций в прайсе, то по одной штуке записывать - сайт неделю будет пыхтеть

Аааа, я думал, у тебя их всего 100 штук)))

и прям цены на весь миллион товаров изменяются как-то нелинейно?
Если речь об апдейте одного филда, то зачем всю сущность дёргать?

А можно как-то обновить одно поле, не дёргая всю сущность? Там в сущности 3 базовых поля, в одной таблице лежащих - id, name, price.

наверное только через запрос к базе.

Но вообще - очень часто приходится и в более тяжёлых сущностях с кучей полей делать полный $entity->save() ради того, чтобы обновить значение только у одного поля. Более легковесный вариант это вроде только напрямую писать значение поля в базу, а потом вручную затронутые кеши чистить. Но в таком варианте надо чётко знать что делаешь, т.к. не будут выполняться никакие хуки и другие функции, слушающие событие изменения сущности.

Мне кажется, по этому легковесному варианту в итоге то на то выйдет

Кстати, при работе с кучей сущностей в циклах - ещё полезно прочищать статик-кеш сущностей Друпала через $entityTypeStorage->resetCache(); после каждых 50-100 операций, а то мемори оверфлоу словить можно. И докучи - gc_collect_cycles(); энфорсить чтоб уж наверняка ;)

А это и так при сохранении делается и даже бакенд специальный в ядро завезли, но он вроде только при обновлении/установке ядра используется