Дикие тормоза в админке

89 views
Skip to first unread message

Zodiak

unread,
Mar 14, 2010, 12:43:07 PM3/14/10
to Django russian
Ситуация: вхожу в админку, выбираю раздел "Пользователи", выбираю
пользователя.
Страница открывается 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

unread,
Mar 15, 2010, 5:38:56 AM3/15/10
to Django russian
Пожалуйста, посмотрите в своих проектах, есть ли у Вас такие симптомы.

Yuri Baburov

unread,
Mar 15, 2010, 5:43:45 AM3/15/10
to django-...@googlegroups.com
У меня были такие симптомы между Django 1.0 и Django 1.1.
Потом не смотрел. Как-то была проблема в том, что 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

unread,
Mar 15, 2010, 7:21:33 AM3/15/10
to 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 mailto:DesZ...@gmail.com

Yuri Baburov

unread,
Mar 15, 2010, 10:37:54 AM3/15/10
to django-...@googlegroups.com
2010/3/15 Alex <desz...@gmail.com>:

> БД локальная - 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бета - то же самое.
Я не понимаю, почему тогда идёт обращение к таблице auth_permission.

>  ОЧЕНЬ ОЧЕНЬ не хочется из-за такой фигни самому писать бэкенд...
>  Ведь оставить такие тормоза нельзя.

Почему?

Alex

unread,
Mar 15, 2010, 11:20:32 AM3/15/10
to Yuri Baburov
Здравствуйте, Yuri.

Вы писали 15 марта 2010 г., 17:37:54:


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

Кстати пробовал на мускуле (вдруг sqlite что-то не поддерживает) - те же тормоза

Mikhail Gusarov

unread,
Mar 15, 2010, 12:06:00 PM3/15/10
to django-...@googlegroups.com

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

unread,
Mar 15, 2010, 12:43:29 PM3/15/10
to Mikhail Gusarov
Здравствуйте, Mikhail.

Вы писали 15 марта 2010 г., 19:06:00:


Лучше по теме что-нибудь скажите, без обид.

Yuri Baburov

unread,
Mar 15, 2010, 1:24:39 PM3/15/10
to django-...@googlegroups.com
Ну тогда не используйте django вообще или хотя бы django.admin, именно
который, исходя из ваших слов, есть корень зла.

Производительность имела смысл в 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

unread,
Mar 15, 2010, 1:29:15 PM3/15/10
to django-...@googlegroups.com
если вы не читали -- http://www.rsdn.ru/article/career/BrickScience.xml

2010/3/15 Yuri Baburov <bur...@gmail.com>:

Stanislav Panasik

unread,
Mar 15, 2010, 1:33:47 PM3/15/10
to django-...@googlegroups.com
Привет !

> Так и заясните своему научному руководителю. Заодно приведите пример
> Facebook, который удерживает лидирующие позиции на рынке, в том числе,
> за счёт применения жутко неэффективного языка php!

Маленькое замечание - они не чистый PHP используют, у них там транслятор
PHP (в C++ по-моему), т.е. код бинарный в результате.

По теме полностью согласен с Юрием - преждевременная оптимизация есть
первейшее зло. Рекомендую к прочтению книгу "Искусство программирования
для Unix", всего лишь однократное её прочтение спасает от многих болячек
(даже если вы пишете исключительно на дотнетах под винду).

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

Mikhail Gusarov

unread,
Mar 15, 2010, 1:39:43 PM3/15/10
to django-...@googlegroups.com

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

unread,
Mar 15, 2010, 1:46:18 PM3/15/10
to django-...@googlegroups.com
2010/3/15 Stanislav Panasik <span...@gmail.com>:

> Привет !
>
>> Так и заясните своему научному руководителю. Заодно приведите пример
>> Facebook, который удерживает лидирующие позиции на рынке, в том числе,
>> за счёт применения жутко неэффективного языка php!
>
> Маленькое замечание - они не чистый PHP используют, у них там транслятор PHP
> (в C++ по-моему), т.е. код бинарный в результате.
Всего двухкратное ускорение. Непринципиально.

> По теме полностью согласен с Юрием - преждевременная оптимизация есть
> первейшее зло. Рекомендую к прочтению книгу "Искусство программирования для
> Unix", всего лишь однократное её прочтение спасает от многих болячек (даже
> если вы пишете исключительно на дотнетах под винду).

Ага. И добавить товарищу дипломнику в список литературы!

Stanislav Panasik

unread,
Mar 15, 2010, 1:49:19 PM3/15/10
to django-...@googlegroups.com
> Всего двухкратное ускорение. Непринципиально.

Ну, учитывая, что у них сотни миллионов юзеров, возможно, для них это
было весьма и весьма.

Mikhail Gusarov

unread,
Mar 15, 2010, 1:59:58 PM3/15/10
to django-...@googlegroups.com

Twas brillig at 19:46:18 15.03.2010 UTC+02 when bur...@gmail.com did gyre and gimble:

>> Маленькое замечание - они не чистый PHP используют, у них там транслятор PHP
>> (в C++ по-моему), т.е. код бинарный в результате.
YB> Всего двухкратное ускорение. Непринципиально.

В эмбеддеде и энтерпрайзе ресурсоёмкость опять становится экономическим
вопросом.

--
http://fossarchy.blogspot.com/

Evgeniy Kryukov

unread,
Mar 15, 2010, 7:40:09 AM3/15/10
to django-...@googlegroups.com
Добрый день!
30 (или даже 300) запросов по первичному ключу для нормальной реляционной базы плевое дело. 
Вот, к примеру, скорость обработки запросов на бесплатной Oracle XE на слабом ноутбуке под Ubuntu 9.10 с 1 гигом оперативы:
main@sv2> declare
  2  v_count number := 300;
  3
  4  begin
  5    for rec1 in 1..v_count
  6    loop
  7      for rec2 in (select * from user_objects t where t.OBJECT_ID = rec1)
  8      loop
  9        null;
 10      end loop;
 11    end loop;
 12  end;
 13  /

Процедура PL/SQL успешно завершена.

Затрач.время: 00:00:00.45
Как видите, время выполнения запросов малозначимо, причем это первый прогон, потом информация еще закешируется.  
Другой вопрос, что SQLlite - это не совсем то, что требуется для сколь-нибудь заметной нагрузки. Дефграгментацию базы, кстати, проводили? Помогает ускорить.
----------------------------------------------
С уважением, Евгений Крюков



2010/3/15 Alex <desz...@gmail.com>

Arcady Chumachenko

unread,
Mar 15, 2010, 2:22:24 PM3/15/10
to django-...@googlegroups.com
Евгений, не пугайте ТС, SQLite прекрасно тянет такие объемы.

Топикстартеру: debug toolbar показывает время выполнения sql-запросов, они у Вас по нескольку секунд выполняются? Таблицы создавались syncdb-ом, со всеми индексами?

2010/3/15 Evgeniy Kryukov <doct...@gmail.com>

Добрый день!
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

unread,
Mar 15, 2010, 2:23:46 PM3/15/10
to django-...@googlegroups.com

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

unread,
Mar 15, 2010, 2:58:53 PM3/15/10
to Django russian
Юрий, Вы меня не правильно поняли. Я за принципы, которые заложены в
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

unread,
Mar 15, 2010, 3:00:42 PM3/15/10
to django-...@googlegroups.com
у меня вообще 78, первые 5 к юзеру, остальные по одному на contenttype. Такие дела.
--
Best regards, Dmitry Shevchenko.



Arcady Chumachenko

unread,
Mar 15, 2010, 3:03:12 PM3/15/10
to django-...@googlegroups.com


2010/3/15 Zodiak <desz...@gmail.com>

Arcady Chumachenko, в debug toolbar время выполнения запросов я не
смотрел, но страница генерится секунды 3-4. Таблицы создавались syncdb-
ом, со всеми индексами.

Посмотрите, пожалуйста. Насчет секунд - почему-то зациклился на минутах :) значит, ищите запросы на 100+ миллисекунд.

И, кстати, объем данных там какой (количество пользователей и приложений)?
 

Alex Koshelev

unread,
Mar 15, 2010, 3:08:50 PM3/15/10
to django-...@googlegroups.com
Да. и дебаг-тулбар не забудьте выключить.
---
Alex Koshelev

2010/3/15 Arcady Chumachenko <arcady.ch...@gmail.com>:

Zodiak

unread,
Mar 15, 2010, 3:22:05 PM3/15/10
to Django russian
А теперь начинается уличная магия...
Выключил 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

unread,
Mar 15, 2010, 3:27:00 PM3/15/10
to django-...@googlegroups.com
От отключения тул-бара число запросов точно не поменялось. Просто он
сам по себе довольно медленно отрисовывает свой интерфейс с данными.

А вообще в дебаге все запросы логируются в конекшенах к базам. В
документации рассказано как их получить.

---
Alex Koshelev

2010/3/15 Zodiak <desz...@gmail.com>:

Arcady Chumachenko

unread,
Mar 15, 2010, 3:27:07 PM3/15/10
to django-...@googlegroups.com
Запросы те же самые, просто с выключенным дебагом для них не делается explain и прочие замеры.

2010/3/15 Zodiak <desz...@gmail.com>

А теперь начинается уличная магия...
Выключил debug-toolbar и ... вуаля! Вместо 3-4 секунд страница
открылась за одно мгновение!
Хотя я все еще подозреваю что запросов делается много, но то что это
не заметно уже радует.

Буду презнателен, если кто подскажет как с выключенным тулбаром
посмотреть какие запросы делаются к БД.
 

Alex Koshelev

unread,
Mar 15, 2010, 3:39:57 PM3/15/10
to django-...@googlegroups.com
Explain, как я помню, спрятан за клик (и запрос к серверу) на строчке с SQL.
---
Alex Koshelev

2010/3/15 Arcady Chumachenko <arcady.ch...@gmail.com>:

Oleg Komkov

unread,
Mar 16, 2010, 11:22:40 PM3/16/10
to django-...@googlegroups.com
В Пнд, 15/03/2010 в 22:33 +0500, Stanislav Panasik пишет:

> По теме полностью согласен с Юрием - преждевременная оптимизация есть
> первейшее зло. Рекомендую к прочтению книгу "Искусство программирования
> для Unix", всего лишь однократное её прочтение спасает от многих болячек
> (даже если вы пишете исключительно на дотнетах под винду).

Для равновесия предлагаю прочитать "Джоэл о программировании", а именно
главу "Дырявые абстракции"

Stanislav Panasik

unread,
Mar 17, 2010, 2:48:42 AM3/17/10
to django-...@googlegroups.com
Привет !

>> По теме полностью согласен с Юрием - преждевременная оптимизация есть
>> первейшее зло. Рекомендую к прочтению книгу "Искусство программирования
>> для Unix", всего лишь однократное её прочтение спасает от многих болячек
>> (даже если вы пишете исключительно на дотнетах под винду).
>
> Для равновесия предлагаю прочитать "Джоэл о программировании", а именно
> главу "Дырявые абстракции"

Прочитал. В чём же противоречие между книгой "Искусство программирования
для Unix", в которой подробнейшим образом говорится о базовых,
основополагающих вещах, и главой из другой книги, где говорится, что
помимо абстракций необходимо знать базовые вещи ? Поясните, пожалуйста.

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

Oleg Komkov

unread,
Mar 17, 2010, 6:41:46 AM3/17/10
to django-...@googlegroups.com
В Срд, 17/03/2010 в 11:48 +0500, Stanislav Panasik пишет:

> Прочитал. В чём же противоречие между книгой "Искусство программирования
> для Unix", в которой подробнейшим образом говорится о базовых,
> основополагающих вещах, и главой из другой книги, где говорится, что
> помимо абстракций необходимо знать базовые вещи ? Поясните, пожалуйста.

Собственно предложение прочесть относилось не столько к вашему
сообщению, сколько к сообщения Юрия и Михаила:

> Надеюсь, вы-то сами хоть понимаете, зачем дополнительные уровни
> абстракции нужны?
> А то, видимо, дипломированный специалист в вашем лице будет уметь
> выложить стенку из 3х кирпичей, и не представлять, чем его действия
> _принципиально_, подчёркиваю, _принципиально_, отличаться от
> строительства дома.

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

> Какой забавный (если не сказать сильнее) научный руководитель.

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

Mikhail Gusarov

unread,
Mar 17, 2010, 6:43:20 AM3/17/10
to django-...@googlegroups.com

Twas brillig at 16:41:46 17.03.2010 UTC+06 when oko...@gmail.com did gyre and gimble:

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

>> Какой забавный (если не сказать сильнее) научный руководитель.

OK> за желание уменьшить количество межпроцессовых вызов, мягко говоря,
OK> странно.

Дырявые абстракции и IPC никак не связаны.

--
http://fossarchy.blogspot.com/

Stanislav Panasik

unread,
Mar 17, 2010, 6:52:08 AM3/17/10
to django-...@googlegroups.com

> Собственно предложение прочесть относилось не столько к вашему
> сообщению, сколько к сообщения Юрия и Михаила:

Тогда очень извиняюсь :-)

UKD PHY

unread,
May 12, 2017, 9:14:49 PM5/12/17
to Django russian
Прошло 7 лет. Джанга всё так же необъяснимо тупит. Страницы открываются 2 секунды на локальной машине. 

Алексей С.

unread,
May 13, 2017, 1:59:37 AM5/13/17
to django-...@googlegroups.com
еще кто то пишет на джанге?

13 мая 2017 г., 1:56 пользователь UKD PHY <code...@gmail.com> написал:
Прошло 7 лет. Джанга всё так же необъяснимо тупит. Страницы открываются 2 секунды на локальной машине. 

--
Вы получили это сообщение, поскольку подписаны на группу "Django russian".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес django-russian+unsubscribe@googlegroups.com.
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

Yuri Baburov

unread,
May 13, 2017, 5:59:24 AM5/13/17
to django-...@googlegroups.com
Используете runserver ?

2017-05-13 5:56 GMT+07:00 UKD PHY <code...@gmail.com>:
> Прошло 7 лет. Джанга всё так же необъяснимо тупит. Страницы открываются 2
> секунды на локальной машине.
>
> --
> Вы получили это сообщение, поскольку подписаны на группу "Django russian".
> Чтобы отменить подписку на эту группу и больше не получать от нее сообщения,
> отправьте письмо на электронный адрес
> django-russia...@googlegroups.com.
> Чтобы настроить другие параметры, перейдите по ссылке
> https://groups.google.com/d/optout.



--
Best regards, Yuri V. Baburov, Skype: yuri.baburov

UKD PHY

unread,
May 13, 2017, 8:52:28 AM5/13/17
to Django russian
Да

суббота, 13 мая 2017 г., 12:59:24 UTC+3 пользователь Yuri Baburov написал:

Evgeny Myzgin

unread,
May 13, 2017, 8:59:04 AM5/13/17
to django-...@googlegroups.com

Тогда причина не в Django ;) загляните в документацию.


Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес django-russian+unsubscribe@googlegroups.com.

Max Morozov

unread,
May 13, 2017, 2:32:56 PM5/13/17
to django-...@googlegroups.com
Все перешли на Yii.....

--
Have a nice day,
Max Morozov

Yuri Baburov

unread,
May 13, 2017, 2:36:03 PM5/13/17
to django-...@googlegroups.com
Ну как сказать... В Джанге тоже, точнее, в её странных создателях..
Другого простого способа запускать дев сервер нет.

13 мая 2017 г. 19:59 пользователь "Evgeny Myzgin" <evmy...@gmail.com> написал:

UKD PHY

unread,
May 13, 2017, 2:55:30 PM5/13/17
to django-...@googlegroups.com
у меня маленький внутренний проект, и джанго отлично подходит. а тормоза были саязаны с mysql сервером. 

13 мая 2017 г. 9:36 PM пользователь "Yuri Baburov" <bur...@gmail.com> написал:
Вы получили это сообщение, поскольку подписаны на одну из тем в группе "Django russian".
Чтобы отменить подписку на эту тему, перейдите по ссылке https://groups.google.com/d/topic/django-russian/oeWqwyzD-jg/unsubscribe.
Чтобы отменить подписку на эту группу и все ее темы, отправьте письмо на электронный адрес django-russian+unsubscribe@googlegroups.com.

Yuri Baburov

unread,
May 14, 2017, 12:31:46 AM5/14/17
to django-...@googlegroups.com
Замечательно, что разобрались

14 мая 2017 г. 1:55 пользователь "UKD PHY" <code...@gmail.com> написал:

Konstantin Alekseev

unread,
May 14, 2017, 12:01:12 PM5/14/17
to Django russian
Обычно проблема большого количества запросов решается вот этим https://docs.djangoproject.com/en/1.11/ref/contrib/admin/#django.contrib.admin.ModelAdmin.list_select_related
Бывает еще что тулбар строит огромный DOM и из за этого страница долго рендериться (проверяется отключением тулбара)
Reply all
Reply to author
Forward
0 new messages