forest25

forest25
Рейтинг
67
Регистрация
12.09.2009
Должность
Colary
ivan-lev:
Плюсики неплохо сочетаются с кнопкой пересчитать ;)
Но в целом - Вам виднее.

А насчёт "костылей" - достаточно только этого:

Я бы и рад так сделать но там ajax-запрос возвращает ответ в виде готового html который перезаписывает существующее поле. Видимо такой стандартный функционал у Views. Был бы очень рад если бы запрос просто возвращался без автоматического перезаписывания полей.

ivan-lev:
Эм.. реализовать без отправки ajax-запроса и с кнопкой "Пересчитать"
Я бы ещё "буферами поигрался".

Как наберётся после последних изменений - статистику посмотреть. Можно скриптом вроде tuning_primer - он прямым текстом намекнёт что расширить и где углУбить.


А сейчас апач бэкендом? Или он же и картинки отдаёт? ИМХО, без тонкого тюнинга, победитель в битве mod_php vs php-fpm на 100% не определён. А тут отдельный скилл требуется. Лучше в сторону опкэшеров посмотреть (если не установлены ещё) APC\Xcache\ZO Plus

Исторически на сервере уже стоит Apache т.к. там еще есть mod_passenger =) Он обслуживает только mod_php, вся статика уже давно на nginx с необходимыми настройками по времени кеширования.

По tuning_primer спасибо, посмотрю. Обычно пользовался MySQL-tuner.

Сейчас стоит Xcache, но можно попробовать замерить с APC.

Насчет кнопки «Пересчитать» я бы возможно так и сделал, но тут уже утвержденный дизайн и заказчики. Нужны именно плюсики =)

Как вариант можно извратиться и сделать так:

1) Вывод views сделать display:none

2) На js вытащить оттуда данные по кол-ву товаров и сгенерить представление

3) При клике все мнгновенно пересчитывается и отображается и затем отправляется ajax-запрос

4) Который при возврате соответственно переписывает только ту часть которая у нас display:none

5) Прислушиваемся к ответу ajax-запроса только в случае если он завершился ошибкой

Но если честно не хочу городить такие костыли )

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

offtop

Кстати насчет Битрикса - по работе ежедневно сталкиваюсь с различными редакциями «Управления сайтом». Не стоит эту CMS выставлять как неповоротливого монстра. Да в стандартной поставке оно тянет кучу архаичного кода для совместимости, но если его пнуть как надо то вполне себе бегает.

Ставил разные редакции как на хостинг за 2 бакса в месяц там и на дедиках. В основном причина тормозов - кривые руки интеграторов.

Встречал такие интересные конструкции которые для получения 3 рандомны элементов делают выборку из 12к элементов сложным запросом с кучей Join'ов и прочие интересности.

Ни для кого не секрет что «птички» там несут скорее субъективную информацию.

Поверю ТС только после того как он будет проводить всесторонние объективные тесты и замеры:

1) несколькими бенчмарками на PHP (включая тест Битрикс)

2) сервера БД

3) дисковой подсистемы

И не будет мешать в кучу VPS на различных типах виртуализации, дедики и шаред-хостинги.

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

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

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

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


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

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


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

Да, точно Boost =)

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

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

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

Pavel_:
Вы что-то не то наконструировали стопудово. Хорошо и быстро это работает Точка

Делал не я. Сайт мне уже достался таким. У меня другое мнение насчет скорости его работы.

Есть что сказать по существу? В плане действий по оптимизации.

Pavel_:
Как вы представляете себе кэширование корзины? Зачем? ... ))

Возникла бредовая идея ::: сменить DOCTYPE только у одного типа материала. Как бэ если можно page--мая_материала.tpl.php, то теоретически и html--мая_материала.tpl.php должно работать... дык не хочет...

долго мучил-мучил template.php - не хотит почему-то

Просто этот Drupal Commerce на весьма неслабом сервере даже при простом пересчете количества товаров как будто запускает расчет траектории полета космической ракеты на Марс.

Хотел попробовать Booster, но не знаю как он себя поведет на интернет-магазине где нужен интерактив от пользователей.

Ребят, подскажите плиз варианты по оптимизации скорости Drupal Commerce?

Настройка серверного ПО не в счет, интересуют именно варианты справильной настройкой кэширования, установкой доп. модулей и т.д.

Алсо, корзина сделана на views. Можно ли там включать кэширование или будут глюки у покупателей с товарами?

У вас в трех файлах хотя бы количество строк одинаковое? Строки идут по порядку по Id?

Всего: 372