Пишу приложение на django.
Стек такой : nginx->gunicron->django->pgsql

Решил померить скорость, — создал view, который из get параметров берет id, ищет в базе объект(18 полей) по первичному ключу и создает другой обобьет (23 поля) связанный с найденным через FK

При этом получаю(wget) 0.03 сек на запрос. А это много.


Начинаю профилировать через консоль:

In [1]: import billing.views as v
In [2]: from django.test.client import RequestFactory

In [3]: v.TakeTest(RequestFactory().get(path="/taketest/?code=1&msisdn=123123")).serialize()
Out[3]: b'Content-Type: text/html; charset=utf-8\r\n\r\nOk 0.05739855766296387'

In [4]: v.TakeTest(RequestFactory().get(path="/taketest/?code=1&msisdn=4231421")).serialize()
Out[4]: b'Content-Type: text/html; charset=utf-8\r\n\r\nOk 0.008865118026733398'

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

Как мне сделать так, чтобы эту скорость я наблюдал не только в консоли?

Здравствуйте, Kir., Вы писали:

K> Как мне сделать так, чтобы эту скорость я наблюдал не только в консоли?

Попробуй разделить тест на 2/4 части. В перовой не использовать базу, а подставить из заглушки заранее заданные значения (это будет производительность django, при чем на холодном и горячем кэше во второй и последующий запросы). Во второй части делать запрос в БД на холодном и горячем кэше (это будет соответствующая производительность связки django-база).

Отсюда будет более понятно куда двигаться дальше.

Здравствуйте, Anton Batenev, Вы писали:

AB>Здравствуйте, Kir., Вы писали:

K>> Как мне сделать так, чтобы эту скорость я наблюдал не только в консоли?

AB>Попробуй разделить тест на 2/4 части. В перовой не использовать базу, а подставить из заглушки заранее заданные значения (это будет производительность django, при чем на холодном и горячем кэше во второй и последующий запросы). Во второй части делать запрос в БД на холодном и горячем кэше (это будет соответствующая производительность связки django-база).

AB>Отсюда будет более понятно куда двигаться дальше.

Уже сделал.
Тормозит именно запрос к базе. Если из консоли вызывать, то первая вставка ~0.02, а последующие вставки ~0.002. (и это с коммитом)
А если через веб, то каждая всякая получается как первая т.е. по 0.02.

Я полагал что джанго поддерживает соединение с базой, а оказывается есть параметр, — https://docs.djangoproject.com/en/1.8/ref/settings/#conn-max-age

Выставил его, — ситуация не изменилась.

Здравствуйте, Anton Batenev, Вы писали:

AB>Здравствуйте, Kir., Вы писали:
Уф, победил.

pgsql по умолчанию надежён,а джанго генерирует коммит после каждого чиха.
Под чутким руководством http://stackoverflow.com/questions/9407442/optimise-postgresql-for-fast-testing отключил synchronous_commit и жизнь наладилась.

Здравствуйте, Kir., Вы писали:

K>Уф, победил.

K>pgsql по умолчанию надежён,а джанго генерирует коммит после каждого чиха.
K>Под чутким руководством http://stackoverflow.com/questions/9407442/optimise-postgresql-for-fast-testing отключил synchronous_commit и жизнь наладилась.

Еще можно pgbouncer попробовать прикрутить.

Здравствуйте, Ops, Вы писали:

Ops>Здравствуйте, Kir., Вы писали:

Ops>Еще можно pgbouncer попробовать прикрутить.
Пишут что начиная с 1.6 появилась опция CONN_MAX_AGE и pgbouncer стал ненужен