1. Главная
  2. Форумы
  3. Техподдержка Drupal
  4. Решение проблем

Множество полей = Большое число таблиц БД = Долгая загрузка нод

Главные вкладки

Аватар пользователя CSoft CSoft 13 марта 2014 в 5:27

Всем привет!

Имеется магазин на Drupal Commerce. Проблема в том, что у товаров очень много разных особенностей + всякие разные примочки для пометки товаров в акции и так далее. Таким образом, в сумме node product + commerce product у меня имеют 40 дополнительных полей.

Благодаря этому, у нас в БД появилось множество таблиц для каждого поля. И когда я красиво вывожу это всё используя Search API Views, то через Devel вижу примерно 2 тысячи обращений к БД только из функции field_sql_storage_field_storage_load - это она тянет из каждого поля данные, пока они не упадут в кэш. Вот смотрю страничку с товарами в 40 штук - 3.5 тысячи запросов к БД. После обновления страницы - 372 и быстрое отображение.

Кто как справляется в подобных ситуациях? Поделитесь, пожалуйста, опытом! Поля я никак убрать не могу - все нужны. Как вариант: думаю поставить entitycache + commerce_entitycache, чтобы сущности уже полностью были готовы при их загрузке, и класть их в файловый кэш через модуль filecache. Оперативной памяти у меня нет столько, чтобы разместить весь кэш туда, а БД разгружу. И ночью по крону взять и обойти все ноды (сейчас их примерно 7к), прогрузить через node_load, чтобы всё было в кэше и работать с этим. Только, блин, будет круто, если кэш сайта сбросить... Завтра опробую этот метод.

Буду рад любым советам!

Комментарии

Аватар пользователя CSoft CSoft 13 марта 2014 в 15:58

Да, я вчера тоже смотрел на этот модуль, но мне очень не нравится раздел ограничений Sad Да и версия помечена автором, как нестабильная:

7.x-1.0-unstable9

И я ему охотно верю Smile Выходит, что лучший вариант пока что - заранее всё кэшировать? Единственное, как-то придумать, чтобы кэш не очищался для полей и сущностей. А только при их обновлении или удалении.

Аватар пользователя CSoft CSoft 13 марта 2014 в 17:24

Да, его я тоже поставил, но что-то не работает Sad Или я настроил его неправильно, или несовместимость какая-то...

Аватар пользователя CSoft CSoft 13 марта 2014 в 20:28

Хм, что-то с Expire мне не ясно ничего. Вернул кэш в БД. Вроде бы настроил expire. Смотрю ноды - они попадают в кэш. Очищаю кэш - они оттуда уходят. А вот как сделать, чтобы не уходили? А только при обновлении / удалении? Или данный модуль для другого?

Аватар пользователя alextdk alextdk 13 марта 2014 в 21:39

Покупаем сервер потолще, админа потолковее и не паримся Smile ... темболее 40 полей вообще фигня ... ну а если уж решили крутить, xhprof + xdebug вам в помощь, расскажет и подскажет что делать.

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

Кстати какие у вас показатели времени генерации бекенда и фронтенда?

Аватар пользователя CSoft CSoft 13 марта 2014 в 21:47

А зачем мне заниматься профилированием, если я причину проблемы описал в самом первом сообщении?

"lamer" wrote:
Кстати какие у вас показатели времени генерации бекенда и фронтенда?

Гляну ночью и отпишусь.

Аватар пользователя CSoft CSoft 15 марта 2014 в 18:41

"lamer" wrote:
Кстати какие у вас показатели времени генерации бекенда и фронтенда?

Пишу показатели от модуля Devel. Все страницы смотрю, соответственно, под админом.

Главная страница (уже из кэша):

Quote:
Executed 119 queries in 110.23 ms. Page execution time was 1286.69 ms. Memory used at: devel_boot()=1.06 MB, devel_shutdown()=22.86 MB, PHP peak=23.5 MB.

Одна из страниц каталога, 44 товара:

Quote:
[первое открытие] Executed 1537 queries in 1861.06 ms. Page execution time was 11661.27 ms. Memory used at: devel_boot()=1.06 MB, devel_shutdown()=41.6 MB, PHP peak=43.25 MB.

Quote:
[уже в кэше] Executed 139 queries in 152.05 ms. Page execution time was 1984.47 ms. Memory used at: devel_boot()=1.06 MB, devel_shutdown()=31.1 MB, PHP peak=32.75 MB.

Страница журнала в админке:

Quote:
Executed 25 queries in 17.5 ms. Page execution time was 232.78 ms. Memory used at: devel_boot()=1.06 MB, devel_shutdown()=7.92 MB, PHP peak=8 MB.

Страница модулей:

Quote:
Executed 265 queries in 45.73 ms. Page execution time was 2634.07 ms. Memory used at: devel_boot()=1.06 MB, devel_shutdown()=15.07 MB, PHP peak=17.25 MB.

Страница admin/index:

Quote:
Executed 777 queries in 469.92 ms. Page execution time was 7835.91 ms. Memory used at: devel_boot()=1.07 MB, devel_shutdown()=17.68 MB, PHP peak=22.75 MB.

Вот как-то так.

Аватар пользователя alextdk alextdk 15 марта 2014 в 20:42

CSoft wrote:
"lamer" wrote:
Кстати какие у вас показатели времени генерации бекенда и фронтенда?

Quote:
[первое открытие] Executed 1537 queries in 1861.06 ms. Page execution time was 11661.27 ms. Memory used at: devel_boot()=1.06 MB, devel_shutdown()=41.6 MB, PHP peak=43.25 MB.

Quote:
[уже в кэше] Executed 139 queries in 152.05 ms. Page execution time was 1984.47 ms. Memory used at: devel_boot()=1.06 MB, devel_shutdown()=31.1 MB, PHP peak=32.75 MB.

11 сек на генерацию, это конечно круто, ещё наверно html весь стандартный без заголовков кеша статики на стороне сервере, плюс ещё наверно секунд пять ...
Ну что тут скажешь, прототип собрали, молодцы, пришло время заняться программированием! Узкие места знаете, ТЗ имеется, прототип имеется, вперед и с песней Smile

Аватар пользователя sg85 sg85 16 марта 2014 в 5:04

это у вас не со структурой БД проблемы, это либо настройки php - не так давно причиной подобного бедствия оказался open_basedir на хостинге(суть прикола - при любом использовании полного пути к файлу\еще кому происходит некий тормоз, напоминающий обращение к диску(по крайней мере по времени), соответственно, если таких обращений много... например, commerce kickstart сразу после установки тормозил по хуже битрикса после неё же), кроме того кривые настройки акселератора могут при определенных условиях способны вызывать подобные тормоза, либо, как вариант, mysql сервер находится на противоположной стороне земного шара относительно сайта, словом, суть в том, что проблемы с хостингом(вероятность примерно 90%).