- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
В 2023 году Google заблокировал более 170 млн фальшивых отзывов на Картах
Это на 45% больше, чем в 2022 году
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
ТС: в чем сложность проанализировать свои же запросы к MySQL?
Если хостинг действительно гонит, это будет видно в запросах, то что их почти нет, либо же наоборот.
Зато удалите/оптимизируете грузящий модуль сайта ;)
до 10 - это слишком мало что ли? =)
это очень много!
при отсутствии авторизации на сайте, они вообще не нужны!
должен кеш работать
а можно один join без индексов на сотню тыщщ записей..
зачем такое вообще закладывать в структуру сайта?
p.s. А магазин.. там же как... товар, характеристики-свойства, разные цены.. дерево категорий наверняка не кэшируется, брэнды.. ещё картинку нужно главную найти.. в общем, десятка легко наберётся..
тут вообще ни одного запроса к бд не надо, точнее всё уже должно быть в кеше ;)
1 - это тоже "до 10"..
всё уже должно быть в кеше
Иногда в базу дешевле сходить, чем в файловый кэш.. Иногда кэш и лежит в базе.. А "хитрые" кэши далеко не все хостинги предоставляют...
зачем такое вообще закладывать в структуру сайта?
Поди их знай этих закладчиков..
ТС: в чем сложность проанализировать свои же запросы к MySQL?
Далеко не у всех есть желание вникать.. и уж, тем более, исправлять.. особенно с постоянным снижением стоимости вычислительных ресурсов.. Что вполне уместно, особенно если учесть, что большинству таких сайтов "хайлоад" не грозит.
Иногда кэш и лежит в базе.
ну это вообще изврат!
Далеко не у всех есть желание вникать.. и уж, тем более, исправлять..
припрёт будут исправлять, иначе проблемы с пс могут возникнуть - из-за недоступности ресурса.
P.S. был у нас один клиент по недвижке, так они при добавлении/удалении любого объекта переписывали(формировали заново) xml файл на сервере всего 400-500Мб - 30мин недоступности на одну операцию :)
ни какое снижение стоимости вычислительных ресурсов, не решит проблемы криво спроектированных проектов :)
ну это вообще изврат!
Раз уж мы тут взялись оффтопить… то… чисто теоретически, если весь кэш в одной таблице, а таблица эта в памяти (в кэше СУБД), то обращение к этим страницам будет происходить быстрее, чем чтение директории/файлов. И будет менее накладно по ресурсам (I/O).
Но это в теории :)
[umka], насколько я понимаю, чтобы такое реализовать, нужно быть очень хорошим прогером и иметь свой сервер БД, а не общий :)
Собственно файл вот с таким содержанием прислали с мастерхоста:
SELECT * FROM jos_phocaguestbook_items WHERE catid = 1 AND published = 1 ORDER BY ordering DESC;
SELECT * FROM jos_phocaguestbook_items WHERE catid = 1 AND published = 1 ORDER BY ordering DESC;
SELECT * FROM jos_phocaguestbook_items WHERE catid = 1 AND published = 1 ORDER BY ordering DESC;
SELECT * FROM jos_phocaguestbook_items WHERE catid = 1 AND published = 1 ORDER BY ordering DESC;
SELECT * FROM jos_phocaguestbook_items WHERE catid = 1 AND published = 1 ORDER BY ordering DESC;
SELECT * FROM jos_phocaguestbook_items WHERE catid = 1 AND published = 1 ORDER BY ordering DESC;
SELECT * FROM jos_phocaguestbook_items WHERE catid = 1 AND published = 1 ORDER BY ordering DESC;
SELECT * FROM jos_phocaguestbook_items WHERE catid = 1 AND published = 1 ORDER BY ordering DESC;
SELECT * FROM jos_phocaguestbook_items WHERE catid = 1 AND published = 1 ORDER BY ordering DESC;
SELECT * FROM jos_phocaguestbook_items WHERE catid = 1 AND published = 1 ORDER BY ordering DESC;
Была подобная ситуация на виртуальном хостинге мастерхоста. Тоже прислали список совершенно безобидных запросов.
Вообще нагрузка от подобных одинаковых запросов, идущих пачками, очень эффективно снижается при помощи memcached, однако едва ли этот демон доступен на виртуальном хостинге.
По крайней мере, еще нужно проверить индексы.
Мой совет - уйти на VDS или на арендованный физический сервер, в зависимости от Вашего бюджета. Арендованный физический сервер позволит полностью контролировать ситуацию с нагрузкой и выполнять оптимизацию путем использования необходимых средств.
Помимо memcached для кэширования запросов к базе данных, очень рекомендую использовать nginx для быстрой отдачи статических файлов в обход апача.
Здравствуйте. Нашей компании 8 лет, мы занимаемся продажей техники, большой интернет-магазин по мелочам. Трудно было найти нормальный хостинг, чтобы хоть раз в месяц не ложился, чтобы не глючило. Два года назад нам посоветовали хостинг и удаленные рабочие столы для наших бухгалтеров. Теперь уже два года как обходимся админом хостера. Как и мне в нужный момент посоветовали: советую и вам нашего хостера.
Скайп: OptiHost. Нас обслуживает Ярослав. Очень прост в общении и ни разу не "отморозился", когда бухгалтерам или менеджеру надо что-то объяснить. Вобщем, мы благодарны что нам посоветовали, и советуем Вам.
SELECT * FROM jos_phocaguestbook_items WHERE catid = 1 AND published = 1 ORDER BY ordering DESC;
А индексы какие для таблицы jos_phocaguestbook_items ? И записей сколько?
Что скажет phpmyadmin в ответ на такое: