Задавайте вопросы про Drupal - 2

по существу ::: все эти функции корзины летают на шареде за три бакса

Видимо у нас с вами разные понятия слова «летают»

Видимо у нас с вами разные варианты конструкций... ))

Ставите Devel, смотрите запросы к базе данных для каждой страницы и выясняете что именно даёт нагрузку. После этого пытаетесь понять как оптимизировать нагрузку. Ряд запросов можно убрать путём установки дополнительных модулей кэширования. Некоторые запросы можно убрать какими-то простыми действиями (загрузка более новой версии перевода и т.д.).

---------- Добавлено 31.07.2013 в 20:39 ----------

Всё зависит от того, что у вас на сервере стоит. Например, если Memcache установлен, то можно просто установить модуль Memcache API and Integration (https://drupal.org/project/memcache), что может существенно снизить нагрузку.

Я не знаю как делается корзина с использованием Views, но мне кажется, что кэширование будет вызывать глюки. Хотя, лучше протестировать.

---------- Добавлено 31.07.2013 в 20:43 ----------

Может Boost? Каким именно действиям пользователей он может помешать? Я использую Boost на сайте интернет-магазина (Ubercart).

Насчет Devel спасибо, я уже занимаюсь анализом SQL-запросов.

«дополнительных модулей кэширования» - вот тут хотелось бы поподробнее. Какие из них реально помогают, а какие глючная поделка?

Кстати да, спасибо. Попробуем memcache поставить и настроить. Думаю будет чуток быстрее.

Да, точно Boost =)

Ну вот та же корзина к примеру. Например сгенерилась страница каталога и закешировалась полностью. Пользователь закинул товар в корзину, но кол-во товаров отображается прежним т.к. страница снова отдалась из кеша. Я про такого плана возможные косяки.

Всё зависит от вашего сайта. Я использую Block Cache Alter (https://drupal.org/project/blockcache_alter) и Entity cache (https://drupal.org/project/entitycache). Плюс настройка кэширования блоков в Views. Вам могут помочь и другие модули, но сказать какие именно не могу, так как это зависит от конфигурации и функционала сайта.

Я для корзины использую Ajax Blocks (https://drupal.org/project/ajaxblocks). Он подгружает блок с корзиной через Ajax. Вся остальная страница остаётся закэшированной через Boost. Правда, мне пришлось ядро Drupal пропатчить, так как он не даёт создавать кэш страницы, если сессия содержит какие-то данные.

Ясно теперь.. Фантазировал, как Boost будет интернет-магазин ускорять, для уверенности на страничку заглянул в схемку - мало ли, вдруг изменилось чего...

Тем более, с исходными данными:

* понимаю, что для ботов всяких он поможет, освободит часть ресурсов "активным" пользователям. Но пересчёт...

forest25, а полей много? Может там во вьюшке чего творится?

и да.. тип таблиц какой? Если про мемкэш речь шла - видимо, VPS/дедик.. может там настройки БД "специфичные"?

p.s. читал, что "не в счёт", но тем не менее..

Просто в моём понимании, это своего рода баг системы. Наличие сессии не значит, что пользователь залогинен. Информация о товарах в корзине хранится и для анонимных пользователей. Могут ещё многие вещи хранится в сессии. Поэтому я и удалил условия в ядре, которое проверяет наличие сессии. Это обсуждалось уже на drupal.org. Я так и не понял, что они там решили.

не, это особенность кэширования "страницы целиком".

Для магазинов (да и вообще, для многих сайтов, где предусмотрена активность пользователя чуть больше чем "просто почитать") более актуально блочное кэширование.

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

Интересно было бы на списочек запросов глянуть...

furamag, ivan-lev - спасибо за ответы. Много полезного для себя почерпнул.

Вообще с тормозами если честно я погорячился чуток - работает оно более менее сносно, но есть один неприятный момент. В корзине реализованы кнопки для добавления и удаления товаров (+ и -). Так вот при каждом клике отправляетя ajax-запрос. В итоге получается не совсем быстро и удобно т.к. при каждом прибавлении пользователь должен ждать доли секунды которые тем не менее создают эффект подтормаживания корзины.

Вообще друпал мне изначально не нравится своей перегруженностью (это понятно ибо универсальное решение не может быть быстрее специализированного) и избыточным кол-вом запросов к БД.

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

Увеличил немного кеш в MySQL (InnoDB) - стало чуток быстрее работать. Если что варианты по оптимизации пока такие:

1) Индексы в БД, memcache

2) Nginx + PHP-FPM

3) Накатывание Pressflow сверху (кстати как оно с Drupal Commerce работает?)

4) Модули кеширования

5) PHP 5.5 с Zend OpCache =) или запуск в HHVM