Требуется слишком много времени, чтобы отобразить дисплей продукта с более чем 6000 вариациями
У меня есть продукт с несколькими атрибутами, и у каждого из них есть несколько опций. Общее количество вариаций составляет более 6000. Проблема в том, что рендеринг занимает слишком много времени. Я включил модуль разработки, и вот результаты:
- Выполнил 72 запроса за 323,6 мс.
- Время выполнения страницы составило 13870.81 мс.
- Используемая память: devel_boot()=1,44 МБ, devel_shutdown()=62,56 МБ, пик PHP=69,5 МБ.
Так что я предполагаю, что есть какое-то узкое место в код.
Некоторые замечания о реализации:
- Мне нужна уникальная цена для каждого варианта.
- Я использую ванильную торговлю на Drupal.
Есть ли какой-нибудь способ улучшить производительность?
2 answers
Не нашел подходящего решения для повышения производительности или, по крайней мере, чистого решения. Поэтому я решил создать модуль, который в основном содержит альтернативный форматер представления для "Добавить в корзину", который поставляется с Drupal Commerce.
Вы можете найти модуль здесь: https://www.drupal.org/sandbox/marcofernandes/2705035
В основном это "клон" средства форматирования представления "Добавить в корзину", но он позволяет избежать итераций по всем вариантам и параметрам полей. Это не идеально, но это соответствует моим потребностям (варианты для всех возможных комбинаций). Я сохраню его в качестве песочницы до тех пор, пока он не достигнет более зрелого состояния (в нем отсутствуют некоторые проверки и, возможно, отсутствует некоторый стиль кода).
Получение cachegrind/flamegraph было бы идеальным решением. Скорее всего, там есть какой-то код, который можно оптимизировать.
Есть ли какой-нибудь способ повысить производительность?
Скорее всего, да. Если вы можете обернуть вызов дорогостоящего кода в вызов кэша , это может быть быстрым решением. Если данные меняются довольно регулярно, и вас устраивают данные, которым несколько минут, вы можете использовать кэш функций HTTPRL (httprl_call_user_func_array_cache). Мы используем его для некоторых безумно дорогих вещей, на расчет которых уходит 10 минут (статистика по каждому пользователю нашего сайта). Хорошая вещь в том, что у него есть cache_lifetime_min и cache_lifetime_max; cache_lifetime_min - это время ожидания до создания новых данных, а cache_lifetime_max - это возраст данных, которые вы хотите использовать. Он использует "потоковую передачу", чтобы сделать часть генерации кэша неблокирующей. Пример кода ниже. Первые 2 параметра такие же, как call_user_func_array(), последний параметр является массивом и управляет тем, как работает кэш функций.
// Don't regenerate until data is 2 minutes old.
// Use data up to 1 day old.
// Function is slow give it 1 minute to run.
// Return NULL if there is no cache data. If FALSE and the cached data doesn't exist, the function will block.
// Store cached data in the cache_custom table/bin. This table needs to exist, or choose to not set it and it defaults to the cache bin.
return httprl_call_user_func_array_cache('function_name', array($uid), array(
'cache_lifetime_min' => 120,
'cache_lifetime_max' => 86400,
'lock_timeout' => 60,
'return_null_cache_miss' => TRUE,
'bin' => 'cache_custom',
));