Оптимизация работы сайта

NesteA88
На сайте с 24.01.2017
Offline
59
2159

Добрый день!

Сайт - 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
На сайте с 26.08.2010
Offline
325
#1

Статику раздавать желательно через nginx - может быть подумать перед apache поставить его ?

Клуб любителей хрюш (https://www.babai.ru)
W
На сайте с 08.02.2017
Offline
169
#2
NesteA88:
Что можете посоветовать в данной ситуации

Рекомендуем

NesteA88:
передать информацию разработчику вашего сайта для оптимизации SQL-запросов
Комплексный аудит ИМ. Формирование УТП, анализ юзабилити, каналов продвижения. Контекстная реклама, настройка систем аналитики. Консультация - бесплатно, в ЛС
S
На сайте с 30.09.2016
Offline
469
#3
NesteA88:
Реально ли самостоятельно это выполнить или лучше искать исполнителя?

Если бы могли выполнить самостоятельно, то не задавали бы этот вопрос.

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

Отпилю лишнее, прикручу нужное, выправлю кривое. Вытравлю вредителей.
Mik Foxi
На сайте с 02.03.2011
Offline
1076
#4

Ну то что хостер докопался до sql запроса - это не факт что sql запрос плохой, это просто в хостерских логах на момент просмотра был самый тяжелый.

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

Антибот, антиспам, веб файрвол, защита от накрутки поведенческих: https://antibot.cloud/ + партнерка, до 40$ с продажи.
T7
На сайте с 19.09.2018
Offline
63
#5
NesteA88:
WHERE artist_id = 33;

в его описании видим, что происходит анализ 1787 строк без использования индексов:

Может индекс повесить на artist_id?

S
На сайте с 30.09.2016
Offline
469
#6
timo-71:
Может индекс повесить на artist_id?

Да это хостер просто впихнул в письмо первое, что попалось. Сам запрос COUNT(*) – никакой, и количество строк 1787 – никакое. Такой запрос проходит за ноль целых хрен десятых хреносекунд.

Aisamiery
На сайте с 12.04.2015
Offline
293
#7

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

CREATE INDEX idx_msongs_artist ON xxxxx_muscol_songs (artist_id);
Разработка проектов на Symfony, Laravel, 1C-Bitrix, UMI.CMS, OctoberCMS
SeVlad
На сайте с 03.11.2008
Offline
1609
#8
NesteA88:
В ходе диагностики ими было выявлено, что повышенное потребление ресурсов обусловлено скачиванием аудиофайлов с сайта.

Статику или через скрипты? Если первое - меняй хостинг или перекладывай на CDN.

Делаю хорошие сайты хорошим людям. Предпочтение коммерческим направлениям. Связь со мной через http://wp.me/P3YHjQ-3.
IL
На сайте с 20.04.2007
Offline
435
#9
Sitealert:
И 144145 запроса в сутки – это "ничто" в плане запросов к базе данных.

Думаю, всё же, речь о просмотрах страниц (+ скачиваний файлов?.. )

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

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

Стандартно - анализ логов, поиск узких мест.. поинтересоваться у хостера по поводу наиболее "затратных" страниц-файлов-URL-ов.. slow query log попросить.. Профилирование запросов кратковременное включить (если не для всех, то для админа).

Возможно, кто-то просто альбомами песни качает...

... :) Облачные серверы от RegRu - промокод 3F85-3D10-806D-7224 ( http://levik.info/regru )
SeVlad
На сайте с 03.11.2008
Offline
1609
#10
ivan-lev:
Думаю, всё же, речь о просмотрах страниц..

А вот я думаю, что хостер первый раз (про файлы) прислал правду, а второй (про базу) - просто левую отмазку. И дело вовсе не в базе.

АПД. Хотя я ща досмтрелся - "без использования индексов"? Разве в джумловской базе нет индексов? Чот сомневаюсь.

Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий