Сайт — armymusic.ru; Joomla — 3.9.15; версия базы данных — 5.7.26-29; версия PHP — 7.2.25; веб-сервер — Apache/2.4.6
Неделю назад хостер прислал уведомление о том, что сайт превысили лимит использования аппаратных ресурсов, предусмотренный текущим тарифным планом. В ходе диагностики ими было выявлено, что повышенное потребление ресурсов обусловлено скачиванием аудиофайлов с сайта. Порекомендовали обратиться к специалистам в области веб-разработки за оптимизацией данного процесса. Не стал этого делать. Проблему решил переходом на другой тариф (дороже, соответственно).
Но 15 февраля вновь пришло уведомление только уже с блокировкой аккаунта, причина такая же — повышенное потребление ресурсов. Диагностика показала следующее, цитирую:
«Превышения вызваны увеличением общего количества запросов к сайту. Для примера, 10.02.2020 поступило 92943 обращения, а 15.02.2020 — 144145 (15 числа была памятная дата в военной истории России, а т.к. сайт с военными песнями, выросла посещаемость, отсюда увеличение количества запросов).
Значительную часть ресурсов потребляют запросы к серверу баз данных. По примеру одного из зафиксированных запросов:
SELECT COUNT(*) FROM xxxxx_muscol_songs WHERE artist_id = 33;
в его описании видим, что происходит анализ 1787 строк без использования индексов:
Рекомендуем передать информацию разработчику вашего сайта для оптимизации SQL-запросов и работы сайта в целом».
Что можете посоветовать в данной ситуации, чтобы снизить потребление ресурсов при скачивании аудиофайлов и оптимизировать SQL-запросы? Реально ли самостоятельно это выполнить или лучше искать исполнителя?
Заранее спасибо!
suffix
Статику раздавать желательно через nginx — может быть подумать перед apache поставить его ?
wicker
NesteA88: Что можете посоветовать в данной ситуации
Рекомендуем
NesteA88: передать информацию разработчику вашего сайта для оптимизации SQL-запросов
Sitealert
NesteA88: Реально ли самостоятельно это выполнить или лучше искать исполнителя?
Если бы могли выполнить самостоятельно, то не задавали бы этот вопрос.
И 144145 запроса в сутки – это «ничто» в плане запросов к базе данных. Надо анализировать ситуацию и искать причину.
Mik Foxi
Ну то что хостер докопался до sql запроса — это не факт что sql запрос плохой, это просто в хостерских логах на момент просмотра был самый тяжелый.
Сколько страниц на сайте? Смотрите аксес логи и баньте говноботов для начала по юзерагенту, особых прогерских знаний и умений на это не надо, возможно в разы, а то и десятки раз снизить нагрузку только этим.
timo-71
NesteA88: WHERE artist_id = 33;
в его описании видим, что происходит анализ 1787 строк без использования индексов:
Может индекс повесить на artist_id?
Sitealert
timo-71: Может индекс повесить на artist_id?
Да это хостер просто впихнул в письмо первое, что попалось. Сам запрос COUNT(*) – никакой, и количество строк 1787 – никакое. Такой запрос проходит за ноль целых хрен десятых хреносекунд.
Aisamiery
Для начала я бы повесил индекс все же на табличку, тем более он у вас прям сильно просится сюда
CREATE INDEX idx_msongs_artist ON xxxxx_muscol_songs (artist_id);
SeVlad
NesteA88: В ходе диагностики ими было выявлено, что повышенное потребление ресурсов обусловлено скачиванием аудиофайлов с сайта.
Статику или через скрипты? Если первое — меняй хостинг или перекладывай на CDN.
ivan-lev
Sitealert: И 144145 запроса в сутки – это «ничто» в плане запросов к базе данных.
Думаю, всё же, речь о просмотрах страниц (+ скачиваний файлов?.. )
увеличением общего количества запросов к сайту
NesteA88: Что можете посоветовать в данной ситуации, чтобы снизить потребление ресурсов при скачивании аудиофайлов и оптимизировать SQL-запросы?
Для начала определиться, в каком месте формируется нагрузка, т.к. можно укопаться в оптимизации, а фактически проблема будет совсем в другом месте.
Стандартно — анализ логов, поиск узких мест.. поинтересоваться у хостера по поводу наиболее «затратных» страниц-файлов-URL-ов.. slow query log попросить.. Профилирование запросов кратковременное включить (если не для всех, то для админа).
Возможно, кто-то просто альбомами песни качает…
SeVlad
ivan-lev: Думаю, всё же, речь о просмотрах страниц..
А вот я думаю, что хостер первый раз (про файлы) прислал правду, а второй (про базу) — просто левую отмазку. И дело вовсе не в базе.
АПД. Хотя я ща досмтрелся — «без использования индексов»? Разве в джумловской базе нет индексов? Чот сомневаюсь.
NesteA88
Добрый день!
Сайт — armymusic.ru; Joomla — 3.9.15; версия базы данных — 5.7.26-29; версия PHP — 7.2.25; веб-сервер — Apache/2.4.6
Неделю назад хостер прислал уведомление о том, что сайт превысили лимит использования аппаратных ресурсов, предусмотренный текущим тарифным планом. В ходе диагностики ими было выявлено, что повышенное потребление ресурсов обусловлено скачиванием аудиофайлов с сайта. Порекомендовали обратиться к специалистам в области веб-разработки за оптимизацией данного процесса. Не стал этого делать. Проблему решил переходом на другой тариф (дороже, соответственно).
Но 15 февраля вновь пришло уведомление только уже с блокировкой аккаунта, причина такая же — повышенное потребление ресурсов. Диагностика показала следующее, цитирую:
«Превышения вызваны увеличением общего количества запросов к сайту. Для примера, 10.02.2020 поступило 92943 обращения, а 15.02.2020 — 144145 (15 числа была памятная дата в военной истории России, а т.к. сайт с военными песнями, выросла посещаемость, отсюда увеличение количества запросов).
Значительную часть ресурсов потребляют запросы к серверу баз данных. По примеру одного из зафиксированных запросов:
SELECT COUNT(*) FROM xxxxx_muscol_songs WHERE artist_id = 33;
в его описании видим, что происходит анализ 1787 строк без использования индексов:
+—-+————-+———————+————+——+—————+——+———+——+——+———-+————-+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+—-+————-+———————+————+——+—————+——+———+——+——+———-+————-+
| 1 | SIMPLE | xxxxx_muscol_songs | NULL | ALL | NULL | NULL | NULL | NULL | 1787 | 10.00 | Using where |
+—-+————-+———————+————+——+—————+——+———+——+——+———-+————-+
Рекомендуем передать информацию разработчику вашего сайта для оптимизации SQL-запросов и работы сайта в целом».
Что можете посоветовать в данной ситуации, чтобы снизить потребление ресурсов при скачивании аудиофайлов и оптимизировать SQL-запросы? Реально ли самостоятельно это выполнить или лучше искать исполнителя?
Заранее спасибо!
suffix
Статику раздавать желательно через nginx — может быть подумать перед apache поставить его ?
wicker
Что можете посоветовать в данной ситуации
Рекомендуем
передать информацию разработчику вашего сайта для оптимизации SQL-запросов
Sitealert
Реально ли самостоятельно это выполнить или лучше искать исполнителя?
Если бы могли выполнить самостоятельно, то не задавали бы этот вопрос.
И 144145 запроса в сутки – это «ничто» в плане запросов к базе данных. Надо анализировать ситуацию и искать причину.
Mik Foxi
Ну то что хостер докопался до sql запроса — это не факт что sql запрос плохой, это просто в хостерских логах на момент просмотра был самый тяжелый.
Сколько страниц на сайте? Смотрите аксес логи и баньте говноботов для начала по юзерагенту, особых прогерских знаний и умений на это не надо, возможно в разы, а то и десятки раз снизить нагрузку только этим.
timo-71
WHERE artist_id = 33;
в его описании видим, что происходит анализ 1787 строк без использования индексов:
Может индекс повесить на artist_id?
Sitealert
Может индекс повесить на artist_id?
Да это хостер просто впихнул в письмо первое, что попалось. Сам запрос COUNT(*) – никакой, и количество строк 1787 – никакое. Такой запрос проходит за ноль целых хрен десятых хреносекунд.
Aisamiery
Для начала я бы повесил индекс все же на табличку, тем более он у вас прям сильно просится сюда
SeVlad
В ходе диагностики ими было выявлено, что повышенное потребление ресурсов обусловлено скачиванием аудиофайлов с сайта.
Статику или через скрипты? Если первое — меняй хостинг или перекладывай на CDN.
ivan-lev
И 144145 запроса в сутки – это «ничто» в плане запросов к базе данных.
Думаю, всё же, речь о просмотрах страниц (+ скачиваний файлов?.. )
Что можете посоветовать в данной ситуации, чтобы снизить потребление ресурсов при скачивании аудиофайлов и оптимизировать SQL-запросы?
Для начала определиться, в каком месте формируется нагрузка, т.к. можно укопаться в оптимизации, а фактически проблема будет совсем в другом месте.
Стандартно — анализ логов, поиск узких мест.. поинтересоваться у хостера по поводу наиболее «затратных» страниц-файлов-URL-ов.. slow query log попросить.. Профилирование запросов кратковременное включить (если не для всех, то для админа).
Возможно, кто-то просто альбомами песни качает…
SeVlad
Думаю, всё же, речь о просмотрах страниц..
А вот я думаю, что хостер первый раз (про файлы) прислал правду, а второй (про базу) — просто левую отмазку. И дело вовсе не в базе.
АПД. Хотя я ща досмтрелся — «без использования индексов»? Разве в джумловской базе нет индексов? Чот сомневаюсь.