- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Маркетинг для шоколадной фабрики. На 34% выше средний чек
Через устранение узких мест
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Плагин SP Thumbnail используется всего для нескольких изображений (их не больше десятка) с определенным классом на определенных страницах.
Я не знаю, почему они пишут, что эскизы всех изображений на сайте генерируются этим плагином.
Основная часть изображений - это фото исполнителей и обложки альбомов разных размеров, добавленных через основной компонент - Music Collection. Возможно, именно он генерирует каждый раз превью картинок.
К сожалению, знаний для этого не хватает.
Я не знаю, почему они пишут, что эскизы всех изображений на сайте генерируются этим плагином.
Основная часть изображений - это фото исполнителей и обложки альбомов разных размеров, добавленных через основной компонент - Music Collection. Возможно, именно он генерирует каждый раз превью картинок.
К сожалению, знаний для этого не хватает.
Этот запрос действительно ужасный!
Можно его переделать типа этого:
SELECT s.*, al.name AS album_name, al.image, ar.artist_name
FROM (SELECT * FROM `v0ecf_muscol_songs` ORDER BY RAND() LIMIT 5) 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
Сначала выбрать 5 случайных песен, а потом уже к ним подтягивать другие данные.
В остальном надо код смотреть, что ещё можно поправить.
слишком много подключений стилей и скриптов файлов.
Сначала выбрать 5 случайных песен, а потом уже к ним подтягивать другие данные.
В остальном надо код смотреть, что ещё можно поправить.
А я бы лучше сделал по другому. Так как RAND() запросы очень тяжелые для оптимизатора, и если представить что например в таблице soft delete pattern, то проще вытащить последний ID таблицы и выбрать сколько надо случайных ID при помощи генерации чисел на самом php, проц сделает это быстро, а фильтрация по primary будет колоссальной.
---------- Добавлено 20.05.2020 в 02:15 ----------
слишком много подключений стилей и скриптов файлов.
На сколько я понял, выясняем нагрузку на хостинг. Статика вряд ли как то нагружает хостера, если конечно это реально статика.
да я писю плохо а четаю хорошо:
Одним из факторов такого большого количества обращений является то, что каждый запрос к страницам сайта генерирует множество дополнительных.
а вообще трудно искать чернуб кошку в темной комнате (если ее там нет)
[инфы нет и просто толоченье воды в кадке]
слишком много подключений стилей и скриптов файлов.
Кто их отдает Apache или nginx, ещё вопрос?
Кто их отдает Apache или nginx, ещё вопрос?
Да нет там вопроса, статику там отдаёт openresty то есть nginx
Да, возможно, они ужасные. Но все проблемные запросы, на которые жалуется хостер, создаются компонентом для Joomla под названием Music Collection.
Вот, кстати, из последней диагностики (на День ПВ опять был заблокирован):
Самым ресурсоемким является запрос к таблице 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 сложнее.
ДСмена хостера может помочь? Или переезд на VPS/VDS? Или чтобы Вы посоветовали в данной ситуации?
Конечно, в большинстве случаев кривизну кода можно компенсировать увеличением железа и его количества до определенного момента, а дальше либо снова платить, либо переписывать.
PS. Не пробовали уточнить, сколько будет разработать такой компонент вам отдельно? Глянул демку, там достаточно банальный CRUD по сути или там под капотом какой то гастрономических масштабов функционал?
Конечно, в большинстве случаев кривизну кода можно компенсировать увеличением железа и его количества до определенного момента, а дальше либо снова платить, либо переписывать.
PS. Не пробовали уточнить, сколько будет разработать такой компонент вам отдельно? Глянул демку, там достаточно банальный CRUD по сути или там под капотом какой то гастрономических масштабов функционал?
Нет, не спрашивал. Но пару лет назад ценник на внесение незначительных правок в код был от 100 евро.
Функционал прост: есть возможность добавить исполнителя, к этому исполнителю добавить альбомы, в альбомы - песни. Также есть поиск по жанрам, тегам и т.д. + в сочетании с другим компонентам выводить статистику (самые популярные песни и т.п.).