организация кэширования

[Alexander Pugachev]

Привет.
Любите ли вы кэширование так, как люблю его я?
Я вот добавляю в приложения файлики caching.py. Там код, который
вызывается из вьюшек, инвалидирующий код и назначение вызова
инвалидирующего кода сигналам.
Кто как организует кэширование?

[Alex Koshelev]

Я так [1]. Но и с caching.py тоже в одном из проектов.

Эх побыстрее бы сигналы отрефакторили, чтобы жить стало веселее...:)

[1]: http://webnewage.org/post/2008/3/9/keshirovanie-invalidatsiya-signalami-trapeza/

On Jul 9, 12:20 pm, "Alexander Pugachev"

[spanasik]

Привет !

> Любите ли вы кэширование так, как люблю его я?

А то ! :-)

> Я вот добавляю в приложения файлики caching.py. Там код, который
> вызывается из вьюшек, инвалидирующий код и назначение вызова
> инвалидирующего кода сигналам.
> Кто как организует кэширование?

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

А как правильно ?

У меня такая проблема, что при первом обращении к вьюхе выполняется
много одинаковых sql запросов, порядка 200.
Как победить - не нашёл, потому что не могу отследить, откуда идут
запросы. Очень много моделей, да практически все, с ForeignKey,
плюс с ContentTypes, и поэтому там чёрт ногу сломит, как отследить,
откуда запросы идут, блин. В общем, я 2 дня пробился, только кэш смог
добавить,
чтобы при последующих обращениях к функциям данные читались из кеша.
Как в первый раз это откешировать на уровне query.py - не нашёл.
Есть один модуль где-то на блогах видел, только он под 0.96, с транком
не пашет, а ковырять времени не было, нужен результат.

Есть какой-нибудь модуль, чтобы кешировал SQL ?

С уважением, Стас

[Alexander Pugachev]

Правильно вроде использовать джанговый кэш. Который на странице
документации под ссылкой Caching.
Тогда закэшированные данные сохранятся даже после перезапуска
сервера, а также будут доступны в других питоновых процессах вашего
сайта. А то получается, что у вас если несколько процессов, то в
каждом свой кэш.
Посмотреть что там у вас за SQL выполняется можно, импортировава
connection из django.db. У него есть атрибут, который хранит
вызывавшийся SQL.

9 июля 2008 г. 15:29 пользователь spanasik <span...@gmail.com> написал:

[Alexander Pugachev]

Хорошая штука, только мне не походит. У меня инвалидация должна
делаться сразу по нескольким ключам.
Ну, то есть если ваши последние пять постов: последние пять
постов-полное содержание, последние пять постов-тизер и тп.

9 июля 2008 г. 13:23 пользователь Alex Koshelev <daev...@gmail.com> написал:

[Alex Koshelev]

Так дело в том, что количество ключей для инвалидации не имеет значения. Можно в один обработчик сигнала повесить инвалидацию всех ключей, а можно для каждого ключа свой обработчик (так, как раз, в моем примере). Да, второй вариант чуть более накладный, но как только передалают в джанге сигналы, то будет совсем минимальная цена.

2008/7/9 Alexander Pugachev <alexander...@gmail.com>:

[spanasik]

Привет, Александр !

> Правильно вроде использовать джанговый кэш. Который на странице
> документации под ссылкой Caching.
> Тогда закэшированные данные сохранятся даже после перезапуска
> сервера, а также будут доступны в других питоновых процессах вашего
> сайта. А то получается, что у вас если несколько процессов, то в
> каждом свой кэш.

Да, я про это не подумал, обычно больше одного процесса не использую.
Учту на будущее.

> Посмотреть что там у вас за SQL выполняется можно, импортировава
> connection из django.db. У него есть атрибут, который хранит
> вызывавшийся SQL.

Я этот атрибут использую, чтобы посмотреть количество запросов. Дело
не в этом. Дело в том, что я не могу найти место, откуда идут
запросы.
В connection этой информации нету, к сожалению.

С уважением, Стас

[Artiom Diomin]

django.db.connection.queries заполняется выполненными запросами только
если DEBUG = True

[Alex Koshelev]

Это симптомы того, что вы пренебрегаете `select_related`

2008/7/9 spanasik <span...@gmail.com>:

[spanasik]

Привет, Артём !

> django.db.connection.queries заполняется выполненными запросами только
> если DEBUG = True

> > В connection этой информации нету, к сожалению.

Само собой. Я пишу про то, что в connection нету трассы до места из
которого был использован query.py.
Т.е., строки кода, которая при выполнении в результате сгенерировала
запрос к БД.

С уважением, Стас

[spanasik]

Привет !

> Это симптомы того, что вы пренебрегаете `select_related`

Был бы рад, но весь код вдоль и поперёк тестировал и с select_related,
и без него. Причём, без него работает быстрее :-)
Не знаю, может быть особенность проекта такая, но с select_related,
если его использовать везде вместо all(), получается ерунда.
Поэтому использую ограниченно, не больше, чем нужно.

С уважением, Стас

[Alex Koshelev]

А зачем `вместо` all, надо `с`.

2008/7/9 spanasik <span...@gmail.com>:

[Alexander Pugachev]

Тут вот какое дело. Есть у меня сигнал, один. Если он получен, то надо
инвалидировать несколько элементов кэша. Повесить несколько
обработчиков сигнала через trigger я не могу, так? Суфикс тоже
принимается один. А мне нужно, чтобы, к примеру, в trigger['suffix'] у
меня принимали итерэйбл, и инвалидировали всё получившиеся ключи.
Я может не дочитываюсь в коде, но вроде не делает пантеоновский кэш этого?

9 июля 2008 г. 15:51 пользователь Alex Koshelev <daev...@gmail.com> написал:

[spanasik]

Привет !

> А зачем `вместо` all, надо `с`.

select_related().all() ? :-)

Я как раз 'с' и использую, выжал из него максимум, дальше упёрлось в
то, о чём я писал.
Т.е. что я хочу сказать - гадать, поможет в каком-либо случае
select_related, имхо, неправильно.
По идее в query.py должен быть хотя бы callback, чтобы я мог
записывать трассу до места, откуда сгенерирован запрос, иначе всё
сводится к методу научного тыка и профилированию. По-правильному
должно быть что-то, чтобы я мог посмотреть, откуда генерятся запросы,
всё в это упирается, в конечном счёте.
Чтобы меньшие объёмы кешировать, нужно знать слабые места, а с этим
сейчас трудновато пока.

С уважением, Стас

[Alex Koshelev]

Нет. Гадать не надо. `select_related` очень хорошо помогает, когда в модели есть ForeignKey/OneToOneField и чтобы при обращении к ним не хитить базу каждый раз. Модели с такого рода полями известны и всегда можно оптимизировать выборки к ним, подобрав нужные поля к для `select_related`.

Плюс, запросы сами по себе из воздуха не берутся И если вы автор кода, то всегда сможете определить где они происходят.

А вы же боретесь с ветряными мельницами держа в руках гнутые грабли.

2008/7/9 spanasik <span...@gmail.com>:

[Alex Koshelev]

Да. Правильно. Вы инвалидируете скопом кучу всего без разбора. Но почему для этой кучи тогда не сделать один ключ и не кешировать разом?
Я же только по мере надобности. Это разные подходы что ли.

2008/7/9 Alexander Pugachev <alexander...@gmail.com>:

[spanasik]

Привет !

> Плюс, запросы сами по себе из воздуха не берутся И если вы автор кода, то
> всегда сможете определить где они происходят.

Я, пожалуй, с этим не соглашусь. Код (мой) не уровня blog example, и
запросы генерируются динамически на основе анализа полей моделей.
Модели используют много ForeignKey + ForeignKey на ContentType, и
какая в каждый конкретный момент времени грузится, и что именно из неё
читается, я не могу сказать, читая свой код, это только во время
выполнения видно может быть (теоретически).

> А вы же боретесь с ветряными мельницами держа в руках гнутые грабли.

Ну, если у вас 2-4 миллиона тяжёлых записей, и туда select_related
употребить, может получиться нехорошо. Методы борьбы выбираются в
каждом конкретном случае.
В данном случае из шутки не понял, как именно нужно бороться, потому
что select_related не гроаль, не догма, не серебрянная пуля и не
"нашё фсё" :-)

С уважением, Стас

[Alex Koshelev]

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

2008/7/9 spanasik <span...@gmail.com>:

[Yuri Baburov]

хе-хе, ну это-то дело 10 минут работы.

просто добавь что-нибудь типа
try:
1/0
except Exception, e:
connection.queries[-1]["code"] = format(e)

к тому месту, где заполняется connection.queries

2008/7/9 spanasik <span...@gmail.com>:

--
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com

[spanasik]

Привет, Юрий !

> хе-хе, ну это-то дело 10 минут работы.
>
> просто добавь что-нибудь типа
> try:
> 1/0
> except Exception, e:
> connection.queries[-1]["code"] = format(e)
>
> к тому месту, где заполняется connection.queries

Спасибо за хорошую идею !

С уважением, Стас

[Alexander Pugachev]

оригинальная организация кэширования :)
замусорили топик, ироды

9 июля 2008 г. 19:26 пользователь Yuri Baburov <bur...@gmail.com> написал:

[spanasik]

Привет, Александр !

> оригинальная организация кэширования :)
> замусорили топик, ироды

Посыпаю голову пеплом :-) Постеснялся новый топик по своей теме
открывать, ошибка.

С уважением, Стас