Дикие тормоза в админке
Zodiak
пользователя.
Страница открывается 3 секунды. При этом делается 36 запросов на
пустой джанге.
На django-cms страница открывается 5 секунд, при это делается ~150
запросов к БД.
Просто ЖЕСТЬ!!! Самое странное что работаю с Django больше года, а
заметил только сейчас.
У меня одного такое?
Django 1.1.1, БД SQLite.
Ниже то что удалось выдрать из django-debug-toolbar.
Вот собственно дублирующиеся запросы:
SELECT "auth_permission"."id", "auth_permission"."name",
"auth_permission"."content_type_id", "auth_permission"."codename" FROM
"auth_permission" INNER JOIN "django_content_type" ON
("auth_permission"."content_type_id" = "django_content_type"."id")
ORDER BY "django_content_type"."app_label" ASC,
"auth_permission"."codename" ASC
А вот стек вызовов:
Line Method File
226 wrapper /home/alex/Develop/Django/test/env/lib/python2.6/site-
packages/django/contrib/admin/options.py
186 inner /home/alex/Develop/Django/test/env/lib/python2.6/site-
packages/django/contrib/admin/sites.py
873 change_view /home/alex/Develop/Django/test/env/lib/python2.6/
site-packages/django/contrib/admin/options.py
590 render_change_form /home/alex/Develop/Django/test/env/lib/
python2.6/site-packages/django/contrib/admin/options.py
231 render /home/alex/Develop/Django/test/env/lib/python2.6/site-
packages/django/contrib/admin/widgets.py
36 render /home/alex/Develop/Django/test/env/lib/python2.6/site-
packages/django/contrib/admin/widgets.py
9 {% if field.is_checkbox %}
10 {{ field.field }}{{ field.label_tag }}
11 {% else %}
12 {{ field.label_tag }}{{ field.field }}
13 {% endif %}
14 {% if field.field.field.help_text %}<p
class="help">{{ field.field.field.help_text|safe }}</p>{% endif %}
15 </div>
Zodiak
Yuri Baburov
Потом не смотрел. Как-то была проблема в том, что request.user
грузился каждый раз и его permissions тоже грузились каждый раз.
Но чтобы страница открывалась 3 секунды... у тебя база данных далеко/тормозная?
2010/3/15 Zodiak <desz...@gmail.com>:
--
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com
Alex
рендриться форма для редактирования пользователя, идет обращение к
полям:
> 9 {% if field.is_checkbox %}
> 10 {{ field.field }}{{ field.label_tag }}
> 11 {% else %}
> 12 {{ field.label_tag }}{{ field.field }}
> 13 {% endif %}
> 14 {% if field.field.field.help_text %}<p
> class="help">{{ field.field.field.help_text|safe }}</p>{% endif %}
> 15 </div>
которые не загружены. Поэтому при обращении к полю идет обращение к
одной и той же таблице, но с разным id. Всего таких обращений около
30 на чистой джанге.
Ставил 1.0.4 и 1.2бета - то же самое.
ОЧЕНЬ ОЧЕНЬ не хочется из-за такой фигни самому писать бэкенд...
Ведь оставить такие тормоза нельзя.
--
С уважением,
Alex mailto:DesZ...@gmail.com
Yuri Baburov
> БД локальная - SQLite. Да и дело не базе. Дело в том, что когда
> рендриться форма для редактирования пользователя, идет обращение к
> полям:
>> 9 {% if field.is_checkbox %}
>> 10 {{ field.field }}{{ field.label_tag }}
>> 11 {% else %}
>> 12 {{ field.label_tag }}{{ field.field }}
>> 13 {% endif %}
>> 14 {% if field.field.field.help_text %}<p
>> class="help">{{ field.field.field.help_text|safe }}</p>{% endif %}
>> 15 </div>
>
> которые не загружены. Поэтому при обращении к полю идет обращение к
> одной и той же таблице, но с разным id. Всего таких обращений около
> 30 на чистой джанге.
> Ставил 1.0.4 и 1.2бета - то же самое.
> ОЧЕНЬ ОЧЕНЬ не хочется из-за такой фигни самому писать бэкенд...
> Ведь оставить такие тормоза нельзя.
Почему?
Alex
Вы писали 15 марта 2010 г., 17:37:54:
Научный руководитель придушит. Он в курсе что больше всего
производительности крадут: межпроцессовое взаимодействие (в т.ч.
получение данных из БД), динамическое выделение памяти и по т.д.
по уменьшению. А в дипломе я должен по максимуму показать свои знания
и умения...
Кстати пробовал на мускуле (вдруг sqlite что-то не поддерживает) - те же тормоза
Mikhail Gusarov
Twas brillig at 18:20:32 15.03.2010 UTC+03 when desz...@gmail.com did gyre and gimble:
A> Научный руководитель придушит. Он в курсе что больше всего
A> производительности крадут: межпроцессовое взаимодействие (в т.ч.
A> получение данных из БД), динамическое выделение памяти и по т.д. по
A> уменьшению.
Какой забавный (если не сказать сильнее) научный руководитель.
--
http://fossarchy.blogspot.com/
Alex
Вы писали 15 марта 2010 г., 19:06:00:
Лучше по теме что-нибудь скажите, без обид.
Yuri Baburov
который, исходя из ваших слов, есть корень зла.
Производительность имела смысл в 70х, когда компьютеры были медленные.
Сейчас наибольший смысл в производстве имеет экономия времени
программистов различными способами, потому что расходы на коммуникацию
между ними, синдром NIH и без того высокая стоимость изменения кода
делают практически невозможными большие проекты в разумные сроки.
А те, кто в 2010м беспокоятся о производительности, до сих пор пишут в
одиночку на ассемблере, а не занимаются веб-программированием.
Потому что иначе они с ума сойдут, думая о том, как неэффективно
генерируются страницы в django. Дело ведь даже не в памяти или в
межпроцессной коммуникации. Главный вопрос, кому нужны эти
дополнительные уровни абстракции, которые время генерации страницы от
0.0001 секунды (основное ограничение будет тогда скорость сети,
скажем, 100 мбит/сек) превращают в 3 секунды? Python как большой
тормоз, веб-сервер, WSGI, Middleware, Auth Backend, Context Processor,
Template (и язык шаблонов), Form, Model, SQL, база данных со своими
уровнями оптимизации и кэширования запросов? Может, лучше написать
приложение на С, которое будет просто раздавать статические файлы из
памяти, и иногда, когда нужно, генерировать динамические файлы на
основе данных в памяти? Ведь так будет существенно быстрее.
Так и заясните своему научному руководителю. Заодно приведите пример
Facebook, который удерживает лидирующие позиции на рынке, в том числе,
за счёт применения жутко неэффективного языка php!
Надеюсь, вы-то сами хоть понимаете, зачем дополнительные уровни
абстракции нужны?
А то, видимо, дипломированный специалист в вашем лице будет уметь
выложить стенку из 3х кирпичей, и не представлять, чем его действия
_принципиально_, подчёркиваю, _принципиально_, отличаться от
строительства дома.
2010/3/15 Alex <desz...@gmail.com>:
--
Yuri Baburov
2010/3/15 Yuri Baburov <bur...@gmail.com>:
Stanislav Panasik
> Так и заясните своему научному руководителю. Заодно приведите пример
> Facebook, который удерживает лидирующие позиции на рынке, в том числе,
> за счёт применения жутко неэффективного языка php!
Маленькое замечание - они не чистый PHP используют, у них там транслятор
PHP (в C++ по-моему), т.е. код бинарный в результате.
По теме полностью согласен с Юрием - преждевременная оптимизация есть
первейшее зло. Рекомендую к прочтению книгу "Искусство программирования
для Unix", всего лишь однократное её прочтение спасает от многих болячек
(даже если вы пишете исключительно на дотнетах под винду).
С уважением, Стас
Mikhail Gusarov
Twas brillig at 19:29:15 15.03.2010 UTC+02 when bur...@gmail.com did gyre and gimble:
YB> если вы не читали -- http://www.rsdn.ru/article/career/BrickScience.xml
Перевод кривой. В оригинале гораздо лучше.
--
http://fossarchy.blogspot.com/
Yuri Baburov
> Привет !
>
>> Так и заясните своему научному руководителю. Заодно приведите пример
>> Facebook, который удерживает лидирующие позиции на рынке, в том числе,
>> за счёт применения жутко неэффективного языка php!
>
> Маленькое замечание - они не чистый PHP используют, у них там транслятор PHP
> (в C++ по-моему), т.е. код бинарный в результате.
> По теме полностью согласен с Юрием - преждевременная оптимизация есть
> первейшее зло. Рекомендую к прочтению книгу "Искусство программирования для
> Unix", всего лишь однократное её прочтение спасает от многих болячек (даже
> если вы пишете исключительно на дотнетах под винду).
Ага. И добавить товарищу дипломнику в список литературы!
Stanislav Panasik
Ну, учитывая, что у них сотни миллионов юзеров, возможно, для них это
было весьма и весьма.
Mikhail Gusarov
Twas brillig at 19:46:18 15.03.2010 UTC+02 when bur...@gmail.com did gyre and gimble:
>> Маленькое замечание - они не чистый PHP используют, у них там транслятор PHP
>> (в C++ по-моему), т.е. код бинарный в результате.
В эмбеддеде и энтерпрайзе ресурсоёмкость опять становится экономическим
вопросом.
--
http://fossarchy.blogspot.com/
Evgeniy Kryukov
----------------------------------------------
С уважением, Евгений Крюков
Arcady Chumachenko
Добрый день!30 (или даже 300) запросов по первичному ключу для нормальной реляционной базы плевое дело.Вот, к примеру, скорость обработки запросов на бесплатной Oracle XE на слабом ноутбуке под Ubuntu 9.10 с 1 гигом оперативы:
Аркадий Чумаченко // Arcady Chumachenko
веб-проекты // web development
icq is no more, use google talk please
cell +7 911 701-0626
www http://ilvar.ru
Mikhail Gusarov
Twas brillig at 14:40:09 15.03.2010 UTC+03 when doct...@gmail.com did gyre and gimble:
EK> Другой вопрос, что SQLlite - это не совсем то, что требуется для
EK> сколь-нибудь заметной нагрузки.
Фигня какая.
$ time for i in `seq 1 300`; do echo "select * from user_objects where OBJECT_ID = $i;"; done | sqlite3 foobar.sqlite >/dev/null
0.25s user 0.01s system 90% cpu 0.287 total
$
--
http://fossarchy.blogspot.com/
Zodiak
django. Но в ситуации, которую я описал проблема в другом.
Можно до потери пульса спорить на тему "на сколько плевое дело для БД
30 запросов", но речь о другом:
вместо 30 запросов к разным строчкам одной таблицы (в нашем случае к
JOIN-у нескольких), намного проще и дешевле (для производительности)
сделать один запрос, который вернет все что нам нужно за раз.
Я открыл это обсуждение с одной единственной целью: узнать есть ли
подобные симптомы у других, и если есть найти источник бага и
исправить.
Arcady Chumachenko, в debug toolbar время выполнения запросов я не
смотрел, но страница генерится секунды 3-4. Таблицы создавались syncdb-
ом, со всеми индексами.
> 2010/3/15 Alex <deszod...@gmail.com>:
>
>
>
> > Здравствуйте, Yuri.
>
> > Вы писали 15 марта 2010 г., 17:37:54:
>
> >> 2010/3/15 Alex <deszod...@gmail.com>:
Dmitry Shevchenko
Best regards, Dmitry Shevchenko.
Arcady Chumachenko
Arcady Chumachenko, в debug toolbar время выполнения запросов я не
смотрел, но страница генерится секунды 3-4. Таблицы создавались syncdb-
ом, со всеми индексами.
Alex Koshelev
---
Alex Koshelev
2010/3/15 Arcady Chumachenko <arcady.ch...@gmail.com>:
Zodiak
Выключил debug-toolbar и ... вуаля! Вместо 3-4 секунд страница
открылась за одно мгновение!
Хотя я все еще подозреваю что запросов делается много, но то что это
не заметно уже радует.
Буду презнателен, если кто подскажет как с выключенным тулбаром
посмотреть какие запросы делаются к БД.
On 15 мар, 22:08, Alex Koshelev <daeva...@gmail.com> wrote:
> Да. и дебаг-тулбар не забудьте выключить.
> ---
> Alex Koshelev
>
> 2010/3/15 Arcady Chumachenko <arcady.chumache...@gmail.com>:
>
>
>
> > 2010/3/15 Zodiak <deszod...@gmail.com>
Alex Koshelev
сам по себе довольно медленно отрисовывает свой интерфейс с данными.
А вообще в дебаге все запросы логируются в конекшенах к базам. В
документации рассказано как их получить.
---
Alex Koshelev
2010/3/15 Zodiak <desz...@gmail.com>:
Arcady Chumachenko
А теперь начинается уличная магия...
Выключил debug-toolbar и ... вуаля! Вместо 3-4 секунд страница
открылась за одно мгновение!
Хотя я все еще подозреваю что запросов делается много, но то что это
не заметно уже радует.
Буду презнателен, если кто подскажет как с выключенным тулбаром
посмотреть какие запросы делаются к БД.
Alex Koshelev
---
Alex Koshelev
2010/3/15 Arcady Chumachenko <arcady.ch...@gmail.com>:
Oleg Komkov
> По теме полностью согласен с Юрием - преждевременная оптимизация есть
> первейшее зло. Рекомендую к прочтению книгу "Искусство программирования
> для Unix", всего лишь однократное её прочтение спасает от многих болячек
> (даже если вы пишете исключительно на дотнетах под винду).
Для равновесия предлагаю прочитать "Джоэл о программировании", а именно
главу "Дырявые абстракции"
Stanislav Panasik
>> По теме полностью согласен с Юрием - преждевременная оптимизация есть
>> первейшее зло. Рекомендую к прочтению книгу "Искусство программирования
>> для Unix", всего лишь однократное её прочтение спасает от многих болячек
>> (даже если вы пишете исключительно на дотнетах под винду).
>
> Для равновесия предлагаю прочитать "Джоэл о программировании", а именно
> главу "Дырявые абстракции"
Прочитал. В чём же противоречие между книгой "Искусство программирования
для Unix", в которой подробнейшим образом говорится о базовых,
основополагающих вещах, и главой из другой книги, где говорится, что
помимо абстракций необходимо знать базовые вещи ? Поясните, пожалуйста.
С уважением, Стас
Oleg Komkov
> Прочитал. В чём же противоречие между книгой "Искусство программирования
> для Unix", в которой подробнейшим образом говорится о базовых,
> основополагающих вещах, и главой из другой книги, где говорится, что
> помимо абстракций необходимо знать базовые вещи ? Поясните, пожалуйста.
Собственно предложение прочесть относилось не столько к вашему
сообщению, сколько к сообщения Юрия и Михаила:
> Надеюсь, вы-то сами хоть понимаете, зачем дополнительные уровни
> абстракции нужны?
> А то, видимо, дипломированный специалист в вашем лице будет уметь
> выложить стенку из 3х кирпичей, и не представлять, чем его действия
> _принципиально_, подчёркиваю, _принципиально_, отличаться от
> строительства дома.
Джоэл говорит о том, что все абстракции имеют дыры. И их приходится
учитывать. Так что называть
> Какой забавный (если не сказать сильнее) научный руководитель.
за желание уменьшить количество межпроцессовых вызов, мягко говоря,
странно.
Mikhail Gusarov
Twas brillig at 16:41:46 17.03.2010 UTC+06 when oko...@gmail.com did gyre and gimble:
OK> Джоэл говорит о том, что все абстракции имеют дыры. И их приходится
OK> учитывать. Так что называть
>> Какой забавный (если не сказать сильнее) научный руководитель.
OK> странно.
Дырявые абстракции и IPC никак не связаны.
--
http://fossarchy.blogspot.com/
Stanislav Panasik
> Собственно предложение прочесть относилось не столько к вашему
> сообщению, сколько к сообщения Юрия и Михаила:
Тогда очень извиняюсь :-)
UKD PHY
Алексей С.
Прошло 7 лет. Джанга всё так же необъяснимо тупит. Страницы открываются 2 секунды на локальной машине.
--
Вы получили это сообщение, поскольку подписаны на группу "Django russian".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес django-russian+unsubscribe@googlegroups.com.
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.
Yuri Baburov
2017-05-13 5:56 GMT+07:00 UKD PHY <code...@gmail.com>:
> Прошло 7 лет. Джанга всё так же необъяснимо тупит. Страницы открываются 2
> секунды на локальной машине.
>
> Вы получили это сообщение, поскольку подписаны на группу "Django russian".
> Чтобы отменить подписку на эту группу и больше не получать от нее сообщения,
> отправьте письмо на электронный адрес
--
Best regards, Yuri V. Baburov, Skype: yuri.baburov
UKD PHY
суббота, 13 мая 2017 г., 12:59:24 UTC+3 пользователь Yuri Baburov написал:
Evgeny Myzgin
Тогда причина не в Django ;) загляните в документацию.
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес django-russian+unsubscribe@googlegroups.com.
Max Morozov
--
Yuri Baburov
UKD PHY
Вы получили это сообщение, поскольку подписаны на одну из тем в группе "Django russian".
Чтобы отменить подписку на эту тему, перейдите по ссылке https://groups.google.com/d/topic/django-russian/oeWqwyzD-jg/unsubscribe.
Чтобы отменить подписку на эту группу и все ее темы, отправьте письмо на электронный адрес django-russian+unsubscribe@googlegroups.com.
