Опубликовано Оставить комментарий

Создание сайта автозапчастей на платформе YUPE часть 1

Пару недель назад поступила ко мне заявка из региона на создание сайта автозапчастей для иномарок, точнее для одной конкретной модели. Так как тема запчастей мне близка, плюс я давно хотел сделать узконаправленный интернет магазин запчастей для какой нибудь марки автомобиля и применить полученные мной за последнее время знания в области SEO, я согласился.

Как показывает мой опыт работы с ИМ запчастей , есть два пути по которым идет развитие таких интернет магазинов.

  1. Мультибренд — когда магазин занимается запчастями ко всем автомобилям
  2. Узкая специализация — когда магазин занимается исключительно одной маркой автомобиля или одной моделью, или даже один брендом.

У обоих вариантов есть и плюсы и минусы, но не стоит их рассматривать как истину в последней инстанции. Итак :

Плюсы первого варианта.

Широкий ассортимент автозапчастей потенциально должен привлечь более широкую аудиторию, а значит большее количество заказов.

Минусы первого варианта.

Большое количество марок, а соответственно и огромный массив запчастей создает проблемы для качественного наполнения и продвижения магазина.

Плюсы второго варианта.

Узкий ассортимент товара, позволяет добиться более глубокого знания о марке/модели автомобиля, всех его деталей, узлов и болячек , что несомненно отражается на качестве преподносимой информации и существенно повышает доверие со стороны покупателя.

Минусы второго варианта.

Потенциально более меньшая аудитория, а  значит и посещаемость ИМ, что влияет на количество заказов, а значит и показатели выручки и прибыли магазина.

 

Почему то развитие 80-90 % всех интернет магазинов запасных частей идет по первому пути. Отчасти этому способствовала слава крупнейшего ИМ запчастей в рунете Exist.ru , отчасти общее состояние этой отрасли, но только несколько игроков сумели составить конкуренцию этому монстру и войти когорту лидеров.

Тем не менее 10-20% интернет магазинов заняли свои узкие ниши и неплохо себя чувствуют.

Именно этот тип магазина я и хочу создать.

Итак  с типом магазина я определился. Создание сайта автозапчастей потребует выбрать платформу или CMS, когда речь идет об узкой нише, то редко количество товаров превышает 1000-10000 SKU, а значит принципиально можно выбирать любую платформу или CMS из топ-10, дело только в удобстве использования, оформлении и всяких фишках/наворотах. Но для начала пробежимся по имеющимся вариантам уже заточенным под торговлю автозапчастями.

Проанализировав различные варианты я остановился на CMS Yupe , почему именно эта платформа , а не WordPress или Битрикс ? Все просто, yupe из коробки имеет множество модулей, она написана на любимом мной фреймворке  YII, да и просто захотелось пройти весь цикл создания ИМ на этой платформе для более глубокого ее изучения.

Продолжение следует…..

Опубликовано Оставить комментарий

Часть вторая «сайт тормозит» или кэш в YII1

Как использовать кэш в YII1 .

Итак в первой части я рассказывал о борьбе с медленным сайтом клиента и использовании программы XDEBUG. Сайт клиента до начала работы выдавал умопомрачительные 6-7секунд времени до загрузки первого байта и с помощью XDEBUG удалось найти и локализовать проблему. Время отдачи первого байта упало до приемлимых на мой  взгляд 800-900мс, но клиенту этого показалось мало и он решил вывести время  ответа сайта по основным своим страницам каталога в район 200-300мс, а значит можно попробовать использовать кэш в YII1 .

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

Контроллер YII1
Типичный контроллер YII1

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

 

 

Кэш в YII1

Изучив нужные мне view-шки на предмет кода решаю внедрить примерно одинаковые конструкции отличющиеся только разными зависимостями и названиями ИД кэшей.

if($this->beginCache('car'.$model->id.'type'.$type.'page'.$page, array('duration'=>60*60*24*365,'dependency'=>array(
'class'=>'system.caching.dependencies.CDbCacheDependency',
'sql'=>'SELECT update_at FROM katalog_vavto_items WHERE cathegory_id=:cathegory_id order by update_at desc limit 1',
'params'=>array(':cathegory_id'=>$model->id),
)))) {
// здесь какой то контент который нужно закэшировать
$this->endCache(); }

Если вкратце, то кэшируем разные страницы модели и ее типов  на год ( ‘duration’=>60*60*24*365), а вторым условием использования кэша делаем проверку на изменение или добавление какой либо карточки принадлежащей модели (атрибут update_at который изменится если вдруг в какую то карточку внесут изменения или добавят новую ).

Проворачиваем такой фокус со всеми нужными страницами каталога, смотрим, что страницы пагинации тоже правильно кэшируются и отображаются. Делаем контрольные замеры и получаем время ответа сервера 250-300мс.

Бинго !
 

Опубликовано Оставить комментарий

Как я искал проблему «сайт тормозит» !

XDEBUG result

Поступила мне тут на днях следующая задача, помочь решить проблему «сайт тормозит».

Краткое предисловие было в том, что время открытия заглавной страницы сайта составляло порядка 6-8 секунд , по словам клиента » сайт тормозит» ! При всем этом, ничего такого особенного и тяжеловесного на сайте нету. Задача интересная и не совсем обычная для меня и я решил взяться.

Сайт написан на  YII который славится своей быстротой. Первичное исследование железа на котором установлен сайт показало VPS со следующими параметрами : 8 ядерный процессор, 32Гб ОЗУ, SSD диск . Причина скорее всего не в железе. Сайт работает под управлением PHP56 и NGINX в качестве СУБД выступает MYSQL 5.5. На всякий пожарный смотрим настройки mysql (а то тут был у меня один случай 🙂 , все в порядке база на innoDB. Все размеры буферов и кэшей соответствуют размерам БД, да и обычный show processlist  ни дает ничего криминального, как иногда это бывает.

Вывод chrome

Запускаем chrome посмотреть выдачу , показатель TTFB то есть время через которое браузер получил первый байт составляет 6.23 сек ! Причем повторные загрузки не изменили картины. При всем этом размер страницы всего 65Кб.

 

Проблема «сайт тормозит» явно в коде сайта !

 

 

Как спрофилировать код PHP ?

Проблема локализована, но не понятно, что именно так тормозит. Для того, чтобы это понять, я устанавливаю и запускаю XDEBUG. Включаем срабатывание xdebug по триггеру  и настраиваем директорию куда он будет писать свой файл. Запускаем обновление главной страницы с параметром ?XDEBUG_PROFILE и любуемся файлом в 97MB )))

Для быстрого анализа файла выдачи Xdebug  есть офигенский инструмент webgrind. Устанавливаем его с GITHUB репозитория и скармливаем ему наш 97Мб файлик. Убираем функции PHP и сортируем по Total Self Cost для начала. Это самый затратный процесс.

На первом месте вызов KatalogVavtoModule->generateItemsPathsMap. Самое частое кто его вызывает этоKatalogAvtoUrlRule->createUrl. Заглядываем внутрь, а там 1,5 млн. выполнений операции array_key_exists !!! Ныряем в код и проводим небольшое расследование. Итого: модуль KatalogAvtoUrlRule->createUrl переопределяет собственные методы CBaseUrlRule createUrl и parseUrl , для формирования ссылок на товары и категории товаров, в которых идет обращение к модулю KatalogVavtoModule и методу generateItemsPathsMap. Идем дальше в этот метод и видим следующую картину. Каждый раз при формировании ссылок выполняется поиск и выборка из БД  более чем 11 тыс. строк, обработка и формирование карты ссылок которая затем скармливается createUrl и уже по этой карте формируется нужная ссылка.

На главной странице примерно 132 ссылки на различные категории и товары, 132 х 11 тысяч строк БД + операции проверки и формирования нужных ссылок. Вот то, что тормозило сайт ! Так как товары практически не меняются^ посещаемость сайта не велика и дабы не углубляться в дебри бизнес-логики, включаю кэширование и дописываю код. Теперь карта ссылок будет хранится в CFileCache и при всевозможных изменениях в категориях или товарах. Заново перестраиваться. Сказано сделано.

Стало 893ms !!!  Победа !!!

 

 

Пишите в коментариях как Вы справлялись с похожими проблемами.