NesteA88

NesteA88
Рейтинг
76
Регистрация
24.01.2017
превью картинки надо создавать единожды, и а дальше отдавать уже ранее сгенерированное изображение.

Плагин SP Thumbnail используется всего для нескольких изображений (их не больше десятка) с определенным классом на определенных страницах.

Я не знаю, почему они пишут, что эскизы всех изображений на сайте генерируются этим плагином.

Основная часть изображений - это фото исполнителей и обложки альбомов разных размеров, добавленных через основной компонент - Music Collection. Возможно, именно он генерирует каждый раз превью картинок.

По поводу запроса нужно убрать из запроса ORDER BY RAND()

К сожалению, знаний для этого не хватает.

Всем добрый день! И всех с праздником Великой Победы!

Каюсь, не отвечал тут. Так уж получилось. Но очередной военный праздник опять привел к предупреждению от хостера. В общем, проблему надо решать.

LEOnidUKG:
Да не ребят, я посмотрел там и БД и запросы. Там выключен кэш т.е. идёт по 350-400 запросов к БД. В основном затупы при записи сессии, как принято у джумлы это делается в БД. Я сделал таблицу MEMORY, но что-то хостеру вообще попалам на это.

Перевод таблицы с сессиями в MEMORY привел к появлению на сайте ошибки такого плана Error: Failed to start application: Error starting the session в связи с тем, что допустимый объем MEMORY регулируется параметром max_heap_table_size, ныне равным 32 Мб. При достижении данного значения появлялась указанная ошибка. Пришлось вернуть стандартный тип для таблицы _session - InnoDB.

Стандартный кэш отключен в связи с тем, что на сайте перестает работать плеер на страницах с песнями, альбомами и исполнителями. Может еще что-то отваливается, не проверял.

А что за хостер? таймвэб какой нибудь или спейсвэб? или можордомо?

Спринтхост.

Sitealert:
Если бы могли выполнить самостоятельно, то не задавали бы этот вопрос.
И 144145 запроса в сутки – это "ничто" в плане запросов к базе данных. Надо анализировать ситуацию и искать причину.

Вы могли бы взяться за диагностику данной проблемы?

Выложу крайний ответ хостера. 7 мая они прислали предупреждение о превышении лимита ресурсов. Я попросил продиагностировать и указать причины.

Повышенное потребление ресурсов на вашем аккаунте вызвано большим количеством запросов к самому сайту. На момент проведения диагностики к сайту было совершено 201497 запросов, это практически в полтора раза больше, чем за вчерашний день — 152082.

Одним из факторов такого большого количества обращений является то, что каждый запрос к страницам сайта генерирует множество дополнительных. При обращении к главной странице сайта генерируется порядка 11 дополнительных обращений, большая часть из которых — генерация эскизов, превью картинок (9 запросов). Пример таких запросов ниже:

[08/May/2020:19:38:16 +0300] 0.101 0.501 200 94.140.192.2 armymusic.ru GET /index.php?option=com_muscol&task=thumbnail&type=album&file=chernyi_tyulpan.jpg&width=48&height= HTTP/2.0 "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.163 Safari/537.36 OPR/67.0.3575.137" "https://armymusic.ru/" 6279 141.8.194.42 armymusic
[08/May/2020:19:38:16 +0300] 0.099 0.550 200 94.140.192.2 armymusic.ru GET /index.php?option=com_muscol&task=thumbnail&type=artist&file=nofoto.jpg&width=200&height= HTTP/2.0 "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.163 Safari/537.36 OPR/67.0.3575.137" "https://armymusic.ru/" 14432 141.8.194.42 armymusic
[08/May/2020:19:38:16 +0300] 0.100 0.650 200 94.140.192.2 armymusic.ru GET /index.php?option=com_muscol&task=thumbnail&type=artist&file=kordon.jpg&width=200&height= HTTP/2.0 "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.163 Safari/537.36 OPR/67.0.3575.137" "https://armymusic.ru/" 50157 141.8.194.42 armymusic

Судя по коду сайта и содержанию запросов, эскизы генерируются плагином SP Thumbnail.

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

Также вы можете отключить данный плагин и использовать аналогичное по функционалу решение.

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

SELECT s.*,al.name AS album_name, al.image, ar.artist_name FROM v0ecf_muscol_songs as s LEFT JOIN v0ecf_muscol_albums as al ON al.id = s.album_id LEFT JOIN v0ecf_muscol_artists as ar ON ar.id = s.artist_id ORDER BY RAND() LIMIT 5;

+----+-------------+-------+------------+--------+---------------+---------+---------+----------------------------+------+----------+---------------------------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+-------+------------+--------+---------------+---------+---------+----------------------------+------+----------+---------------------------------+
| 1 | SIMPLE | s | NULL | ALL | NULL | NULL | NULL | NULL | 2015 | 100.00 | Using temporary; Using filesort |
| 1 | SIMPLE | al | NULL | eq_ref | PRIMARY | PRIMARY | 4 | armymusic_test.s.album_id | 1 | 100.00 | NULL |
| 1 | SIMPLE | ar | NULL | eq_ref | PRIMARY | PRIMARY | 4 | armymusic_test.s.artist_id | 1 | 100.00 | NULL |
+----+-------------+-------+------------+--------+---------------+---------+---------+----------------------------+------+----------+---------------------------------+

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

В данном случае рекомендуем изменить запрос с учётом добавленных в базу данных индексов.

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

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

Подскажите, пожалуйста, ничего не меняли в итоге на самом сайте? Осталась реклама РСЯ и Адсенс?

На сайте ничего не менял. Рекламу тоже не трогал. Переписка со службой поддержки результата не дала. Просто нажал кнопку.

Кроме нажатия кнопки мыслей нет)

Фильтр сняли. После нажатия кнопки прошло около 2-х недель.

Ответил мне Платон. Я в письме также сослался на эту тему.

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

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

Либо я не столь убедителен, либо мне попался очень дотошный представитель службы поддержки. Хз что делать! Кроме нажатия кнопки мыслей нет)

webnoob, спасибо за информацию! Попробую еще раз написать.

Напишу ответ им со ссылкой на эту тему.

webnoob, есть новости от Платона?

Лучше переписываться с Платоном, доказывая свою правоту.

Я уже не знаю, какие доводы им приводить! Да и в итоге оказывается, что ответы шаблонные...

webnoob, на мое письмо мне пришел точно такой же ответ:

Мы проверили: ваш сайт действительно перенаправлял пользователей на домен reredirecting.com с платными мобильными подписками. Так что никакой ошибки в наложении ограничений нет. Вам нужно найти причину редиректов и удалить её.

Я уже было начал грешить на взлом сайта, но раз не у меня одного такая ситуация... Может просто нажать кнопку "Я все исправил" и посмотреть, что будет?

grey109, все аналогично. Платону сразу же написал, получил точно такой же ответ с примером страницы с нарушением. Пробовал воспроизвести с разных браузеров и с разных мобильных устройств - безрезультатно. Никаких перенаправлений. Отписался об этом Платону. Вот жду результата. Кнопку пока не нажимал.

Всего: 80