Проблема с загрузкой сайта

Аватар пользователя aka drupaller aka drupaller 27 ноября 2015 в 20:14

Дело такого рода что первый раз стартовая страница загружается около 5-7 секунд, стоит друпал + коммерц + сопутствующие модули, сайт пока не загружен контентом - подскажите что проверять или чем)) кэш пока только стандартный: страницы карточек товара нормально грузятся после создания кэша, но вот с стартовой страницей надо что-то делать.. буду благодарен за любую помощь!

Комментарии

Аватар пользователя tlito tlito 27 ноября 2015 в 20:33

этот вопрос меня тоже очень заботит. ускорению д7 посвящены несколько постов на тлито.ру, пока что с коммерцем я так и не разобрался потому что на впс не хочу его держать так как еще не умею настраивать мемкеш, а на джино как-то медленно бд работает, хотя на бегете вообще не работало
я вам могу советовать:
1. включите authcache + filecache - это работает на шаред хостингах
2. не пользуйтесь таксономи меню и представляенияи в блоках тоже не пользуйтесь
3. переезжайте на друпалхостинг или рувеб.нет, или на свою впс и включайте мемкеш и entity cache
на данный момент я думаю что д7 коммерц трудно ускорить новичку, так что пробуйте другие системы, например joomla магазины, вп екоммерц, ruby solidus https://github.com/solidusio/solidus и другие движки, даже платный вебасист или пхпшоп. мне кажется что их использование будет вызывать меньше проблем связанных с тормозами. но первое что вы должны сделать - выбрать другого хостера. поделитесь опытом, если исследуете

Аватар пользователя Grayw0lf Grayw0lf 27 ноября 2015 в 20:38

Tlito, к чему все это? Если не умеешь готовить то может быть стоит отстать от друпала?

Аватар пользователя gor gor 27 ноября 2015 в 21:30

Вообще то он прав по некоторым пунктам:
- не делать таксономия меню ( реально тормозной вариант если без кеширования результата)
- не выносить представления виевс в блоки ( или включать кеширование для них отдельно)
- осторожно выбирать хостинг ( очень дешевые часто перегружены по бд)
- включить filecache ( реально помогает когда в кеш базы слишком много гигабайт данных падает и база тупо не тянет)

Имхо это ответ вполне .

Аватар пользователя Айдар Айдар 30 ноября 2015 в 22:42

@gor, можно пару вопросов:

  1. Почему именно блоки? Views panes тоже к ним относятся? Или именно потому что в рамках одной страницы может быть много блоков?
  2. filecache - это конкретный модуль и просто название концепции хранения кеша в файлах?
Аватар пользователя gor gor 1 декабря 2015 в 4:12

1 - из опыта. чаще всего проблему видел на сайтах, где на 1 страницу было 5-10 блоков из views представлений собранных по рекомендациям из поисковика. Без включенного кеширования представления. Итог обычно печальный - при достаточно малой посещаемости, дикая нагрузка базы по трафику (мегабайты данных в секунду). Теоретически это могут быть видимо и панели, но пока не попадалось, не могу судить.
2 - https://www.drupal.org/project/filecache или https://www.drupal.org/project/cacherouter - В случае если на сайте много таких вот блоков, встроенное в views кеширование не помогает. Так как в результате тянуться мегабайты генерированного вывода из кеш таблицы. Спасает очень. Так как прочитать файл с диска стоит дешевле чем вытянуть из базы. На примере DH Elastic тарифа, включение этих модулей позволяло снизить стоимость хостинга на порядок для клиента.

Аватар пользователя Айдар Айдар 4 декабря 2015 в 14:38

Ну, по первому пункту речь, получается, именно о наличии множества дисплеев на одной странице, а не о блоках views как таковых?
По панелям да, у меня есть сайт, где в форме из селект-листа выбираются пункты, и по каждому пункту показывается свой views pane (по сущности являясь отдельным дисплеем), меняя класс display - с none на block. Так вот, на странице получается постоянно грузятся около 10 views panes - ситуация с нагрузкой аналогичная описанной Вами. Хотя таки неплхая система кеширования самих панелей спасает.

По второму пункту понял, спасибо! А к старому-доброму бусту как варианту как Вы относитесь?

Аватар пользователя gor gor 4 декабря 2015 в 16:35

Boost н же во всех случаях спасает. Он кеширует для анонимов и целиком. Соответственно он полезен когда трафик анонимный ( не авторизируется) и попавшие в буст страницы окрашиваются больше чем 1 раз за время до истечения срока Кеша.
Особенно плохо бывает когда материалов 10000 , а в итоге их боты только парсят раз в день.
И время жизни 5 минут.

Вообщем с умом использовать надо и в ситуациях где он нужен.

Аватар пользователя Айдар Айдар 4 декабря 2015 в 18:29

Ну это понятно, да. Спасибо!

Я думаю, в моём случае - в контентных проектах со статикой, нацеленных на трафик анонимов, как раз буст будет полезен.

Аватар пользователя dropout dropout 27 ноября 2015 в 21:23

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

Аватар пользователя gor gor 27 ноября 2015 в 21:27

Еще вариант - включите devel модуль с xhprof. Он позволит начать понимать где именно тормоза.

Аватар пользователя Grayw0lf Grayw0lf 27 ноября 2015 в 21:53

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

Аватар пользователя aka drupaller aka drupaller 30 ноября 2015 в 12:56

Добрый день, извиняюсь что пропал.. спасибо кто отвечал!
1. сайт находится на украинском хостере https://www.ukraine.com.ua/ на тарифе Лучший SSD - не самый дешевый хостинг, и по характеристикам не плохой, на мой взгляд.. что вы скажете по поводу хостера?
2. чаще всего при первой загрузке долго грузится файл www.camozzi,in.ua - по-этому не знаю что именно менять
3. сегодня из 5 секунд 4 загружался слайд - выключил его на данный момент, стоял Views Slideshow: Cycle - подскажите плз какой лучше слайдер использовать?
4. таксономи меню не используется - меню построено вручную)
5. кеш конечно будет включен, но на данный момент сайт пустой - он же должен грузится быстро? из-за этого я и грешу на свою "сборку"
6. вьюха в блоке - есть альтернативный способ отображать принадлежности к товару?
p.s. надеюсь ни у кого нет предвзятости что я с Украины..

Аватар пользователя bsyomov bsyomov 30 ноября 2015 в 13:16

3. Статика грузится довольно вяло, так что вероятно, с хостингом всё не очень хорошо, и это может быть одной из проблем, и даже основной проблемой. Скорость загрузки картинки в слайдере зависит не от слайдера, а от хостинга.
5. Devel и xhprof, или хотя бы просто devel, могли бы прояснить ситуацию с тем, на что тратится время при генерации страницы. Иначе это просто гадание на кофейной гуще будет. По поводу пустого сайта - далеко не всегда скорость генерации конкретной страницы зависит от количества материалов на сайте, и почти никогда не зависит линейно. Т.е. сделать тормозной сайт вполне можно и без огромного кол-ва данных, и наоборот.

Аватар пользователя aka drupaller aka drupaller 30 ноября 2015 в 13:40

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

Аватар пользователя aka drupaller aka drupaller 30 ноября 2015 в 14:12

просто сейчас стоит выбор: можно ли воскресить данный вариант или с нуля собирать все на друпалайф сторе - во втором случае не уверен что история не повторится.. да и в данный сайт положены некоторые усилия))
еще одна просьба - поделитесь ссылкой на хорошую песочницу куда можно было бы установить данный сайт и проверить,

Аватар пользователя aka drupaller aka drupaller 30 ноября 2015 в 16:12

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

Аватар пользователя aka drupaller aka drupaller 30 ноября 2015 в 18:04

понимаю что толку от этого знания будет мало - но что именно означает под форточки?)

Аватар пользователя dropout dropout 30 ноября 2015 в 18:09

akafaust wrote:
понимаю что толку от этого знания будет мало - но что именно означает под форточки?)

windows )
заведи себе аккаунт на digitalocean и создай каплю за 5 баксов и тестируй сайты в реальных условиях.

Аватар пользователя multpix multpix 30 ноября 2015 в 18:15

как вариант - подними на виртуалбоксе стек максимально близкий по параметрам к своему хостингу,
разверни копию своего ресурса,
и обвешай се профайлерами и ищи узкие места.

форточки ниже:

Аватар пользователя aka drupaller aka drupaller 1 декабря 2015 в 4:57

спасибо за наглядный пример форточек))
завтра опен сервер разверну - к сожалению не так много времени могу уделять программированию...
если все будет нормально - скорее всего перееду на друпалхостинг
у меня на сайте всего 2 блока с вьюсом - топ товары и гарнитура, выше шла речь что 5-6 грузят сайт, надеюсь 1-2 можно оставить?) завтра буду гуглить кеширование блоков))

Аватар пользователя aka drupaller aka drupaller 2 декабря 2015 в 9:31

возникла такая идея: а возможно ли и есть ли смысл сделать главную страницу отдельным файлом html - чтобы при загрузке сайта вообще не было запроса к бд, а выдавалась просто инфа с файла?

Аватар пользователя aka drupaller aka drupaller 3 декабря 2015 в 12:52

надеюсь еще кто-то смотрит в эту тему... так что вернемся к нашим баранам, а точнее барану в моем лице))
вот включил девел, но так и не понял что сильно грузит сайт - запрос к бд 1с, загрузка страницы 4 с чем-то сек, сортировка по продолжительности...
http://pixs.ru/showimage/zagruzka2p_2046181_19730230.png

Аватар пользователя tlito tlito 3 декабря 2015 в 13:41

у вас 1110 запросов - это много. и у вас выборка из таблицы заказов долгая - у меня тоже также на хостинге *одном*. это просто надо хостинг менять.ну и запросы можно было бы в два раза срезать для этого ну попробуйте отключить админ меню, и другие блоки и меню сайта. что будет?

Аватар пользователя aka drupaller aka drupaller 3 декабря 2015 в 15:28

Тоже обратил внимание на 1000 запросов, но их скорость 1мс - на всю тысячу уходит 1 сек, еще 1 сек на первый долгий запрос, куда уходит еще 2-3 секунды..

Аватар пользователя bsyomov bsyomov 3 декабря 2015 в 16:53

Ответ на этот вопрос, можно получить с помощью профайлера, например, xhprof. Но по всей вероятности придётся развернуть окружение где-то у себя на основном компе, или виртуалке, где вы сможете его поставить.

А вообще, то, что у вас запрос не такой уж и навороченный, да ещё и при небольшом количестве данных отрабатывает за секунду почти, довольно точно говорит о том, что хостинг надо менять. То, что у вас код при этом выполняется 3 секунды, вполне может быть связано с тем, что на вас сильно пожалели ресурсов процессора просто. И учитывая работу mysql это выглядит более вероятным, чем проблема с сайтом.

Аватар пользователя bsyomov bsyomov 3 декабря 2015 в 16:47

Это несколько излишне - devel умеет работать с xhprof.
Впрочем на хостинге это не поможет - там скорее всего xhprof не найдётся.

Аватар пользователя aka drupaller aka drupaller 4 декабря 2015 в 0:07

На сервере, где размещен Ваш хостинг-аккаунт используется процессор на 4 ядра по 2.67GHz.
вроде бы достаточно... или нет?)

Аватар пользователя bsyomov bsyomov 4 декабря 2015 в 13:05

На серевере может быть 100500 процессоров с миллионом ядер. А выделено может быть 1/100 производительности одного ядра. Smile Или они могут быть перегружены все кучей сайтов по сосоедству, если нагрузка вообще не распределяется.
И 1 проц с 4 ядрами это, вообще говоря, совсем мелкий сервер. Smile

Аватар пользователя aka drupaller aka drupaller 4 декабря 2015 в 14:09

Если в прошлый раз я говорил о себе как о баране в шутку, то теперь с полной серьезностью... есть такой статус юзера на форуме?) gor, bsyomov и остальные извиняюсь что голову морочил, надеюсь не отобьет охоту помочь новичку)
Сайт был написан года пол назад но отложен в далекий угол, сейчас потребовалось его поднять, помню что вручную прописывал весь каталог и оказалось что это была таксономия, а меню все-таки было подтянуто таксономи-меню...
удалил меню и все летает, теперь вопрос каким способом лучше построить такое большое меню?
первый вариант через обычное меню друпала руками добавить ссылки - геморно и возможен тот же эффект, или при помощи модуля для меню OM maximenu но он ничего особо не изменит - может быть будет немного быстрее, но не целесообразно геморно...
или все-таки через таксономию: taxonomy_get_tree, я так понимаю по этой функции уже и модуль написан Taxonomy menu block, склоняюсь к последнему, но хотелось бы услышать мнение знающих чтобы снова не наступить на старые грабли, хотя я уже на них просто танцую))

Аватар пользователя gor gor 4 декабря 2015 в 16:37

Что б не тормозило - лучше в ручную. Фигово если меню привязано к таксономии - тогда надо как то кешировать саму генерацию сеню.

Аватар пользователя aka drupaller aka drupaller 4 декабря 2015 в 21:34

еще не успел протестить, но если я правильно понял Taxonomy menu block работает по другой схеме: создает не меню через друпаловскую систему, а блок и в него вставляет меню..

Аватар пользователя aka drupaller aka drupaller 5 декабря 2015 в 19:17

понял как можно разбить большое меню на маленькие: только возник вопрос не будет сильно грузить сайт наличие 5 маленьких меню с условием показывать на определенных страницах? переборка 5 условий не тяжелее одного большого меню?)

Аватар пользователя bsyomov bsyomov 21 января 2016 в 17:36

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