27 ноября 2015 в 20:14
Дело такого рода что первый раз стартовая страница загружается около 5-7 секунд, стоит друпал + коммерц + сопутствующие модули, сайт пока не загружен контентом - подскажите что проверять или чем)) кэш пока только стандартный: страницы карточек товара нормально грузятся после создания кэша, но вот с стартовой страницей надо что-то делать.. буду благодарен за любую помощь!
Комментарии
этот вопрос меня тоже очень заботит. ускорению д7 посвящены несколько постов на тлито.ру, пока что с коммерцем я так и не разобрался потому что на впс не хочу его держать так как еще не умею настраивать мемкеш, а на джино как-то медленно бд работает, хотя на бегете вообще не работало
я вам могу советовать:
1. включите authcache + filecache - это работает на шаред хостингах
2. не пользуйтесь таксономи меню и представляенияи в блоках тоже не пользуйтесь
3. переезжайте на друпалхостинг или рувеб.нет, или на свою впс и включайте мемкеш и entity cache
на данный момент я думаю что д7 коммерц трудно ускорить новичку, так что пробуйте другие системы, например joomla магазины, вп екоммерц, ruby solidus https://github.com/solidusio/solidus и другие движки, даже платный вебасист или пхпшоп. мне кажется что их использование будет вызывать меньше проблем связанных с тормозами. но первое что вы должны сделать - выбрать другого хостера. поделитесь опытом, если исследуете
Tlito, к чему все это? Если не умеешь готовить то может быть стоит отстать от друпала?
Вообще то он прав по некоторым пунктам:
- не делать таксономия меню ( реально тормозной вариант если без кеширования результата)
- не выносить представления виевс в блоки ( или включать кеширование для них отдельно)
- осторожно выбирать хостинг ( очень дешевые часто перегружены по бд)
- включить filecache ( реально помогает когда в кеш базы слишком много гигабайт данных падает и база тупо не тянет)
Имхо это ответ вполне .
@gor, можно пару вопросов:
1 - из опыта. чаще всего проблему видел на сайтах, где на 1 страницу было 5-10 блоков из views представлений собранных по рекомендациям из поисковика. Без включенного кеширования представления. Итог обычно печальный - при достаточно малой посещаемости, дикая нагрузка базы по трафику (мегабайты данных в секунду). Теоретически это могут быть видимо и панели, но пока не попадалось, не могу судить.
2 - https://www.drupal.org/project/filecache или https://www.drupal.org/project/cacherouter - В случае если на сайте много таких вот блоков, встроенное в views кеширование не помогает. Так как в результате тянуться мегабайты генерированного вывода из кеш таблицы. Спасает очень. Так как прочитать файл с диска стоит дешевле чем вытянуть из базы. На примере DH Elastic тарифа, включение этих модулей позволяло снизить стоимость хостинга на порядок для клиента.
Ну, по первому пункту речь, получается, именно о наличии множества дисплеев на одной странице, а не о блоках views как таковых?
По панелям да, у меня есть сайт, где в форме из селект-листа выбираются пункты, и по каждому пункту показывается свой views pane (по сущности являясь отдельным дисплеем), меняя класс display - с none на block. Так вот, на странице получается постоянно грузятся около 10 views panes - ситуация с нагрузкой аналогичная описанной Вами. Хотя таки неплхая система кеширования самих панелей спасает.
По второму пункту понял, спасибо! А к старому-доброму бусту как варианту как Вы относитесь?
Boost н же во всех случаях спасает. Он кеширует для анонимов и целиком. Соответственно он полезен когда трафик анонимный ( не авторизируется) и попавшие в буст страницы окрашиваются больше чем 1 раз за время до истечения срока Кеша.
Особенно плохо бывает когда материалов 10000 , а в итоге их боты только парсят раз в день.
И время жизни 5 минут.
Вообщем с умом использовать надо и в ситуациях где он нужен.
Ну это понятно, да. Спасибо!
Я думаю, в моём случае - в контентных проектах со статикой, нацеленных на трафик анонимов, как раз буст будет полезен.
ТС вначале напишите где находится сайт, т е больше подробностей
если сайт на шареде или локалке то шустро он бегать вряд ли будет.
посмотри в консоли разработчика в браузере во вкладке сеть, что дольше всего грузится.
F12 потом network
Еще вариант - включите devel модуль с xhprof. Он позволит начать понимать где именно тормоза.
Поэтому я вначале и предложил описать где находится сайт, потом смотреть кеширование и также запросы чтобы понять где именно тормоза. Еще непонятно есть ли у ТС таксономи меню. Также могут подвешивать сайт виджеты при попытке подключиться к удаленному сайту и сторонние библиотеки.
Добрый день, извиняюсь что пропал.. спасибо кто отвечал!
1. сайт находится на украинском хостере https://www.ukraine.com.ua/ на тарифе Лучший SSD - не самый дешевый хостинг, и по характеристикам не плохой, на мой взгляд.. что вы скажете по поводу хостера?
2. чаще всего при первой загрузке долго грузится файл www.camozzi,in.ua - по-этому не знаю что именно менять
3. сегодня из 5 секунд 4 загружался слайд - выключил его на данный момент, стоял Views Slideshow: Cycle - подскажите плз какой лучше слайдер использовать?
4. таксономи меню не используется - меню построено вручную)
5. кеш конечно будет включен, но на данный момент сайт пустой - он же должен грузится быстро? из-за этого я и грешу на свою "сборку"
6. вьюха в блоке - есть альтернативный способ отображать принадлежности к товару?
p.s. надеюсь ни у кого нет предвзятости что я с Украины..
3. Статика грузится довольно вяло, так что вероятно, с хостингом всё не очень хорошо, и это может быть одной из проблем, и даже основной проблемой. Скорость загрузки картинки в слайдере зависит не от слайдера, а от хостинга.
5. Devel и xhprof, или хотя бы просто devel, могли бы прояснить ситуацию с тем, на что тратится время при генерации страницы. Иначе это просто гадание на кофейной гуще будет. По поводу пустого сайта - далеко не всегда скорость генерации конкретной страницы зависит от количества материалов на сайте, и почти никогда не зависит линейно. Т.е. сделать тормозной сайт вполне можно и без огромного кол-ва данных, и наоборот.
да, кстати, вспомнил что была идентичная проблема с вообще пустым сайтом на данном хостинге - только после установки сайт первый раз долго грузился 5-7 секунд, вообще забыл про это
писал в ТП по этому поводу - сказали что они такой проблемы не обнаружили, не могу понять в чем именно проблема и не могу сымитировать эту ситуацию - удаление кеша из браузера то дает медленную загрузку, то нет...
просто сейчас стоит выбор: можно ли воскресить данный вариант или с нуля собирать все на друпалайф сторе - во втором случае не уверен что история не повторится.. да и в данный сайт положены некоторые усилия))
еще одна просьба - поделитесь ссылкой на хорошую песочницу куда можно было бы установить данный сайт и проверить,
с него все и началось, на денвере - работоспособность полная, а вот скорость работы на нем определить тяжело..
понимаю что толку от этого знания будет мало - но что именно означает под форточки?)
windows )
заведи себе аккаунт на digitalocean и создай каплю за 5 баксов и тестируй сайты в реальных условиях.
как вариант - подними на виртуалбоксе стек максимально близкий по параметрам к своему хостингу,
разверни копию своего ресурса,
и обвешай се профайлерами и ищи узкие места.
форточки ниже:
спасибо за наглядный пример форточек))
завтра опен сервер разверну - к сожалению не так много времени могу уделять программированию...
если все будет нормально - скорее всего перееду на друпалхостинг
у меня на сайте всего 2 блока с вьюсом - топ товары и гарнитура, выше шла речь что 5-6 грузят сайт, надеюсь 1-2 можно оставить?) завтра буду гуглить кеширование блоков))
возникла такая идея: а возможно ли и есть ли смысл сделать главную страницу отдельным файлом html - чтобы при загрузке сайта вообще не было запроса к бд, а выдавалась просто инфа с файла?
надеюсь еще кто-то смотрит в эту тему... так что вернемся к нашим баранам, а точнее барану в моем лице))
вот включил девел, но так и не понял что сильно грузит сайт - запрос к бд 1с, загрузка страницы 4 с чем-то сек, сортировка по продолжительности...
http://pixs.ru/showimage/zagruzka2p_2046181_19730230.png
у вас 1110 запросов - это много. и у вас выборка из таблицы заказов долгая - у меня тоже также на хостинге *одном*. это просто надо хостинг менять.ну и запросы можно было бы в два раза срезать для этого ну попробуйте отключить админ меню, и другие блоки и меню сайта. что будет?
Тоже обратил внимание на 1000 запросов, но их скорость 1мс - на всю тысячу уходит 1 сек, еще 1 сек на первый долгий запрос, куда уходит еще 2-3 секунды..
Ответ на этот вопрос, можно получить с помощью профайлера, например, xhprof. Но по всей вероятности придётся развернуть окружение где-то у себя на основном компе, или виртуалке, где вы сможете его поставить.
А вообще, то, что у вас запрос не такой уж и навороченный, да ещё и при небольшом количестве данных отрабатывает за секунду почти, довольно точно говорит о том, что хостинг надо менять. То, что у вас код при этом выполняется 3 секунды, вполне может быть связано с тем, что на вас сильно пожалели ресурсов процессора просто. И учитывая работу mysql это выглядит более вероятным, чем проблема с сайтом.
спасибо! все-таки оплачу друпалхостинг для теста...
http://habrahabr.ru/post/145895/
Это несколько излишне - devel умеет работать с xhprof.
Впрочем на хостинге это не поможет - там скорее всего xhprof не найдётся.
На сервере, где размещен Ваш хостинг-аккаунт используется процессор на 4 ядра по 2.67GHz.
вроде бы достаточно... или нет?)
Зависит от загруженности сервера.
И настроек.
На серевере может быть 100500 процессоров с миллионом ядер. А выделено может быть 1/100 производительности одного ядра.
Или они могут быть перегружены все кучей сайтов по сосоедству, если нагрузка вообще не распределяется.
И 1 проц с 4 ядрами это, вообще говоря, совсем мелкий сервер.
Если в прошлый раз я говорил о себе как о баране в шутку, то теперь с полной серьезностью... есть такой статус юзера на форуме?) gor, bsyomov и остальные извиняюсь что голову морочил, надеюсь не отобьет охоту помочь новичку)
Сайт был написан года пол назад но отложен в далекий угол, сейчас потребовалось его поднять, помню что вручную прописывал весь каталог и оказалось что это была таксономия, а меню все-таки было подтянуто таксономи-меню...
удалил меню и все летает, теперь вопрос каким способом лучше построить такое большое меню?
первый вариант через обычное меню друпала руками добавить ссылки - геморно и возможен тот же эффект, или при помощи модуля для меню OM maximenu но он ничего особо не изменит - может быть будет немного быстрее, но не целесообразно геморно...
или все-таки через таксономию: taxonomy_get_tree, я так понимаю по этой функции уже и модуль написан Taxonomy menu block, склоняюсь к последнему, но хотелось бы услышать мнение знающих чтобы снова не наступить на старые грабли, хотя я уже на них просто танцую))
Что б не тормозило - лучше в ручную. Фигово если меню привязано к таксономии - тогда надо как то кешировать саму генерацию сеню.
еще не успел протестить, но если я правильно понял Taxonomy menu block работает по другой схеме: создает не меню через друпаловскую систему, а блок и в него вставляет меню..
понял как можно разбить большое меню на маленькие: только возник вопрос не будет сильно грузить сайт наличие 5 маленьких меню с условием показывать на определенных страницах? переборка 5 условий не тяжелее одного большого меню?)
Нет. Создание структуры и обработка вывода меню на порядки более ресурсоёмко, чем проверка условия.