Возник вопрос по оптимизации.
Лично у меня пока не получается добиться удовлетворяющих меня результатов без использования Varnish.
Я использую VPS (RAM 2Gb, 4 CPU, SSD). PHP 7.0.0 (который вышел 2 дня назад). Mysql 5.5. Nginx 1.8.
Понимаю, что многое зависит от шаблона и самих товаров, тем не менее. Для страницы каталога, которая выводит 24 настраиваемых товара время ответа сервера составляет 400-550 ms (для php5.5 время было 1-1.2 sec). Для страницы с 24 простыми товарами время составляет 250-350 ms .
Хочется узнать, что вы используете для ускорения работы Magento и реально ли добиться ответа сервера за <200ms "за час" поверхностной оптимизации или даже применив больше времени на тюнинг? Возможно я что-то упускаю из виду.
Что же Вам мешает использовать Varnish?
Самый простой способ немного ускорить это http://www.magentocommerce.com/magento-connect/lesti-fpc-simple-fullpagecache.html
Дальше memchached.
Redis говорят еще шустрее, но сам не пробовал пока.
А вообще хостинг был проверен на возможность отдавать быстрее?
Вы не описали что уже сделали для ускорения.
у меня тоже подтормаживает. хотя из основных рекомендаций: включить кэш, соединить джава скрипт и стили, включить компиляцию. Это немного ускорило, не не значительно. Вот рассматривал вариант покупки модуля fullpagecash. их очень много разных и по разным ценам.
Вы сейчас сбросили тоже такой же модуль, он реально ускоряет? И почему такой разброс цен на эти модули.))
Varnish не пробовал, это на стороне сервера настраивается? не будет ли оно конфликтовать с модулями fullpagecash?
почитал отзывы, пишут что Varnish и fullpagecash нет смысла, это одно и то же. И если есть возможность то рекомендуют все-таки Varnish. Это все нашел в комментариях этому модулю
Помимо, включения настроек в админке Magento для ускорения советую использовать компрессоры js, css которые к тому-же опускают скрипты в конец html документа. Ссылку дать не могу так как при беглом осмотре коннекта не вспомнил какой именно модуль устанавливал, кому понадобится есть скаченный, который можно легко установить через управление расширениями могу отправить Почтой России по электронной почте.
Включить gzip сжатие
Используйте кэш браузера
Lesti_FPC отлично работает с memcached, APC, Redis, о чем указано в документации в блоге разработчика https://gordonlesti.com/projects/lestifpc/
С одним Lesti_FPC ответ сервера будет в среднем 0,2с
Вместе с memcached 0,1с
Если PHP ниже 5,5 вместе с memcached можно прикрутить APC, в более поздних версиях PHP ее заменили на APCu я не стал заморачиваться так как время загрузки страницы укладывается в одну секунду, всех все устраивает.
Кстати совсем забыл упомянуть самую главную вещь! Первое с чего нужно начать это выяснить возможности хостинга. С болью вспоминаю как на reg ru больше полугода мучился заставляя opencart грузится быстрее полутора секунд, переехав на beget, даже ничего и не делал, стало 0,75. Кстати в России от стоимости хостинга не всегда зависит его качество.
PhizikPRO
Что же Вам мешает использовать Varnish?
Странный момент, при включении Varnish резко увеличилось время на страницах корзины и оформления заказа. Еще мне нужна была статистика посещений на сервере, поэтому временно я отказался от него. Возможно еще вернусь к этой теме.
Lesti FPC
Пробовал уже давно его, сразу почему то не заработало. Возможно стоит тоже еще раз на него посмотреть.
memchached
Тоже пробовал, но не увидел никакой разницы что с ним, что без него. При этом он даже работал, и при некоторых изменениях на фронте приходилось перегружать memcached, чтобы их (изменения) стало видно. Но почему то на скорости загрузки страницы это никак не отразилось. Поделитесь вашим конфигом с memcached чтобы сравнить?
Redis
Его я тоже еще не пробовал настраивать.
Включить gzip сжатие
Включено, но на время ответа сервера оно не влияет. А только на скорость с которой клиент получит данные (html, css, js).
Используйте кэш браузера
Нужно что-то специально для этого делать? И ведь это не влияет на время ответа страниц, на которых пользователь еще не был.
Varnish и FPC
Это разные вещи. Хотя цель у них одинаковая.
APC
APC заменен на opcache начиная с php 5.5 и который по умолчанию включен.
APCu и APC разные вещи. Первый это просто пользовательский кэш, а второй кэширует байт-код php.
хостинг был проверен на возможность отдавать быстрее? Первое с чего нужно начать это выяснить возможности хостинга.
Это какие такие возможности?
ps. В данный момент включена компиляция php классов, включен кеш, стоит php7 с включенным opcache, включен gzip, объединение и минимизация css и js. И понятно, что с FPC или с varnish можно добиться менее чем 200ms, но это влечет за собой дополнительные ограничения. Мне пока интересно возможно ли добиться приемлимых результатов без FPC или reverse proxy. Получается только memcached или redis. С первым я почему то не увидел увеличения скорости.
При установке memcached на сервере не конфигурировал ничего если память не изменяет, вносил изменения в Magento, он у меня работает вместе с Lesti_FPC
Как указано в документации к Lesti:
You can set every other cache backend like apc, memcached or redis in app/etc/fpc.xml. In the same style you did it in app/etc/local.xml.
Просто добавил файл fpc.xml с таким содержанием:
<?xml version="1.0"?>
<!--
/**
* Lesti_Fpc (http:gordonlesti.com/lestifpc)
*
* PHP version 5
*
* @link https://github.com/GordonLesti/Lesti_Fpc
* @package Lesti_Fpc
* @author Gordon Lesti <info@gordonlesti.com>
* @copyright Copyright (c) 2013-2014 Gordon Lesti (http://gordonlesti.com)
* @license http://opensource.org/licenses/OSL-3.0 Open Software License (OSL 3.0)
*/
-->
<config>
<global>
<fpc>
<lifetime>86400</lifetime>
</fpc>
<memcached>
<servers>
<server>
<host><![CDATA[127.0.0.1]]></host>
<port><![CDATA[11211]]></port>
<persistent><![CDATA[0]]></persistent>
<weight><![CDATA[2]]></weight>
<timeout><![CDATA[10]]></timeout>
<retry_interval><![CDATA[10]]></retry_interval>
<status><![CDATA[]]></status>
</server>
</servers>
<compression><![CDATA[0]]></compression>
<cache_dir><![CDATA[]]></cache_dir>
<hashed_directory_level><![CDATA[]]></hashed_directory_level>
<hashed_directory_umask><![CDATA[]]></hashed_directory_umask>
<file_name_prefix><![CDATA[]]></file_name_prefix>
</memcached>
</global>
</config>
Кэш у меня очищается как и нужно из админки, memcached передергивать не нужно.
Про gzip и кэш Вы все правильно говорите, но это нужно сделать обязательно так как клиент как правило сначала мельком просматривает товары, а позже возвращается обратно и от этого зависит общее впечатление о пользовании сайтом.
>>APCu и APC разные вещи
Спасибо за пояснения, я не вникал если честно. Увидел в phpinfo APC Emulated залез в сеть посмотреть, там говорят все нет больше APC и забил я на это.
>>Это какие такие возможности?
Это не Вам. Вы же понимаете что тему будут просматривать те кто только начинает. Вот я к примеру начинал с хостинга который мне отдавал простой HTML с "hello world" больше секунды.
Вчера заинтересовавшись вопросом с до скольких разгоняют сайты на Magento нарвался вот на такой тест:
MAGENTO 1.9.1.0 - ВРЕМЯ ЗАГРУЗКИ СТРАНИЦЫ НИЖЕ 0.3С?!
Глядя как нахвалили фейсбуковский HHVM решил попробовать...
Установка и настройка очень простая, и занимает от силы 5 минут (Скажу честно что у меня первый раз все получилось не за пять минут)
Устанавливал на сервер с Ubuntu 14.04 и Apache 2.4
Устанавливаем сам HHVM Официальный гит
sudo apt-get install software-properties-common sudo apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0x5a16e7281be7a449 sudo add-apt-repository "deb http://dl.hhvm.com/ubuntu $(lsb_release -sc) main" sudo apt-get update sudo apt-get install hhvm
Apache и HHVM связывается между собой с помощью FastCGI, ставим его
sudo /usr/share/hhvm/install_fastcgi.sh
Добавляем в автозапуск
sudo update-rc.d hhvm defaults
Все установлено осталось только настроить. Если вы не желаете чтоб все сайты обрабатывал HHVM, а делать это выборочно нужно закомментировать строку в файле hhvm_proxy_fcgi.conf
sudo nano /etc/apache2/mods-available/hhvm_proxy_fcgi.conf
# ProxyPassMatch ^/(.+\.(hh|php)(/.*)?)$ fcgi://127.0.0.1:9000/var/www/$1
А в апачевском файле нашего сайта добавляем строку с ProxyPassMatch...
sudo nano /etc/apache2/sites-available/мой-сайт.ру.conf
<VirtualHost *:80> ServerName мой-сайт.ру DirectoryIndex index.php DocumentRoot /var/www/мой-сайт.ру/public_html ProxyPassMatch ^/(.+\.(hh|php)(/.*)?)$ fcgi://127.0.0.1:9000/var/www/мой-сайт.ру/public_html/$1 </VirtualHost>
Сохраняем, перезапускаем
sudo service apache2 restart sudo service hhvm restart
В первый раз может потребоваться ручной запуск демона
hhvm --mode daemon -vServer.Type=fastcgi -vServer.Port=9000
Делаем в папке с нашим сайтом тестовый файл test.php
<?php echo defined('HHVM_VERSION')?'Using HHVM':'Not using HHVM';
Переходим в браузере по адресу мой-сайт.ру/test.php если видим на экране Using HHVM значит все отлично, работает!
Перехожу на свой сайт чтоб проверить скорость, потыкал по ссылка, вроде субъективно пошустрее стало, а может из за того что глубокая ночь была и пользователей не было совсем. Тут как назло ежедневный бэкап стартовал. Дождался завершения, захожу в админку для того что бы сначала очистить кэш, а потом сделать замеры. И тут на-те-блин, при переходе в любой пункт меню вылетает сообщение "Установите IonCube"!!! У меня стоит одно закубленное приложение, лезу в интернет узнать что за дела и выясняю что HHVM не работает с IonCube.
ОЧЕНЬ БЫЛО ОБИДНО(((
У кого нет приложений с IonCube протестируйте скорость работы, очень уж интересно...
Инфу по установке брал отсюда:
http://blakepetersen.io/how-to-set-up-and-configure-hhvm-on-ubuntu-14-04/
1. Судя по статье ставить redis смысла нет. И было бы интересно как они varnish 4 прикрутили. Те расширения которые я находил работали только с третьим варнишем (о чем они сами пишут)
2. Смысл тестировать на продакшене? Разверните отдельный инстанс, с голой magento 1.9 с тестовыми данными и проверьте под разные конфигурации. И можно использовать ab или siege, чтобы уж наверняка.
3. Я для себя решил поставить php 7 вместо hhvm, хотя последний вроде пишут быстрей чем php7 пока что (хотя и незначительно). Разница в скорости php 5.5 vs php 7 примерно в два раза.