- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Переиграть и победить: как анализировать конкурентов для продвижения сайта
С помощью Ahrefs
Александр Шестаков
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
А что за хостер? таймвэб какой нибудь или спейсвэб? или можордомо?
:)
SeVlad, а ну из той же категории, но правда NS еще не говорят что там и хостинг, надо по IP смотреть
SeVlad, а ну из той же категории, но правда NS еще не говорят что там и хостинг, надо по IP смотреть
Да вроде он и есть, что выше на скрине. Ну виртуальный.
Я сделал таблицу MEMORY, но что-то хостеру вообще попалам на это.
Дык ктож будет вам место в ОЗУ отдавать на хостинге-то.
Отключен мемори скорее всего
Дык ктож будет вам место в ОЗУ отдавать на хостинге-то.
Отключен мемори скорее всего
Как он отключен, если его можно выставить и он отображается как MEMORY?
---------- Добавлено 20.02.2020 в 15:19 ----------
Также эти таблицы отлично лимитируются в настройках. Поэтому тут не вижу никаких проблем.
а ну из той же категории, но правда NS еще не говорят что там и хостинг, надо по IP смотреть
Если глубоко копнуть, то ты прав. Но в 99% и вхуиза достаточно.
А я вообще не знаю хостеров, которые раздавали бы свои НСы для других хостингов. Ну и квалификация/задачи юзеров сюда же.
Тут, если я правильно понял, ещё отдача файлов идёт через PHP, а не напрямую. Соответственно, если много одновременных запросов на закачку, то и php-процессов будет много, которые будут нагружать проц/занимать память.
Там выключен кэш
Так включить его, и нагрузка снизится.
Всем добрый день! И всех с праздником Великой Победы!
Каюсь, не отвечал тут. Так уж получилось. Но очередной военный праздник опять привел к предупреждению от хостера. В общем, проблему надо решать.
Да не ребят, я посмотрел там и БД и запросы. Там выключен кэш т.е. идёт по 350-400 запросов к БД. В основном затупы при записи сессии, как принято у джумлы это делается в БД. Я сделал таблицу MEMORY, но что-то хостеру вообще попалам на это.
Перевод таблицы с сессиями в MEMORY привел к появлению на сайте ошибки такого плана Error: Failed to start application: Error starting the session в связи с тем, что допустимый объем MEMORY регулируется параметром max_heap_table_size, ныне равным 32 Мб. При достижении данного значения появлялась указанная ошибка. Пришлось вернуть стандартный тип для таблицы _session - InnoDB.
Стандартный кэш отключен в связи с тем, что на сайте перестает работать плеер на страницах с песнями, альбомами и исполнителями. Может еще что-то отваливается, не проверял.
Спринтхост.
Если бы могли выполнить самостоятельно, то не задавали бы этот вопрос.
И 144145 запроса в сутки – это "ничто" в плане запросов к базе данных. Надо анализировать ситуацию и искать причину.
Вы могли бы взяться за диагностику данной проблемы?
Выложу крайний ответ хостера. 7 мая они прислали предупреждение о превышении лимита ресурсов. Я попросил продиагностировать и указать причины.
Одним из факторов такого большого количества обращений является то, что каждый запрос к страницам сайта генерирует множество дополнительных. При обращении к главной странице сайта генерируется порядка 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 строк. В эту таблицу уже добавлены необходимые индексы, к полям участвующим в запросе, однако из-за параметров запроса они не используются, потому происходит обход такого большого количества строк.
В данном случае рекомендуем изменить запрос с учётом добавленных в базу данных индексов.
Помимо этого рекомендуем настроить кеширование на вашем сайте, чтобы последующие запросы к страницам сайта не обрабатывались ещё раз, создавая нагрузку на аккаунте, а отдавались уже готовые из кеша.
Я понимаю, что сайту требуется определенная оптимизация, она никогда не проводилась. Но в данной ситуации надо решить вопрос с хостером - в нем это дело и смена решит текущую проблему или надо как можно быстрее проводить оптимизацию!
превью картинки надо создавать единожды, и а дальше отдавать уже ранее сгенерированное изображение.
По поводу запроса нужно убрать из запроса ORDER BY RAND()