1. Ну насчет настройки, с одной стороны, все верно, лишняя сущность, но с другой — чего там в апаче настраивать-то, по сравнению с предложенным способом)
2. Теперь насчет памяти. В случае с процессами-воркерами ngnix, как я понимаю (поправьте, если не так), в каждый процесс будет грузиться как минимум интерпретатор питона. Или нет? Апачевский mod_wsgi работает с shared-версией питоновских библиотек, в итоге каждый его процесс представляет из себя 250 килобайт собственно кода mod_wsgi + загруженное приложение (сайт на джанге, например). Я так себе представляю. Так что и потребление памяти еще посчитать стоит, где больше.
3. Насчет ложки дегтя. Если на VDS том же крутятся несколько сайтов, то выгоднее всем ограничить число плодящихся процессов, а изначально запускать их меньше, чем это макс. ограничение, так что сайты смогут переживать пиковые нагрузки с одной стороны, и не кушать много памяти без надобности с другой. Апачевский mod_wsgi в этом плане довольно гибок — может использовать как апачевские модели порождения процессов и тредов, так и свои. Если ngnix'овые воркеры тоже умеют запускаться по необходимости, то все отлично. А если нет, то вот что выходит: сам сайт на джанге ест в большинстве случаев памяти больше, чем выражение (размер процесса апача — размер процесса ngnix), поэтому даже одна лишняя копия сайта в памяти может убить все преимущество ngnix.
4. Еще раз, насчет памяти, которую скушает апач. Это скорее штука психологическая. Ведь все знают, что апач жрет кучу памяти. Но лучше знать цифры. Если критично 6 (или сколько там) мегабайт на 1 сайт (не на 1 процесс, на сайт) — то да, есть смысл искать что-то другое. Как мне кажется, это критично только если хостится куча сайтов на одном VDS или сервере (кстати, тут см. п3, про ложку дегтя). А для одного сайта с высокой нагрузкой это не критично совершенно, тут важнее надежность и гибкость апачевского mod_wsgi, а так же то, что накладные расходы на процесс/тред минимальны.
Все это ни в коем случае не умаляет важность и полезность статьи, полезно знать, как настроить mod_wsgi ngnix-овский, просто важно обозначить, зачем и когда это нужно.
Сейчас глянул к себе на VDS — процесс апача, который обслуживает сайт, к которому никто не ходит, занимает 6 метров RES-памяти. Это, собственно, все лишние расходы на 1 сайт. Я ничего хитро не компилировал и т.д., просто оставил только нужные модули (mod_wsgi, mod_fastcgi, еще по мелочи).
А чем не устраивает стандартный способ — mod_wsgi к апачу + когда понадобится — ngnix в качестве фронт-энда\для статики? Оверхед в случае апача небольшой, если вообще есть (по сути — это 1 лишний родительский процесс и все).
Ведь треды-процессы mod_wsgi апачевского — независимые, и апача самого в себе не содержат.
А тут непонятно, как обходить эту самую «ложку дегтя».
Тут проявляется одно из преимуществ использования фреймворков.
Берем для примера джангу.
Там есть «django.contrib.sessions.backends.cached_db»:
This uses a write-through cache – every write to the cache will also be written to the database. Session reads only use the database if the data is not already in the cache.
По сути, то же самое, что и описано.
Но иногда такой вариант не подходит, т.к. может не хватать скорости (кроме memcached работает еще и БД). Тогда идем в настройки и меняем SESSION_ENGINE, например, на 'django.contrib.sessions.backends.cache'. Данные сессий теперь хранятся только в кеше.
Причем кеш ведь тоже может быть разный — локальная память процесса, файлы, БД, memcached, можно и свое что-нибудь написать.
В итоге в большинстве случаев не тратится время на изобретение, обкатку и ремонт велосипедов.
Ничего не имею против варианта организации сессий, который тут описан, просто рассуждения.
Сначала тож подумал: некрасиво, свой сайт попиарили, источник не указали. Но зашел на smashing magazine, перешел по ссылке на сайт авторов — pixel-mixer и есть. Ребята молодцы, ссылка в статье и есть первоисточник.
Когда можно — никакого синтаксического оверхеда в виде определения класса, обычная функция + декоратор к ней.
Архитектура — на ООП всегда, тут Вы правы.
Про модули питона — в точку, те же самые ощущения. Когда не нужна инкапсуляция данных, наследование и полиморфизм, а только требуется инкапсулировать некий функционал (на самом деле, частый довольно случай) — отличный работающий подход.
В чем-то BarsLV прав, иногда без объектов и классов проще. В django вон тоже процедурный стиль используется часто. Вид там (контроллер в обычной терминологии MVC) — обычная функция, например. Но это возможно из-за удачной архитектуры (построенной, конечно, на ООП) — код контроллеров обычно выходит довольно простой — будь они объектами, содержали бы в среднем чуть больше 1 метода. Кроме этого, помогает приличная примесь всяких штук из ФП в питоне (функции-декораторы, лямбды всякие и т.д.)
А большинство задач с использованием ООП все ж решаются проще и красивее, чем процедурным подходом. Думаю, раз автор задался уж вопросом, ему будет интересно почитать «Паттерны проектирования» by GOF, книжки Мартина Фаулера про паттерны и про рефакторинг, чтоб взглянуть на мир со стороны сугубо объектно-ориентированной.
А идеи сами по себе чего-то стоят? А вообще-то да, знаю, вопрос холиварный)
Гугл же не самовыражается, реализуя схожую фичу, а пытается сделать свой сервис удобнее для пользователей (чтобы заработать больше денег, естественно, но это нормально).
Честно говоря, не очень знаком с историей развития поисковых систем, но почему-то мне думается, что процесс заимствований идет постоянный — и во все стороны. Не будь гугла тот же яндекс был бы, как мне кажется, другим. И не только в области поисковиков так, а абсолютно везде, что при выращивании морковки, что при производстве автомобилей.
Как пользователь я только приветствую появление новых штук, повышающих удобство работы, будь они в яндексе, гугле, нигме или еще где-то.
Вот, что-то такое я и надеялся услышать, спасибо, прояснили вопрос. Я так-то не волнуюсь) К миру Java отношения имею мало. Просто в этом месте часто грабли бывают. Хорошо, что тут их нет вроде бы.
Хэй, откуда агрессия?
а) Один из этих 5 раз про сериализацию это повторил я. Вообще не понял, к чему тут это ваше замечание.
б) Насчет XML Вы неправы. Если данные сохранить как "123", то они везде прочитаются безо всяких адаптеров, а если сохранять в байт-коде, то это может быть «7B», «007B», «7B00», «0000007B» и т.д.
Я не очень хорошо знаком с Java, но у меня сразу, как только дело доходит до байт-кода, возникает вопрос: есть ли бинарная совместимость данных после такой сериализации? Например, между разными ОС, или между 32 и 64-битными машинами, или между разными версиями ява-машины, ну и т. д. Просто если ее нет, то об этом следует говорить, чтобы люди выбирали XML или что-нибудь еще для передачи данных.
Сам по себе ООП-то довольно прост. Ну понять, что такое наследование, зачем инкапсуляция, про полиморфизм еще. А вот чтобы понять, как его применять, следует изучить т.н. паттерны проектирования.
Есть классическая книжка на эту тему, которую, как мне кажется, должен осилить каждый уважающий себя программист: Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес — «Приемы объектно-ориентированного проектирования. Паттерны проектирования».
Еще можно почитать Фаулера — «Архитектура корпоративных программных приложений приложений», отличная книга тоже.
2. Теперь насчет памяти. В случае с процессами-воркерами ngnix, как я понимаю (поправьте, если не так), в каждый процесс будет грузиться как минимум интерпретатор питона. Или нет? Апачевский mod_wsgi работает с shared-версией питоновских библиотек, в итоге каждый его процесс представляет из себя 250 килобайт собственно кода mod_wsgi + загруженное приложение (сайт на джанге, например). Я так себе представляю. Так что и потребление памяти еще посчитать стоит, где больше.
3. Насчет ложки дегтя. Если на VDS том же крутятся несколько сайтов, то выгоднее всем ограничить число плодящихся процессов, а изначально запускать их меньше, чем это макс. ограничение, так что сайты смогут переживать пиковые нагрузки с одной стороны, и не кушать много памяти без надобности с другой. Апачевский mod_wsgi в этом плане довольно гибок — может использовать как апачевские модели порождения процессов и тредов, так и свои. Если ngnix'овые воркеры тоже умеют запускаться по необходимости, то все отлично. А если нет, то вот что выходит: сам сайт на джанге ест в большинстве случаев памяти больше, чем выражение (размер процесса апача — размер процесса ngnix), поэтому даже одна лишняя копия сайта в памяти может убить все преимущество ngnix.
4. Еще раз, насчет памяти, которую скушает апач. Это скорее штука психологическая. Ведь все знают, что апач жрет кучу памяти. Но лучше знать цифры. Если критично 6 (или сколько там) мегабайт на 1 сайт (не на 1 процесс, на сайт) — то да, есть смысл искать что-то другое. Как мне кажется, это критично только если хостится куча сайтов на одном VDS или сервере (кстати, тут см. п3, про ложку дегтя). А для одного сайта с высокой нагрузкой это не критично совершенно, тут важнее надежность и гибкость апачевского mod_wsgi, а так же то, что накладные расходы на процесс/тред минимальны.
Все это ни в коем случае не умаляет важность и полезность статьи, полезно знать, как настроить mod_wsgi ngnix-овский, просто важно обозначить, зачем и когда это нужно.
Ведь треды-процессы mod_wsgi апачевского — независимые, и апача самого в себе не содержат.
А тут непонятно, как обходить эту самую «ложку дегтя».
Берем для примера джангу.
Там есть «django.contrib.sessions.backends.cached_db»:
This uses a write-through cache – every write to the cache will also be written to the database. Session reads only use the database if the data is not already in the cache.
По сути, то же самое, что и описано.
Но иногда такой вариант не подходит, т.к. может не хватать скорости (кроме memcached работает еще и БД). Тогда идем в настройки и меняем SESSION_ENGINE, например, на 'django.contrib.sessions.backends.cache'. Данные сессий теперь хранятся только в кеше.
Причем кеш ведь тоже может быть разный — локальная память процесса, файлы, БД, memcached, можно и свое что-нибудь написать.
В итоге в большинстве случаев не тратится время на изобретение, обкатку и ремонт велосипедов.
Ничего не имею против варианта организации сессий, который тут описан, просто рассуждения.
а название студии напомнило Mogwai
@register.simple_tag def current_time(format_string): return datetime.datetime.now().strftime(format_string)Когда можно — никакого синтаксического оверхеда в виде определения класса, обычная функция + декоратор к ней.
Архитектура — на ООП всегда, тут Вы правы.
А большинство задач с использованием ООП все ж решаются проще и красивее, чем процедурным подходом. Думаю, раз автор задался уж вопросом, ему будет интересно почитать «Паттерны проектирования» by GOF, книжки Мартина Фаулера про паттерны и про рефакторинг, чтоб взглянуть на мир со стороны сугубо объектно-ориентированной.
Гугл же не самовыражается, реализуя схожую фичу, а пытается сделать свой сервис удобнее для пользователей (чтобы заработать больше денег, естественно, но это нормально).
Честно говоря, не очень знаком с историей развития поисковых систем, но почему-то мне думается, что процесс заимствований идет постоянный — и во все стороны. Не будь гугла тот же яндекс был бы, как мне кажется, другим. И не только в области поисковиков так, а абсолютно везде, что при выращивании морковки, что при производстве автомобилей.
Как пользователь я только приветствую появление новых штук, повышающих удобство работы, будь они в яндексе, гугле, нигме или еще где-то.
А чем плохо то, что разные компании реализуют похожие фичи?
а) Один из этих 5 раз про сериализацию это повторил я. Вообще не понял, к чему тут это ваше замечание.
б) Насчет XML Вы неправы. Если данные сохранить как "123", то они везде прочитаются безо всяких адаптеров, а если сохранять в байт-коде, то это может быть «7B», «007B», «7B00», «0000007B» и т.д.
Но там язык — далеко не самое важное.
Есть классическая книжка на эту тему, которую, как мне кажется, должен осилить каждый уважающий себя программист: Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес — «Приемы объектно-ориентированного проектирования. Паттерны проектирования».
Еще можно почитать Фаулера — «Архитектура корпоративных программных приложений приложений», отличная книга тоже.