Comments 8
Вообще не ясно, чего вы хотели доказать?
Кешировать шаблоны рекомендует дока…
По поводу велосипедов, понятно, что на вкус и цвет… я для себе решил, что джанговые темплейты наиболее оптимальны… но раз уж вы любитель велосипедов, взяли б джинжу, она на пару спичек быстрее джанговых темплейтов и на тележку гибче (правда, чего-то готового на ней мало… ну на то и любители велосипедов)
Теперь, про макс реквест, по дефолту обычно стоит 500, я же ставлю 5000
Какой сакральный смысл 15ти??? Неуж то так память течет? Ну тогда вам совсем другое оптимизировать надо…
Отдельное фи за апач вместо нгинкса и wsgi вместо uwsgi
Кешировать шаблоны рекомендует дока…
По поводу велосипедов, понятно, что на вкус и цвет… я для себе решил, что джанговые темплейты наиболее оптимальны… но раз уж вы любитель велосипедов, взяли б джинжу, она на пару спичек быстрее джанговых темплейтов и на тележку гибче (правда, чего-то готового на ней мало… ну на то и любители велосипедов)
Теперь, про макс реквест, по дефолту обычно стоит 500, я же ставлю 5000
Какой сакральный смысл 15ти??? Неуж то так память течет? Ну тогда вам совсем другое оптимизировать надо…
Отдельное фи за апач вместо нгинкса и wsgi вместо uwsgi
Вопрос не в том, надо или не надо использовать кеширование. Вопрос в том — на сколько. Если занимаешься оптимизацией несколько более внимательно, чем «так сказала дока», то нужно отдавать себе отчет в том, какие изменения происходят в ответ на то или иное действие.
Не знаю что у вас стоит по дефолту и где, но по дефолту — смотри график два.
По сразу apache vs ngnix, wsgi vs uwsgi — то это совершенно не имеет никакого отношения к проблеме. От того что я что-то из этого поменяю представление быстрее отрабатывать ну будет. В данном случае важно — это время жизни потоков. Не знаю как оно в ngnix и uwsgi себя ведет по умолчанию, это я не изучал. Но даже там, зависимость от продолжительности жизни будет та же.
В любом случае — этот проект на сервере не единственный. На нем с десяток других проектов и сервисов, очень разнородных. Вкручивать туда еще ngnix или перенастраивать все под него(а не факт что это реально) от того что «апач фи» просто глупо.
Джанговские шаблоны конечно замечательная вещь, но HAML все же гораздо удобнее. Переписывать все шаблоны обратно на дефолтную реализацию для сравнения производительности я не буду. Да даже если бы я точно знал, что значительно выиграю врядли стал бы — есть множество других способов оптимизации, а так жертвовать удобством разработки я не готов.
Не знаю что у вас стоит по дефолту и где, но по дефолту — смотри график два.
По сразу apache vs ngnix, wsgi vs uwsgi — то это совершенно не имеет никакого отношения к проблеме. От того что я что-то из этого поменяю представление быстрее отрабатывать ну будет. В данном случае важно — это время жизни потоков. Не знаю как оно в ngnix и uwsgi себя ведет по умолчанию, это я не изучал. Но даже там, зависимость от продолжительности жизни будет та же.
В любом случае — этот проект на сервере не единственный. На нем с десяток других проектов и сервисов, очень разнородных. Вкручивать туда еще ngnix или перенастраивать все под него(а не факт что это реально) от того что «апач фи» просто глупо.
Джанговские шаблоны конечно замечательная вещь, но HAML все же гораздо удобнее. Переписывать все шаблоны обратно на дефолтную реализацию для сравнения производительности я не буду. Да даже если бы я точно знал, что значительно выиграю врядли стал бы — есть множество других способов оптимизации, а так жертвовать удобством разработки я не готов.
> Первое что приходит на ум — это конечно неффективная работа с БД. Был проведен достаточно большой объем работы, который уменьшил количество запросов к БД вдвое, их сложность(и время исполнения) еще вдвое.
Ну так надо было профилировать запросы сначала, прежде чем оптимизировать. Тот же django-debug-toolbar хотя бы :)
Ну так надо было профилировать запросы сначала, прежде чем оптимизировать. Тот же django-debug-toolbar хотя бы :)
я просмотрел дамп sql запросов. В принципе всегда это делаю, что бы иметь представление о состоянии дел. В дампе на одну страницу порядка 150 запросов, некоторые из которых выполнялись 10-50мс, то есть достаточно долго. Плюс часть из них вызывались непосредственно из шаблона, что не представляло возможности профилировать шаблон отдельно.
Мне как то и в голову не приходило, что проблемы со скоростью могут быть из-за самого шаблона. Обычно это либо логика, либо БД. В большинстве случаев — просто БД.
Мне как то и в голову не приходило, что проблемы со скоростью могут быть из-за самого шаблона. Обычно это либо логика, либо БД. В большинстве случаев — просто БД.
Дамп :) вы и правда любите велосипеды. github.com/django-debug-toolbar/django-debug-toolbar
я в курсе этой штуки. Я просто вырос с компилируемых языков и была бы простая возможность заглянуть в ассемблерный код — я бы и это регулярно поделывал. Привычка. Мне кстати порядком интересна тяжесть отдельных питоновских операций, да как то все не попадается хорошей статьи на эту тему, а самому анализировать руки не доходят.
А дамп запросов это кстати не велосипед, а одна из возможностей джанго:
А вот для куки и прочего у меня есть свой велосипед, весьма функциональный. В случае исключения его инфа, включая стек, куки, GET/POST дампятся в БД. Если пользователь на странице ошибки пожаловался — к жалобе прикрепляется инфа об исключении. Жалобу можно отправить в Jira одной кнопкой, вместе со всей инфой. Отдельно просмотр таких исключений позволяет выявить ситуации, о которых пользователи почему то забыли пожаловаться.
Я люблю велосипеды не от хорошей жизни. К сожалению если хочешь что-бы что-то было сделано хорошо — сделай это сам.
А дамп запросов это кстати не велосипед, а одна из возможностей джанго:
LOGGING = {
'version': 1,
'disable_existing_loggers': True,
'handlers': {
'sqllogfile': {
'level': 'DEBUG',
'class': 'logging.handlers.WatchedFileHandler',
'filename': PROJECT_ROOT + 'sql-logfile.txt',
},
},
'loggers': {
'django.db.backends': {
'handlers': ['sqllogfile'],
'level': 'DEBUG',
'propagate': False,
},
}
}А вот для куки и прочего у меня есть свой велосипед, весьма функциональный. В случае исключения его инфа, включая стек, куки, GET/POST дампятся в БД. Если пользователь на странице ошибки пожаловался — к жалобе прикрепляется инфа об исключении. Жалобу можно отправить в Jira одной кнопкой, вместе со всей инфой. Отдельно просмотр таких исключений позволяет выявить ситуации, о которых пользователи почему то забыли пожаловаться.
Я люблю велосипеды не от хорошей жизни. К сожалению если хочешь что-бы что-то было сделано хорошо — сделай это сам.
Sign up to leave a comment.
Оптимизация обработки шаблонов