- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
VK приобрела 70% в структуре компании-разработчика red_mad_robot
Которая участвовала в создании RuStore
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Добрый день!
Сайт - 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-запросы? Реально ли самостоятельно это выполнить или лучше искать исполнителя?
Заранее спасибо!
Статику раздавать желательно через nginx - может быть подумать перед apache поставить его ?
Что можете посоветовать в данной ситуации
Рекомендуем
передать информацию разработчику вашего сайта для оптимизации SQL-запросов
Реально ли самостоятельно это выполнить или лучше искать исполнителя?
Если бы могли выполнить самостоятельно, то не задавали бы этот вопрос.
И 144145 запроса в сутки – это "ничто" в плане запросов к базе данных. Надо анализировать ситуацию и искать причину.
Ну то что хостер докопался до sql запроса - это не факт что sql запрос плохой, это просто в хостерских логах на момент просмотра был самый тяжелый.
Сколько страниц на сайте? Смотрите аксес логи и баньте говноботов для начала по юзерагенту, особых прогерских знаний и умений на это не надо, возможно в разы, а то и десятки раз снизить нагрузку только этим.
WHERE artist_id = 33;
в его описании видим, что происходит анализ 1787 строк без использования индексов:
Может индекс повесить на artist_id?
Может индекс повесить на artist_id?
Да это хостер просто впихнул в письмо первое, что попалось. Сам запрос COUNT(*) – никакой, и количество строк 1787 – никакое. Такой запрос проходит за ноль целых хрен десятых хреносекунд.
Для начала я бы повесил индекс все же на табличку, тем более он у вас прям сильно просится сюда
В ходе диагностики ими было выявлено, что повышенное потребление ресурсов обусловлено скачиванием аудиофайлов с сайта.
Статику или через скрипты? Если первое - меняй хостинг или перекладывай на CDN.
И 144145 запроса в сутки – это "ничто" в плане запросов к базе данных.
Думаю, всё же, речь о просмотрах страниц (+ скачиваний файлов?.. )
Что можете посоветовать в данной ситуации, чтобы снизить потребление ресурсов при скачивании аудиофайлов и оптимизировать SQL-запросы?
Для начала определиться, в каком месте формируется нагрузка, т.к. можно укопаться в оптимизации, а фактически проблема будет совсем в другом месте.
Стандартно - анализ логов, поиск узких мест.. поинтересоваться у хостера по поводу наиболее "затратных" страниц-файлов-URL-ов.. slow query log попросить.. Профилирование запросов кратковременное включить (если не для всех, то для админа).
Возможно, кто-то просто альбомами песни качает...
Думаю, всё же, речь о просмотрах страниц..
А вот я думаю, что хостер первый раз (про файлы) прислал правду, а второй (про базу) - просто левую отмазку. И дело вовсе не в базе.
АПД. Хотя я ща досмтрелся - "без использования индексов"? Разве в джумловской базе нет индексов? Чот сомневаюсь.