Сайт на InstantCMS v1.9
Включил в админке в настройках сайта режим отладки.
Для главной страницы:
Время генерации страницы: 2.6737 сек.
Запросы к базе: 185
Это нормально, особенно такое количество запросов? У кого как?
#1
16 января 2016 в 19:06
#2
16 января 2016 в 19:09
2.6737 сек — это НЕ нормально!
#3
16 января 2016 в 19:17
Скорее всего в главном меню есть выпадающие категории и если их много, то может и из-за них в частности.
Сегодня в 21:07
#4
16 января 2016 в 21:13
SQL: 43 Cache: 0 Mem: 3.22 Mb Time: 0.1080 s
на 2.4.0 — давай к нам
на 2.4.0 — давай к нам
#5
16 января 2016 в 21:24
Значит на хосте не включено кэширование запросов в мускуле, да и вообще кэширование модулей не используется.
#6
16 января 2016 в 21:31
именно, дефолт без кнопкоприкладства
#7
16 января 2016 в 21:41
Вот почему то время загрузки меняется, сейчас:
Время генерации страницы: 0.3820 сек.
Запросы к базе: 185
через пару минут
Время генерации страницы: 0.5215 сек.
Запросы к базе: 185
это всё для главной страницы.
Время генерации страницы: 0.3820 сек.
Запросы к базе: 185
через пару минут
Время генерации страницы: 0.5215 сек.
Запросы к базе: 185
это всё для главной страницы.
Скорее всего это вопрос к админам сервера/хостинга. Если хостинг шаровый или свой с несколькими сайтами на нём, то такая картина может быть при наличии высоконагруженных соседних сайтов. Админы сервера могут увидеть кто так сильно нагружает. Возможен вариант и с неверно настроенным SQL-сервером, как тут уже сказали. Есть ещё вариант — DDOS-атака. Но это также вопрос к админам сервера.
На нормальном сервере при правильных SQL-запросах Единичка показывает время несколько меньшее, чем Двойка. К примеру, у меня на сайте с дефолтными двумя десятками запросов время создания страниц меньше 100 мс. При количестве правильных запросов под 200 штук, на моём сервере время увеличилось бы примерно на 75 мс (по пол мс на каждый запрос). То есть, суммарно в пределах 200 мс. Всё сильно зависит от того, какие это запросы и как организованы. Так что даже для нешустрого хостинга время больше 1 секунды — это слишком много.
На нормальном сервере при правильных SQL-запросах Единичка показывает время несколько меньшее, чем Двойка. К примеру, у меня на сайте с дефолтными двумя десятками запросов время создания страниц меньше 100 мс. При количестве правильных запросов под 200 штук, на моём сервере время увеличилось бы примерно на 75 мс (по пол мс на каждый запрос). То есть, суммарно в пределах 200 мс. Всё сильно зависит от того, какие это запросы и как организованы. Так что даже для нешустрого хостинга время больше 1 секунды — это слишком много.
Да, вот бы понять откуда такие нагрузки. Сайт на виртуальном хостинге один, на InstantCMS v.1.9 Сегодня хостер перенес б/д на другой сервер: "В целях оптимизации работоспособности был осуществлен перенос Вашей услуги хостинга на другой сервер БД". Но сегодня и народу меньше на сайте(выходные).
Время генерации страницы: 0.8425 сек.
Запросы к базе: 187
...
Время генерации страницы: 0.2988 сек.
Запросы к базе: 185
Вроде бы пока ситуация стабилизировалась.
По использованию памяти что было и что стало(после переноса на другой сервер в 9:30 по графику видно):
Еще такая есть проблема или не проблема, не знаю.
Посмотрел в error_log на сайте, а там для меня непонятное:
....
Что это за ж**а? Какие-то обращения, их много (этих ссылок и файлов у меня на сайте нет).
Время генерации страницы: 0.8425 сек.
Запросы к базе: 187
...
Время генерации страницы: 0.2988 сек.
Запросы к базе: 185
Вроде бы пока ситуация стабилизировалась.
По использованию памяти что было и что стало(после переноса на другой сервер в 9:30 по графику видно):
Еще такая есть проблема или не проблема, не знаю.
Посмотрел в error_log на сайте, а там для меня непонятное:
Что это за ж**а? Какие-то обращения, их много (этих ссылок и файлов у меня на сайте нет).
#10
17 января 2016 в 21:30
apple-touch-icon — это специальные иконки для эппловских устройств. При заходе с яблочного планшета/компа/телефона браузер их ищет и у Вас не находит. Можете или почитать про них и сделать себе на сайт эти иконки, или проигнорировать.
По второму виду ссылок на xml ничего сказать не могу.
По графику памяти можно сказать лишь то, что периодически (от раза в пару часов до пары раз в час) у Вас расходуется много памяти. По какой причине — сказать трудно. Может много одновременных просмотров, может открываются какие-то "тяжёлые" страницы. Может боты сканируют. Может ещё что-то.
Какая посещаемость ресурса? Сколько показов страниц в день?
Тормоза наблюдаются на всех страницах сайта или только на некоторых?
Какие запросы в логе тяжёлых запросов?
По второму виду ссылок на xml ничего сказать не могу.
По графику памяти можно сказать лишь то, что периодически (от раза в пару часов до пары раз в час) у Вас расходуется много памяти. По какой причине — сказать трудно. Может много одновременных просмотров, может открываются какие-то "тяжёлые" страницы. Может боты сканируют. Может ещё что-то.
Какая посещаемость ресурса? Сколько показов страниц в день?
Тормоза наблюдаются на всех страницах сайта или только на некоторых?
Какие запросы в логе тяжёлых запросов?
Около 600 в выходные, до 1500 в будни дни(суточная посещаемость).
Посмотрим будут ли такие тормоза после переезда на новый сервер.
Тормоза бывают на главной странице или всём сайте(висит, не открывается, потом на хостинге в админке вижу такой скачок потребления памяти), в логах доступа ничего необычного, кроме увеличения именно вот этих ссылок на левые сайты с одних и тех-же IP адресов.
Такое впечатление что для чего-то используют конструкцию перехода /redirect?url=http: их сайт, может таким образом пытаются для поднятия реётинга в ПС(поисковой системе) якобы переход с моего на свой сайт засчитать?
Посмотрим будут ли такие тормоза после переезда на новый сервер.
Тормоза бывают на главной странице или всём сайте(висит, не открывается, потом на хостинге в админке вижу такой скачок потребления памяти), в логах доступа ничего необычного, кроме увеличения именно вот этих ссылок на левые сайты с одних и тех-же IP адресов.
Такое впечатление что для чего-то используют конструкцию перехода /redirect?url=http: их сайт, может таким образом пытаются для поднятия реётинга в ПС(поисковой системе) якобы переход с моего на свой сайт засчитать?
#12
17 января 2016 в 22:37
А по времени эти левые переходы в логах совпадают с пиками потребления памяти?
#13
18 января 2016 в 05:09
Закройте переход по ссылке go, чтоб спамеры от Вас отстали.Что это за ж**а? Какие-то обращения, их много (этих ссылок и файлов у меня на сайте нет).
Но по генерации у вас первое это без кэша, второе с кэшом как я понял. Какие модули стоят и делают большую выборку?
#14
18 января 2016 в 08:54
Включите кэширование модулей.
Найдите модуль который создает проблему, можно методом "научного тыка" — отключите его, если все тормозит из-за него
Найдите модуль который создает проблему, можно методом "научного тыка" — отключите его, если все тормозит из-за него
Кэширование модулей включил.
Да, по времени эти левые переходы в логах часто совпадают с пиками потребления памяти.
Как закрыть переход по ссылке go, чтоб спамеры отстали? Что-то прописать в .htaccess?
В robots.txt уже прописал
User-agent: *
Disallow: /go/
да а в файле access.log куча вот таких конструкций:
Да, по времени эти левые переходы в логах часто совпадают с пиками потребления памяти.
Как закрыть переход по ссылке go, чтоб спамеры отстали? Что-то прописать в .htaccess?
В robots.txt уже прописал
User-agent: *
Disallow: /go/
да а в файле access.log куча вот таких конструкций: