NesteA88

NesteA88
Рейтинг
66
Регистрация
24.01.2017
За май

Добрый день! Подскажите, с чем может быть связана ошибка в Рапиде, в графе "Статус" в Истории операций?


Внезапно перестали отображаться рекламные блоки
Tual #:
На всем сайте отрубать mootools не стоит, можно только в шаблоне: В index.php вашего шаблона, до строчки <jdoc:include type="head" />

Вставляем

<?php
unset(
$this->_scripts[$this->baseurl.'/media/system/js/mootools-core.js'],
$this->_scripts[$this->baseurl.'/media/system/js/mootools-more.js']
);
?>

Реклама появляется. Не забываем делать резервные копии. Это для Joomla 2.5, 3 и это не из за обновлений, у меня старинная Joomla и "цементированная", плагины так просто не поставить.
Не известно когда они это починят и будут ли вообще чинить. Но если починят, дайте знать на форуме.

Данный способ мне помог! Спасибо!

Внезапно перестали отображаться рекламные блоки
Спасибо! Если сбой, то к нам еще кто-нибудь должен присоединиться, а так мысли в самую худшую сторону... Да, где-то с полуночи. С сайтом все нормально, ничего не менял, предупреждений и нарушений не было.
Внезапно перестали отображаться рекламные блоки
Присоединяюсь к вопросу. Сегодня возникла точно такая же проблема.
Обман пользователей мобильного интернета

Доброго времени суток!

Вновь на сайт наложен данный фильтр - Обман пользователей мобильного интернета.

При первом обращении в ответ пришло шаблонное письмо. Попросил прислать конкретные страницы, где происходит перенаправление на платные услуги.

Ответ Платона:

Перенаправления происходили, например, с этой страницы вашего сайта: https://armymusic.ru/K/43-korenyugin-aleksandr/54-sanya-1/774-pod-sapogami-mnetsya-gryaz.html на следующие хосты:

  • inductrhdg.pt
  • wpclk.net
  • muzvolna.beeline.ru
  • cdp.beeline.ru

Как это можно проверить? И как увидеть эти редиректы своими глазами?

Оптимизация работы сайта
Aisamiery:
час нормального спеца стоит в рамках 1200 плюс минус.

Где найти такого нормального спеца, который бы вник в проект...

Оптимизация работы сайта
Aisamiery:
Конечно, в большинстве случаев кривизну кода можно компенсировать увеличением железа и его количества до определенного момента, а дальше либо снова платить, либо переписывать.

PS. Не пробовали уточнить, сколько будет разработать такой компонент вам отдельно? Глянул демку, там достаточно банальный CRUD по сути или там под капотом какой то гастрономических масштабов функционал?

Нет, не спрашивал. Но пару лет назад ценник на внесение незначительных правок в код был от 100 евро.

Функционал прост: есть возможность добавить исполнителя, к этому исполнителю добавить альбомы, в альбомы - песни. Также есть поиск по жанрам, тегам и т.д. + в сочетании с другим компонентам выводить статистику (самые популярные песни и т.п.).

Оптимизация работы сайта
Этот запрос действительно ужасный!

Да, возможно, они ужасные. Но все проблемные запросы, на которые жалуется хостер, создаются компонентом для Joomla под названием Music Collection.

Вот, кстати, из последней диагностики (на День ПВ опять был заблокирован):

Запрос: 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 WHERE ( s.tags LIKE "32" OR s.tags LIKE "32,%" OR s.tags LIKE "%,32" OR s.tags LIKE "%,32,%" ) ORDER BY s.added DESC LIMIT 0, 10; выполняет поиск полей в таблице с тегом «32». Вариантом оптимизации данного запроса является исключение полей с похожими тегами, например, «321» или «132».

Самым ресурсоемким является запрос к таблице v0ecf_content_statistics: SELECT s.*, COUNT(st.id) AS howmuch, s.name as item_name, ar.artist_name , CONCAT("index.php?option=com_muscol&view=song&id=", s.id) as item_link FROM v0ecf_content_statistics as st LEFT JOIN v0ecf_muscol_songs AS s ON s.id = st.reference_id 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

При его выполнении происходит обход 3543691 строк, всего в таблице 7265755 строк. Судя по содержанию таблицы, в ней содержатся статистические данные, собранные компонентом com_muscol. В данном случае рекомендуем удалить из таблицы устаревшую информацию или вовсе ее очистить.

Если честно, у меня нет знаний и навыков, чтобы "ковырять" данный компонент, исправляя запросы. После его обновлений надо будет все начинать заново + работоспособность после таких "ковыряний" никто не гарантирует.

Смена хостера может помочь? Или переезд на VPS/VDS? Или чтобы Вы посоветовали в данной ситуации?

слишком много подключений стилей и скриптов файлов.

Да, с этим полностью согласен. Если с css еще могу разобраться, то с js сложнее.

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

Плагин 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 строк. В эту таблицу уже добавлены необходимые индексы, к полям участвующим в запросе, однако из-за параметров запроса они не используются, потому происходит обход такого большого количества строк.

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

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

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

1 234567 8
Всего: 78