Комментарии 50
Так делать плохо:
правильно:
О чем написано в первых же строчках:
nginx.org/en/docs/http/converting_rewrite_rules.html
if ($host = www.project.ru){
rewrite ^(.*)$ http://project.ru$1 permanent;
}
правильно:
server {
listen 80;
server_name www.project.ru;
return 301 http://project.ru$request_uri;
}
О чем написано в первых же строчках:
nginx.org/en/docs/http/converting_rewrite_rules.html
Кхм. Вы только что привели меня к мысли: я не читал доки от начала. Искал через гугл, когда в этом была необходимость и как следствие читал «кусками». Спасибо, за правку.
К сожалению официальная документация в настоящий момент частично содержит устаревшую информацию, но работы над актуализацией ведутся.
Поэтому, помимо nginx.org, стоит также смотреть wiki.nginx.org, но самое интересное обычно содержится в списках рассылки: http://mailman.nginx.org/mailman/listinfo. Их регулярно читают разработчики, а также не мало очень опытных пользователей, и из них можно узнать как лучше настраивать те или иные вещи, одним из первых узнавать обо всех нововведениях, выпуске новых версий и уязвимостях, которые, увы, тоже случаются. Туда также можно направлять свои предложения и пожелания по улучшению, но предварительно стоит хорошенько погуглить.
Всем, кто хочет научиться хорошо и безопасно настраивать nginx, рекомендуется к прочтению:
И обязательно документацию по таким важным директивам, как location, server_name, root, alias, try_files, error_page, map.
p.s. ещё маленькая придирка:
uWSGI (uwsgi маленькими буквами — это название протокола) все-таки правильнее называть не веб-сервером, а сервером приложений (в роли веб-сервера у вас nginx), о чем сами авторы по ссылке и пишут.
Поэтому, помимо nginx.org, стоит также смотреть wiki.nginx.org, но самое интересное обычно содержится в списках рассылки: http://mailman.nginx.org/mailman/listinfo. Их регулярно читают разработчики, а также не мало очень опытных пользователей, и из них можно узнать как лучше настраивать те или иные вещи, одним из первых узнавать обо всех нововведениях, выпуске новых версий и уязвимостях, которые, увы, тоже случаются. Туда также можно направлять свои предложения и пожелания по улучшению, но предварительно стоит хорошенько погуглить.
Всем, кто хочет научиться хорошо и безопасно настраивать nginx, рекомендуется к прочтению:
И обязательно документацию по таким важным директивам, как location, server_name, root, alias, try_files, error_page, map.
p.s. ещё маленькая придирка:
Веб-сервер
Это будет uwsgi — быстрый и модный.
uWSGI (uwsgi маленькими буквами — это название протокола) все-таки правильнее называть не веб-сервером, а сервером приложений (в роли веб-сервера у вас nginx), о чем сами авторы по ссылке и пишут.
Не думаю, что при отдаче статики из временной файловой системы будет большой выигрыш.
Современные ОС очень грамотно кэшируют отдачу файлов.
То же касается и замены MySQL на SQLite. Ведь если оттюнить MySQL, вполне можно добиться отдачи всех ответов из кэша запросов.
Современные ОС очень грамотно кэшируют отдачу файлов.
То же касается и замены MySQL на SQLite. Ведь если оттюнить MySQL, вполне можно добиться отдачи всех ответов из кэша запросов.
Выигрыш действительно небольшой. По поводу mysql: я решил что сам по себе сервис тоже требует ресурсов, и еще буквально перед публикацией, подумав я решил удалить следующее:
С таким кешированием тяжело работать, но если знать как — проблем никаких.
# В настройках кеша
'TIMEOUT': 0,
# В модели флетпейджа
def save(self, *args, **kwargs):
if self.id:
cache.delete(self.get_absolute_url())
super(FlatPage, self).save(*args, **kwargs)
С таким кешированием тяжело работать, но если знать как — проблем никаких.
Посмотрите лучше Octopress. Немного о подобных движках есть тут — Goblog: Самодельный статический движок для блога на Go.
Или если не выходить за рамки питона, то flask-freeze
НЛО прилетело и опубликовало эту надпись здесь
Пару мелких проектов я захостил у locum.ru. Django за 150р в месяц — это ок.
В ваш конфиг я бы добавил запрет на запросы кроме GET/POST, или $request_method в ключ кеша. А так — кто-то пошлет HEAD запрос на страницу и у вас в кеш ляжет пустая старница.
Это?
cache_it = not settings.DEBUG \
and request.method == 'GET' \
and response.status_code == 200
тогда по логике в nginx должно быть аналогичное условие. что-то типа:
location / {
if ($request_method = GET) {
default_type "text/html; charset=utf-8";
set $memcached_key "YOURSITE:1:$request_uri";
memcached_pass unix:/tmp/memcached.sock;
error_page 404 502 = @fallback;
break;
}
try_files $uri @fallback;
}
Зачем катавасия с мемкешем? Если уж единовременно генерировать странички, можно сразу класть их в виде html-файлов в корень nginx'а (кстати, это уже было в Симпсонах). Заодно и память сэкономите, на ВДСах за её расходом приходится следить.
А вообще статья хорошая, конечно =)
А вообще статья хорошая, конечно =)
Во-первых мемкеш быстрее чем диск, во-вторых в кеше можно еще хранить всякие полезные штуки типа слоу-квери: менюшки, например, то что часто используется: в контекстных процессорах.
Мемкеш быстрее, чем чтение с диска. Но обычно, как уже говорилось выше, файл в кеше ОС, и получается что работа с мемкешом медленнее — вам еще и через сокеты прогнать инфу надо.
Еще выше говорилось почему это может быть полезно.
Уж сколько раз тут уже упоминалось про кеш ОС :-)
Для менюшек и прочего кеширование использовать, разумеется, можно (хоть и непонятно зачем: страницы-то целиком в запоминаются в мемкеше и при их вызове к джанге даже обращения нет). Но ради такой мелочи можно и locmem использовать.
Для менюшек и прочего кеширование использовать, разумеется, можно (хоть и непонятно зачем: страницы-то целиком в запоминаются в мемкеше и при их вызове к джанге даже обращения нет). Но ради такой мелочи можно и locmem использовать.
Увидел в загаловках «стаья — шутка» и подумал что статья безполезная х*ня, открыл тупо поржать с прикола. А в итоге: с удавольствием прочитал, увидил много полезных для себя ссылок, посмотрел предложенные варианты оптимизации, кое-что наматал на ус. Остался даволен. Спасибо.
За способы оптимиизации конечно большой плюс, но в целом за подход… Я рад, что вы подписали шутка :)
200 мб озу и 500 мгц, хватает на достаточно большое количество юзеров и приличный сайт (ну, если саму логику кодить прилично), поэтому проблемы такой оптимизации не совсем понял.
200 мб озу и 500 мгц, хватает на достаточно большое количество юзеров и приличный сайт (ну, если саму логику кодить прилично), поэтому проблемы такой оптимизации не совсем понял.
200мб это много и мало — смотря как к этому подойти. Все зависит от того насколько ваше приложение отличается от «hello world». Я в работе использую кучу батареек и при этом являюсь ярым сторонником DRY: например, less вместо css, а ему нужен nodejs. Однако оптимизация — это, почти, всегда: тут убавил, там прибавил и при определенной степени «комфорта» разработки возникают определнные «трудности». Потеря в скорости, при этом, не допустима.
Если убрать мемкешд и статику из памяти сайт будет работать, но не так быстро как я могу себе это позволить.
Если убрать мемкешд и статику из памяти сайт будет работать, но не так быстро как я могу себе это позволить.
Вы правы в том, что less и DRY — это хорошо. В остальном — нет :) less нужно компилировать ровно один раз, на своей девелоперской машине, при деплое. Заодно кучу css-файлов можно смержить в один, удалить лишние пробелы и гзипнуть на всякий случай.
С coffeescript проделываются аналогичные вещи: компиляция — мерж — yuicompressor… На выходе получается один минифицированный (или даже обфусцированный) js, который уже и отправляется на сервер.
Такая вот подготовленная статика молча лежит икаши не просит не компилируется. При желании её вообще можно на народ.ру закинуть.
Зачем Вам less на сервере? =)
С coffeescript проделываются аналогичные вещи: компиляция — мерж — yuicompressor… На выходе получается один минифицированный (или даже обфусцированный) js, который уже и отправляется на сервер.
Такая вот подготовленная статика молча лежит и
Зачем Вам less на сервере? =)
А зачем мне треш в репе? На каждый коммит удалять старые ксс/джс и добавлять новые? Временные файлы должны быть временными и я не хочу помнить о таких вещах.
Можно не удалять, а синкать. Хотя, конечно, многое зависит от инструментов деплоя. А воспринимать css/js как временные, если им не нужна динамическая (на каждый запрос) генерация, имхо, несколько не верно. Это как считать исполняемые бинарники (pe, elf, ...) временными файлами и раздавать пользователям исходники — запускаешь калькулятор? «упс, временный экзешник удалился уже, подождите пока идёт компиляция и сборка...»
Статика генерится раз при старте приложения, и только если исходные файлы изменены.
Компрессор самостоятельно компилирует, жмет и подставляет новые имена файлов в шаблоны. Я вообще об этом не думаю: мне только залить изменения на сервер и ребутнуть приложение.
Компрессор самостоятельно компилирует, жмет и подставляет новые имена файлов в шаблоны. Я вообще об этом не думаю: мне только залить изменения на сервер и ребутнуть приложение.
За компиляцию и доставку отвечает не система контроля версий, а система разворачивания приложений.
Обычно ассеты компилируются, пакуются и заливаются на целевой сайт без VCS. Либо компилируются на целевом хосте перед симлинком на новую версию приложения.
Обычно ассеты компилируются, пакуются и заливаются на целевой сайт без VCS. Либо компилируются на целевом хосте перед симлинком на новую версию приложения.
Тут ответил.
Если вы тоже используете less, не забудьте поставить node.js на сервер и сам компиляторесть куча доводов против того, чтобы тащить средства разработки на продакшен.
а в целом, спасибо за статью, очень познавательно.
Действительно, зачем треш в репе? У меня вообще папка public/ (в ней media и static/ хранятся) находится в .gitignore и создаётся при развёртывании динамически.
Так что тут тоже полностью согласен: трешу в репозитории не место :-)
Так что тут тоже полностью согласен: трешу в репозитории не место :-)
Я тоже как-то раз так загнался — хотелось платить за сайт по-минимуму. В итоге сделал генерацию статики, и один активный скрипт на cgi для отправки заказа (магазин). Кидаю готовый контент на GAE, проект мелкий, пока лимиты не выбирает. Корзина в куках. Последний раз переделал на flask-freeze.
Лично для меня содержание поста (пока) не применимо, но перед вашей манерой письма снимаю шляпу. Читается на одном дыхании.
Я бы на вашем месте разместил всю статику на Github Pages. Там шустрые nginx и все сжато и отлично подходит в качестве личного мини-CDN. Просто с каждой версией компилить css из less, js из coffeescript итд а потом коммитить в репозиторий и не забыть положить в репозиторий файлик CNAME где прописать например static.site.com и все — ваша статика не занимает на сервере место и не напрягает ваш nginx лишний раз. Все раздается из облака в Rackspace Cloud(именно там располагаются сервера Github Pages). А еще можно вообще спрятать весь сайт за крепкими плечами cloudflare.com
А вообще мне кажется в вашей ситуации varnish бы сделал больше чем делает memcached.
Да, я в курсе под гитхаб :)
«Просто… и все» — вы мне мое начальство напоминаете :) То, что вы описали нисколечки не DRY, но как один из способов оптимизации — гуд. Жирный плюс вам.
Просто с каждой версией компилить css из less, js из coffeescript итд а потом коммитить в репозиторий и не забыть положить в репозиторий файлик CNAME где прописать например static.site.com и все
«Просто… и все» — вы мне мое начальство напоминаете :) То, что вы описали нисколечки не DRY, но как один из способов оптимизации — гуд. Жирный плюс вам.
Тьфу, *про гитхаб
Да еще и пробелище такой влепил после цитаты. Уважаемый, Хабр, почему вы не трете лишние br, м?
Да еще и пробелище такой влепил после цитаты. Уважаемый, Хабр, почему вы не трете лишние br, м?
Ну в том-же Twitter Bootstrap лежит файлик Makefile можно посмотреть как он сделан и что он делает и сделать нечто подобное для своего проекта и добавить там еще пару строчек чтобы все коммитилось в репозиторий. Чем не DRY. А файлик CNAME 1 раз только положить надо ну и создать CNAME или A DNS-запись.
Кстати раньше часто пользовал django-compressor а теперь перешел на django-pipeline или jingo-minify.
Кстати раньше часто пользовал django-compressor а теперь перешел на django-pipeline или jingo-minify.
Я бы просто на локум задешево положил проект :)
Если я правильно Вас понял, основная цель состояла в том, что минимизировать расходы на проект.
В последнее время для маленьких или тестовых проектов я начал использовать google app engine. Получается бесплатно (квоты).
Кроме того, нет необходимости разбираться с хостингом, а разворачивание проекта в боевой режим сводится к нажатию кнопки «Deploy».
Если вы хотите использовать MySQL — Cloud SQL к вашим услугам. При этом для запросов из app engine там нет ограничений.
Ваша статья понравилась! Спасибо.
В последнее время для маленьких или тестовых проектов я начал использовать google app engine. Получается бесплатно (квоты).
Кроме того, нет необходимости разбираться с хостингом, а разворачивание проекта в боевой режим сводится к нажатию кнопки «Deploy».
Если вы хотите использовать MySQL — Cloud SQL к вашим услугам. При этом для запросов из app engine там нет ограничений.
Ваша статья понравилась! Спасибо.
Мне очень понравилась подводка к основному тексту: сначала рассказчик не знает ничего, и держит проект на php на shared-хостинге, затем (с точки зрения текста — внезапно) раскачивает свой skill, и легким движением руки настраивает Django на VPS. :)
Это я не в критику — просто побольше бы таких историй успеха. Уж больно большой прыжок в знаниях и в подходе нам показали. Интересно, а в жизни этот прыжок сколько времени занял?
Это я не в критику — просто побольше бы таких историй успеха. Уж больно большой прыжок в знаниях и в подходе нам показали. Интересно, а в жизни этот прыжок сколько времени занял?
В январе 2010 я сделал свою первую верстку: и сразу интернет-портал (дивы, ие6 и более). У нас были проблемы с программистом, мне часто приходилось лезть в шаблоны mako (это я как-то еще понимал).
В августе 2010 я начал изучать джангу: читал книжку в свободное время («Django. Разработка веб-приложений на Python»). Где-то в октябре до меня дошло, что я начал не с того конца и взялся за Лутца («изучаем питон»). Дальше я работал с готовым проектом (мне его оставили в наследство) по немногу увеличивая скилы.
Весной 2011 я сделал первый проект самостоятельно от дизайна до кода и развертки: интернет-магазин. Потом еще один, но уже сложнее и больше. С августа 2011 я встрял в один большой проект вторым программистом, где первый — чистой воды гений: подобный тимлид все равно что допинг. До этого августа уже становилось скучно: одно и тоже целыми днями. В ноябре проект развалился и я потихоньку стал киснуть. В декабре 2011 это скука просто била по мозгу и я начал делать свой маленький проект, который забросил в феврале в долгий ящик, теперь наверное придется все переписывать :( В феврале мы с супругой решили попробовать свои силы в своем деле, 5 апреля мы гордо сказали «понеслася!» и удалили авторизация с нжинкс :) На основе полученного опыта при его разработке я и написал статью. За кулисами осталось еще много интересного, но в основном по верстке. Возможно я их как-нибудь соберу в отдельную статью: ведь немало нового можно узнать из комментариев, как, например, тут.
2010 и по сей день: 2,5 года выходит. Прыжок может и большой, но пробелов в знаниях, хватает. Вот и вся «история успеха» :)
В августе 2010 я начал изучать джангу: читал книжку в свободное время («Django. Разработка веб-приложений на Python»). Где-то в октябре до меня дошло, что я начал не с того конца и взялся за Лутца («изучаем питон»). Дальше я работал с готовым проектом (мне его оставили в наследство) по немногу увеличивая скилы.
Весной 2011 я сделал первый проект самостоятельно от дизайна до кода и развертки: интернет-магазин. Потом еще один, но уже сложнее и больше. С августа 2011 я встрял в один большой проект вторым программистом, где первый — чистой воды гений: подобный тимлид все равно что допинг. До этого августа уже становилось скучно: одно и тоже целыми днями. В ноябре проект развалился и я потихоньку стал киснуть. В декабре 2011 это скука просто била по мозгу и я начал делать свой маленький проект, который забросил в феврале в долгий ящик, теперь наверное придется все переписывать :( В феврале мы с супругой решили попробовать свои силы в своем деле, 5 апреля мы гордо сказали «понеслася!» и удалили авторизация с нжинкс :) На основе полученного опыта при его разработке я и написал статью. За кулисами осталось еще много интересного, но в основном по верстке. Возможно я их как-нибудь соберу в отдельную статью: ведь немало нового можно узнать из комментариев, как, например, тут.
2010 и по сей день: 2,5 года выходит. Прыжок может и большой, но пробелов в знаниях, хватает. Вот и вся «история успеха» :)
Промашка вышла, не туда ответил :)
Большая часть касается не джанги и не python. Если задаться вопросом оптимизации php проекта то всё почти также будет, разве что вместо uwsgi php-fpm ставить или phpdaemon в режиме http-сервер (не уверен, что есть смысл) или true fastcgi
Серьезно, и с искренним уважением: настоящая success story. Побольше бы таких!
А статью, скажу за всех — ЖДЕМ-с!
А статью, скажу за всех — ЖДЕМ-с!
А кеширование Nginx вам не подходит? wiki.nginx.org/HttpUwsgiModule#uwsgi_cache ИМХО гораздо проще организовать.
Хорошо написано. Но если надо кешировать сайт при малых мощностях или большой нагрузке — есть отличный StaticGenerator Pro, написанный Alrond-ом. При первом обращении к странице генерится html-файл прямо в папку — откуда потом nginx берет напрямую, минуя джангу.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Оптимизация flatpages проекта на django под минимальные системные требования. Статья-шутка