Меню
Что нового?

MySQL cache

glukerrr

Guest
MySQL cache

Добрый день!

Сталкнулся с таким интересным вопросом. У меня сайт с достаточно большой аудиторией. Сайт содержит куча модулей php+mysql. При атаках или большом наплыве народа вылетает мускуль. Даже если он не вылетает, то загружает проц. Хочу оптимизировать это дело.

Представим стандартную start page какого-нибудь портала. Что это такое? Это как правило десять последних новостей, результат голосования ну и еще что-то типа того.. Переводя на язык SQL - это по сути несколько выборок (SELECT -запросов). Теперь давайте рассмотрим хотябы новости.. Новости обновляются ну примерно 1 раз в час, а страница с новостями грузиться ~1-2 тысячи раз в час. Итого на 1 UPDATE/INSERT для таблицы news приходится 1000 SELECTов, которые возвращают одно и тоже.

Т.о. возникает идея создания MySQL прокси - которая бы работала гораздо быстрее нежели чем постоянные выборки. Такая прокся постоянно возвращает кэш и обнуляет его если какая-то таблица(цы) обновилась(лись)

Мой вопрос такой: есть ли реализации чего-нибудь подобного? (Не вериться мне что mysql поддерживает кеширование)
 

AHTIXPICT

Новичок
Мне кажется что тут дело не в SELECT-ах
Муська и таак кеширует результаты
Дело в mysql_connect()
В любом случае при обращении к странице происходит этот самый mysql_connect() а уже потом mysql_query()
И я думаю вылетает муська именно при конекте в твоем случае

Поэтому - SIMM уже опередил меня - его пост и есть ответ на твой вопрос
 

glukerrr

Guest
Спасибо за ответы и ссылку.. Не совсем то что я имелл ввиду.

2AHTIXPICT
Я делаю так: header записываем в переменную результат mysql_connect далее is_set($db) пользуемся ей во всех модулях для mysql_query
footer: if(is_set($db)) mysql_close($db);

Вроде оптимально ? Хотя могу и ошибаться.

В статье по ссылке от SiMM я так понял, что там все завязывается на HTTP HEADER и на понятие HTML кэширования которое в проксях используется. А мне что нужно - быструю MySQL проксю.. Вот.. Которая бы сериализовывала некоторые ответы и десериализовывала когда надо...


И еще.. пожалуйста, скажите использует ли MySQL кеширование запросов по той схеме которую я написал ?
 

glukerrr

Guest
2sveta : а потому что запрос

select ip, count(*) from ips group by ip order by 'count(*)' limit 0,100; занимает очень много времени когда его несколько раз вызываешь.. (ТАБЛИЦУ НЕ МЕНЯЕМ)

-~{}~ 16.04.05 14:48:

2Фанат: сорри, не понял

-~{}~ 16.04.05 14:49:

аа.. понял.. нет.. конечно вылетает too many connections.. Я уже кол-во коннектов увеличил до предела... в итоге нагрузка на память и проц
 
Фанат

Фанат

oncle terrible
Команда форума
запрос занимает очень много времени когда его несколько раз вызываешь
Нажмите для раскрытия...
запросы надо ОПТИМИЗИРОВАТЬ.
если ты не умеешь ездить, то не надо искать форсированный движок - он тебе не поможет.

сорри, не понял
Нажмите для раскрытия...
падает у тебя база молча? Ничего не говоря?
 

AHTIXPICT

Новичок
Помему все таки с такими нагрузками надо копать в сторону HTTP - кеширования.
Тем более что как и предпологалось вылетает на стадии connect-а
 
svetasmirnova

svetasmirnova

маленький монстрик
Четвёртая версия поддерживает так:
[sql]select sql_cache ip, count(*) from ips group by ip order by 'count(*)' limit 0,100; [/sql]
 

AHTIXPICT

Новичок
svetasmirnova
запрос можно послать только после конеута, какой бы он не был (кешированый или нет)
 
svetasmirnova

svetasmirnova

маленький монстрик
AHTIXPICT
Кто бы спорил. Другое дело, что оптимизировать нужно всё, запросы в том числе: быстрее обработался - быстрее закрылся.
 

AHTIXPICT

Новичок
svetasmirnova
вот не знаю работает ли твоя конструкция:
ORDER BY 'count(*)'

Скорее всего тогда уж правильнее:
SELECT SQL_CACHE ip, count( * ) as cnt
FROM ips
GROUP BY ip
ORDER BY cnt
LIMIT 0 , 100;
 

glukerrr

Guest
света, а подскажи, что означает это слово? Мне нужна возможность запихивать результат некоторых SELECT-ов в кеш и потом брать из
если таблица не изменилась то из кеша
иначе выполнять запрос

(Кешировать все SQL запросы наверное очень дорого.. Нет?)

-~{}~ 16.04.05 15:03:

Антихрист.. COUNT(*), если он был в селекте потом можно юзать в ORDER BY сли его заключить в кавычки
 

SiMM

Новичок
> а потому что запрос
> select ip, count(*) from ips group by ip order by 'count(*)' limit 0,100;
> занимает очень много времени когда его несколько раз вызываешь.. (ТАБЛИЦУ НЕ МЕНЯЕМ)
Этот запрос что, на каждой странице вызывается? Интересно, а какой в этом глубинный смысл? order by особенно. А вообще - дешевле наверно было завести таблицу вида ip count
 

glukerrr

Guest
2SiMM Я это для примера привел.. Чтобы показать, что mysql такой запрос не кэширует.. На простых запросвх не понять: из базы результат или из кэша

2Sveta спасибо, почитаю
 

SiMM

Новичок
> Я это для примера привел..
В следующий раз не приводи выдуманных примеров. Если хочешь получить нормальный ответ на свой вопрос.
 

Sad Spirit

мизантроп (Старожил PHPClub)
Команда форума
Автор оригинала: glukerrr
Антихрист.. COUNT(*), если он был в селекте потом можно юзать в ORDER BY сли его заключить в кавычки
Нажмите для раскрытия...
Сдаётся мне, что не в те кавычки ты его заключаешь: сортировка пойдёт по строке 'count(*)', что достаточно бесполезно.
 

glukerrr

Guest
Ты не прав.. Смотри, у меня есть таблица аля LOG в нее заносятся ip адреса посетителей, время и т.п.
Иногда хочется посмотреть с каких адресов идет больше всего запросов.. Как это сделать? Например составить TOP-100 таких ip адресов ?
Я составляю такой запрос:
Код: 
$query= "SELECT ip, COUNT(*) FROM log GROUP BY ip ORDER BY 'COUNT(*)' DESC  LIMIT 0 , 100";
Я получаю к примеру следующее (первые 20)
Код: 
Connects      IP(s)
------------------------
6038	69.11.50.242
5256	219.157.106.129
4850	219.157.106.75
3983	220.196.252.34
2976	212.179.236.3, 212.179.236.3
2520	221.200.24.220
2411	207.248.240.119
2283	81.195.12.158
2057	202.114.150.131
1922	221.229.233.251
1802	218.24.111.83
1535	83.237.9.10
1530	83.237.9.25
1522	218.24.110.58
1514	222.140.195.106
1482	83.237.9.70
1442	128.1.21.121, 193.252.243.180, 193.252.242.61
1420	83.237.9.14
1348	134.159.124.202
1157	218.24.72.92
 
Войдите или зарегистрируйтесь для ответа.
Сверху