26 января 2008 в 16:54
Прочитал:
Интервью: новый веб-сервис "Яндекса" построен на языке Python и фреймворке Django
http://soft.compulenta.ru/346012/
Статья в вики про Django http://ru.wikipedia.org/wiki/Django
Кто сталкивался с этим Django?
Хотелось бы узнать мнения.
Содержимое сайта публикуется на условиях CreativeCommons Attribution-ShareAlike 3.0 или более поздней версии. Программные коды в тексте статей — на условиях GNU GPL v2 или более поздней версии.
Документация по совместной работе с репозиторием drupal.ru – https://docs.drupal.ru/code
Drupal – торговая марка Дриса Бёйтарта
Поддерживать инфраструктуру Drupal.ru нам помогает компания ДАЛЕЕ
Комментарии
сравнивать django с drupal глупо. Что за мода на "сенсационные заголовки"? )
django это фреймворк более низкого уровня, аналоги в пхп - codeigniter и cakephp, в руби - ror
Вполне неплохая система єкшен-вид.
Не жалко было времени на изучение.
А уж связка питона и последнего постгри с его полнотекстовым поиском это просто круто.
Можна делать проекты любой сложности.
Но все нада писать самому, очень мало сторонних модулей.
И к тому же версия еще до единички не доросла).
Сейчас на нем делаю вот это http://www.bankman.com.ua/ в пн сдача)
Ну и для тренировки делал da.net.ua
Короче вполне себе достойный легкий и прозрачный фреймворк (по сравнению например с плоном plone.ru).
Согласен. Только это не CMS, потому о каком сравнении может идти речь.
А как там с русским языком при полнотекстовом поиске. Точнее со словоформами. Разве есть в ПостГри русский стемминг?
Точнее на нем легче делать более сложные проекты, чем сложные проекты на Drupal.
Это нормально. Ибо не CMS это.
Плон как раз не фреймворк, а CMS. Как и Drupal.
restyler ни и заявки.)
Более низкого уровня.))
Со мной рядом чудик сидит узбек) так он из пайлонов (это такие маааленькие утилитки более низкого уровня)))
собирает проект для которого уже сделан кластер из 6 серваков.
Вобщем то каждый ограничен своей некомпетентностью.
Для меня вот линукс проще друпала). И уровень линукса тут нипричем.
как можно сравнивать фреймворк с ЦМС?!
я понимаю там было бы ror vs. Django
http://turbogears.org ещё на мой взгляд интересен - связка API CherryPy, SQLObject и темплейтов Kid. Один из ключевых моментов популярности друпала - популярность языка PHP. Если опыта работы с питоном больше, то Django или Turbogears - удобные инструменты для программистов. Надо только понимать, что это не готовые CMS, а CMF. Друпал сочетает CMF с готовой к использованию CMS.
Тогда уж сразу Pyramid (http://docs.pylonsproject.org/projects/pyramid/dev/), ибо те что в начале вашего текста - уже устарели и несовершенны зело.
Не только.
Drupal прежде всего настраивается, а то что вы перечислили - только программируется.
CMF с уклоном в фреймворк - это Джанга.
Turbogears - вообще чистый фреймворк.
А Друпал - да: CMS с уклоном в CMF.
Для примера - Joomla - чистая CMS без уклона.
Спасибо за ответы, а то я в этом большой ноль.
А как обстоит дело с расширяемостью, удобством программирования и отладки, наличием сторонних модулей?
" - Assembler vs Delphi - кто слышал про этот ассемблер?
- нельзя сравнивать, асм это более низкий уровень
- ну ты сболтнул про асм, я на асме антивирь накатал вчерась!"
это наш разговор, утрированно.
вы понимаете отличие между конфигурацией роутера системы, проектированием бд и подвязкой всего этого к mvc - в джанго и визуальной инсталляцией и cck друпала? не надо на слово "низкий" как на красную тряпку реагировать, не разобравшись о чем говорят.
аминь.
вот и разобрались.
никто ни с чем не просил р(о)внять.
Согалсен с авторами. Сраванивать друпал с Django не корректно. Django это удобный простой и очень мощный инструмент для создания веб-сайтов с нуля, тогда как друпал CMS, попытавшаяся стать универсальной для всех возможных задач.
По своему опыту работы с Drupal, CakePHP, Symfony, Pylons Django делает их всех в разы по всем параметрам (Структура фреймворка, парсер урлов, ORM, шаблонизатор, огромное количество встроенных библиотек и функций, кэш-бэкенд и т.д.). Иногда быстрее сесть и за пару часов склепать полностью Кастом сайт из своих или уже написанных кем-то приложений чем ковырять тонны "говнокода" друпала и ему подобных. При всём этом появляются следующие плюсы:
1. Кода становится в разы меньше. В большинстве случаев автоадминки хватает для всех задач и основным кодом становится HTML в шаблонах.
2. Чёткая структура фреймворка, не позволяющая сувать логику за пределы вьюшек и моделей.
3. Мощный и вместе с этим простой шаблонизатор.
4. Удобный ORM.
5. Отсутствие "Magic", когда вы не понимаете что откуда берётся, но практически полностью уверены, что "оно здесь должно быть"
В общем стоит учить, популяризировать и писать на нём сайты.
Есть проект,деньги, ищу консультанта по Pylons Django! Примеры "серьезных контор" не использующих связки PHP-MySQL в своих базовых сервисах убеждают. Жаль что пишущий, неизвестный мне гость.
Drupal никогда не пытался стать "универсальной" CMS. Во всяком случае, в коробочном виде. Он просто очень модулярный, что позволяет сделать многое.
Насчет django не знаю. Может оно такое замечательное, как вы говорите. Но если оно рассчитано на программистов, то не имеет смысла сравнивать его с Drupal'ом, который и обычный юзер может освоить и за те же пару часов сделать себе небольшой сайт.
А если спросить для конкретных задач ?
Например, чтоб e-shop поднять? Чо быстрее?
Джанга быстрее Друпала не в разы, а на порядки.
т.е чтобы друпал ускорить прийдется все его модули или ядро переписать с php на django?
Нет. Сразу на ассемблере...
Проблема не в том чтобы "переписать".
Где-то читал, что Дрис Байтаерт сказал, что он бы и рад уйти от php, но, к сожалению, это уже не реально. пруфлинк сейчас не найду.
Ну почему же? Он же на джаве по молодости зажигал.
есть какая-то Django CMS - её говорят в качестве админки используют для сотрудников офиса и для себя.
Еще одна CMS на GAE развиваться начала http://stackoverflow.com/questions/3680022/python-gae-social-network-cms
Если что - Гугль тоже очень много Питона использует в своих проектах....
Джанга - не похожа на Друпал.
В Джанге - много больше программирования при создании сайта. Это не плохо - гибкость больше, скорость работы сайта выше. Но не всем подходит, например - непрограммистам и заказчикам без бюджета точно нет.
Гуголь уже отказался от питона.
очень любопытно, а где про это почитать, что их не устроило?
Типа все переписывает заново?
Они помоему свой язык какой-то продвигают. GOO помоему
Не Goo, а Go. Смесь Си и Джавы. На питон забили, потому что не держит нагрузку в их инфраструктуре.
Ну это понятно. У них нагрузка то....
Только причем здесь новый язык?
Для нагрузки - компиляция полноценная или jit. От языка слабо зависит. Тот же Python в версии под Java куда как шустрее.
Чистый питон из коробки не компилится в JIT. Проект phyco не развивается.
При том, что гуглерам всегда мало имеющихся технологий: они развивают собственные и поэтому всегда на рубеже прогресса.
Что там еще развивать?
Разве что встраивать технологию Психа в мейнстримовый Питон.
Да и причем здесь "из коробки"?
Неужели Вы серьезно считаете, что спецы Google только элементарные стандартные вещи настроить могут? Что им проще язык создать, нежели завести Jython или написать "import psyco"?
Ерунда.
Все хитрее.
Если бы им не хватало производительности, то писали бы на Java.
Там вопрос явно политический.
Поглядел описание Google Go...
Простите, а какое там "замена Python"? Это языки для разных целей.
Все равно что Python заменяет Java, а Ruby заменяет Python...
Гвидо оказался мусульманином-шпионом?
Даю намек: в том числе и экономическим
Еще раз — Гугл официально заявил, что ушел с питона, потому что он не держит их нагрузку. Можете придумать сотню причин — экономических, политических, социальных, демографических — суть от этого не меняется.
Люблю беседовать с людьми, которые способны САМИ делать выводы.
Не люблю разжевывать.
С теми, кому нужно разжевывать - беседовать не интересно.
Вы верите официальным заявлениям коммерческих компаний? Не анализирую, не пропуская через фильтры?
Вернемся на твердую базу - техническую.
Я не по секретам ИТ-компаний специалист, а по ИТ-технологиям. И мне, как и любому программисту на этом форуме, прекрасно известно что формулировка "язык не держит нагрузку" не имеет никакого отношения к истине.
Не держать нагрузку может РЕАЛИЗАЦИЯ языка.
А уровней реализаций с точки зрения производительности всего нечего - простая интерпретация, исполнение байт-кода, JIT-компиляция, компиляция в машинные коды. И все они уже есть для Python.
Кроме того, Google широко практикует и Java, где с производительностью лучше.
Вывод - Google говорит не то, что соответствует действительности. Значит, подразумевают нечто иное.
Там не в производительности проблема: Андроид протолкнули, теперича протолкивают Go.
Разжевываю: Microsoft может начинать нервничать, да и Oracle, может статья, зря деньги за Java отдал...
В отличии от вас, я не накручиваю сверху тонны скрытого смысла, которого нет.
Эта фраза и далее по тексту сплошной бред.
JIT компилятор для питона (phyco) имеет массу недостатков, не работали с ним, не пишите. Его можно использовать только в редких случаях, применяя к отдельным функциям. Оверхед памяти от него зашкаливающий.
Ваша осведомленность насчет событий между крупными компаниями роли в этом вопросе не играет.
"То, чего я не знаю - не существует" - шибко дрэвние грэки.
Вас это удивляет? Вы знаете у кого существует JIT-компиляция без расхода дополнительной оперативной памяти?
Или Вы всерьез думает, что Google экономит на оперативной памяти как Вы на своих хостингах?
Да и не Психом единым. JVM работает стабильно. Но это уже художественный свист.
Аргумент-то в другом: то что язык и его реализация - разные вещи. Проблемы Psyco с языком не связаны. Незачем менять язык (оставаясь в рамках той же парадигмы - "небрежное отношение к переменным"), чтобы оптимизировать использование памяти.
Разжевываю еще раз: язык и реализация - это разные вещи. Была бы проблема в производительности - то Google громогласно заявила бы о разработке супер-Python на базе идей из того же PyPy, со своей виртуальной машиной. Решила бы и вопросы производительности и GIL и ускорила бы кучу уже работающего кода.
Для решения вопросов производительности незачем Google уходить от Python и делать язык того же уровня, что и Python и Ruby.
Сделала бы Google язык навроде Python или Ruby со СТАТИЧЕСКОЙ типизацией - тут бы я поверил, что планируется сурьезная оптимизация производительности. А так: шило на мыло меняют. Но на мыле будет стоять свой (с)opyright.
Ребята хотя контролировать рынки.
Двигают Андроид и etc.
Мне уже давно ясно, что вы мыльный пузырь, от которого можно ждать только туманных намеков, т.к. знаний нет.
Что такое JVM, JIT, Jython и тд я знаю не понаслышке лучше вашего, т.к. в питоне не один год.
Вы предлагаете идиотический дилетантский метод: вытягивать низкопроизводительный язык костылями, вместо того, чтобы отдать предпочтение более мощным решениям.
Т.е. если весь код тормозит, давайте скомпилим его в джаву? А почему бы тогда сразу на джаве не написать?
И причина, по которой гугл так не делает, покрыта тайной: политический подтекст.
Пиздец, вам в передачу Малахова пора.
Я Вам все уже разжевал. Не понимаете - учитесь, читайте. Человека нельзя научить. Человек учится сам. Толчок я Вам дал.
С Питоном не первый год? А что Вы с ним делаете?
Стоите на месте, судя по всему, не развиваетесь... С Питоном не один год, а так и не понимаете, где у него затыки по скорости.
Я могу ошибаться, заблуждаться, то пишу свои мысли развернуто, с техническими доводами, которые может проверить любой компетентный (ну или настоящий) программист.
Вы же никаких доводов окромя эмоциональных и "одна бабка сказала" (в смысле - заявление Google) не приводите. Если Вы давно с Питон и хорошо разбираетесь как ИМЕННО устроено выполнение программ, то почему Вы не так и не написали ни одного ТЕХНИЧЕСКОГО довода.
А ваш основной довод - что некий язык программирования является узким местом - так это просто смешно. Подавляющая часть самых быстрых в мире программ пишется на C/C++. Одновременно с этим оба этих языка являются одними из самых неоднозначных и сложных языков программирования. Тем не менее программы, написанные на них почему то быстры.
Если Вы программист, то прекрасно знаете истину: язык программирования НЕ ВАЖЕН на этапе выполнения программы. Язык программирование - это всего лишь способ довести до процессора компьютера мысль программиста. В момент же выполнения программы НИКАКОГО языка программирования УЖЕ НЕТ.
Процессор выполняет программу в машинных кодах и ТОЛЬКО ее и понимает исключительно свой язык - инструкции процессора...
Если Вы программист и до сих пор не знаете этого - мне Вас искренне жаль...
Не первый раз пишу здесь: тормозит не язык, а всего его реализация тем или иным способом.
А теперича подумайте сами - что мешает программе на Питоне выполниться максимально быстрым способом - в машинных кодах?
Примите толчок от меня — убавьте высокомерие и не пишите чушь.
Кроме тайных намеков я от вас так и ничего и не добился. Во всех комментариях вы игнорировали аргументы и увиливали.
Пишу на нем, Кэп.
Слепой? Для кого я писал про психо выше?
Собственно, от вас вообще техническими знаниями не пахнет, одна абстракция.
Напишите мне, как вы будете тюнить проект, написанный на CPython, когда упретесь в производительность? Навтыкаете везде phyco? Напишите пример кода.
Остальную часть коммента оставлю без комментариев, ибо вода. Расскажите школьникам на уроке информатики. Жалеть надо вас, поскольку полностью соответствуете своему нику.
Я не матерюсь в отличие от Вас... Как не стыдно...
Вроде я все по-русски писал. Если чего непонятно - спрашивайте.
Тормозит?
Вы обратили внимание - в каком именно месте тормозит?
Что говорит профайлер?
В реальной жизни высоконагруженные веб-сервисы затыкаются (я не о масштабах Гугла говорю, а о крупном сайте уровня photosight.ru или club.foto.ru - это для примера, неважно на чем они написаны) много раньше, чем проект упрется в производительность классического интерпретатора Питона.
Прежде, чем Вы упретесь рогом в ограничения классического интерпретатора Питона Вам нужно разрулить ваши отношения с кэшем, БД и построением странички по шаблону.
Вопросы разработки структуры БД, быстрого общения с ней - это вообще проблема программиста в любом проекте и Python тут не причем.
Правильная работа с кэшем - какие странички или куски страничек генерить каждый раз заново, а какие просто брать из кэша - это проблема любого веб-программиста, а не только программиста на Python.
Единственное узкое место, где Python может не сдюжить - рендеринг. Предполагается, что Вам известно, что на высоконагруженном сайте следует использовать компилирующий шаблонизатор.
В общем случае глянуть и настроить компоненты, не относящиеся к Питону - примерно в том порядке как написано:
а) Кэширующий прокси сервер ДО Питона.
б) Обработку URL статики проводить ВНЕ Питона.
На Питоне:
в) Кэшируем что можно и что нельзя.
г) Снимаем нагрузку с БД с помощью Redis, Memcached...
БД - напоследок, ибо если допущена ошибка при проектировании, при продумывании структуры БД, то исправлять слишком уж трудоемко:
д) Смотрим - не поменять ли структуру БД, смотрим планы запросов, смотрим - нормально ли все дело с индексами.
И вот только тут начинается Психо, а еще лучше Jython
е) Если приведенные выше шаги не привели к результату, то проблема действительно с производительностью среды выполнения программы на Питоне.
Подавляющая часть тормозов - не в Питоне, а в головах разработчиков. И большую часть ошибок можно избежать сразу, когда еще закладывается общая программная структура сайта.
То есть Вы не понимаете чем отличается язык программирования от СРЕДЫ выполнения программы? Даже после того как все разжевано?
Я же писал, что люблю беседовать с разбирающимися в теме специалистами.
Есть такой метод отладки программы:
В программе есть баги, внесенные не преднамеренно.
В программу искусственно сажаются баги. Поскольку они сажаются преднамерено - число их известно.
Программисту, не имеющего отношения к багам обычным и багам преднамеренным дают программу на рассмотрение.
Он вылавливает баги подряд - и искусственно подсаженные и внесенные не преднамеренно.
По тому, какую долю преднамеренно посаженных багов выловил программист и по тому сколько обычных багов он выловил вычисляется - а сколько еще багов обычных в программе осталось.
Так вот: я внес в мои тексты выше пару преднамеренных ошибок, которые специалист в теме легко бы просек.
Разумеется, Вы бы с удовольствием меня ткнули бы в мои ошибки. Если бы СМОГЛИ БЫ НАЙТИ ошибки. Но для этого НУЖНО быть в ТЕМЕ.
Собственно, Вы не программист, а "кодер".
Я доволен - таких как Вы много, конкурентами в сложных проектах (там где очень много платят) такие как Вы станут еще очень не скоро.
Оффтоп: забавно, но тот, кто говорит "Вы" с большой буквы в споре в заведомо проигрышной позиции.
Где в другой стране, где не принято писать обращение на "Вы" с большой буквы - возможно.
В России - это обязательно по правилам русского языка.
Проскроль выше, я пишу именно про Гугл, т.к. тема началась с Гугла, а ты съезжаешь с темы. Перечитай тред, с чего началась дискуссия: гугл ушел с Питона, потому что уперся в производительность интерпретатора. Это их официальное заявление.
Напиши в гугл письмо: братцы, вы идиоты, т.к. вы не кешируете и не ставите психо.
Я — разработчик. А ты — дилетант или какой-то манагер, который только умеет ездить по ушам. Советую научиться вести дискуссию, не сливаться от аргументов и читать поменьше желтизны.
Я умею материться.
Только не считаю, что технический спор следует вести эмоциональными терминами.
Увиливайте.
Ваш вопрос был вполне конкретным: что делать МНЕ когда Python упрется в ограничения. Я в Google не работаю, у меня или у Вас они советов спрашивать не будут.
Вы уж прочитали бы сначала, что пишут ведущие разработчики Google об ограничении использования Питона в Google:
http://groups.google.com/group/unladen-swallow/browse_thread/thread/4edb...
прежде чем выдумывать.
1. В частности там написано: не ушел с Питона, а ищет альтернативные решения. В частности - ускорение старых программ на Питоне за счет перевода на LLVM (то, о чем я Вам писал выше - когда требуется быстрая работа, используется виртуальная машина, только я писал о JVM).
2. Рекомендуются несколько раз подумать, прежде чем начать использовать Python в новых проектах. Но признают, что деваться на сегодня ПОКА ЕЩЕ некуда.
Что говорит о том, что Go - не рабочий пока и на нем они не пишут реальные вещи пока еще. Собственно, это же написано на официальном сайте Go.
Я написал про Психо - наоборот. То есть Вы не читаете меня, а просто выдумывайте из головы.
В смысле даже не со мной, а с собой?
Я могу подтвердить свои слова о рекомендациях использовать те или иные технологии.
А чем Вы можете подтвердить свои слова о том, что я дилетант или менеджер?
То, что я менеджер Вас ввело в заблуждение наличие готового рецепата и отсутствия должного уровня вашей квалификации.
Вы даже представить себе не могли, что подавляющая часть возникающих в вашей работе проблем по производительности программ имеет решения, придуманные еще в прошлом веке.
Достаточно просто формально выполнять эти рекомендации - и ваша программа уже не заткнется неожиданно.
P.S.:
Многоуважаемый господин "я все знаю, но никому свои технические знания не продемонстрирую, потому что мне нечего сказать по теме вопроса, а есть только эмоции" - учитесь, учитесь и учитесь. Вы еще не программист.
P.P.S.:
На сегодня на самом официальном сайте категорические не рекомендуется использовать язык в production.
Что противоречит вашему первичному утверждению: что Гугль УЖЕ отказался от Питона в пользу Go.
Я допускаю, что когда то на Go будут писать код для веб-сайтов. Но не сегодня.
И они правы - посмотрите хотя бы на убогую реализацию регулярных выражений. Рано еще уходить от Питона и Java.
А сам язык Go мне нравится чисто синтаксически...
Хороший холивар.
Добавил в закладки.
Был бы холивар...
Какие нибудь аргументы по теме...
У моего оппонента все сводится к следующему:
1. Раз Гугль сказал, значит так оно и есть.
Что за слепая вера печатному слову? Когда большинство людей не умели читать - то буквы воспринимались как магия, вспомните руны. Но - сейчас?
Люди должны думать СВОЕЙ головой. Иначе они не заслуживают звания "sapiens"
2. Ссылок на слова Гугля (на "официальное заявление") мой оппонент не привел.
Я привел ссылку на те слова - см. выше.
Оказывается - Гугль считает иначе, чем мой оппонент.
Не полностью иначе, но все же не так.
3. Он много лет с Питоном и по его мнению - Питон медленный до безобразия.
Все что он мог привести из своего опыта по теме - ускорение по технологии psyco.
Замечу - это для очень ленивых и глупых программистов, потому как все ускорение включается добавлением всего пары-тройки строчек в каждый файл программы.
При этом он отчего то решил, что ускорение получит задаром. В смысле - расход памяти ему не понравился.
Хотя так и должно быть - или нагрузка на процессор или нагрузка на оперативную память, на выбор.
Замечу, что правильно оптимизированный веб-сайт требует кучу оперативной памяти под сервер баз данных и под memcached/Redis/аналоги.
На фоне затрат на оперативную память сервера баз данных и memcached/Redis/аналогов затраты оперативной памяти на psyco - просто смехотворны.
Вывод - человек не понимает сути оптимизации производительности.
Оптимизирует неверными методами на хостинге с крайне небольшими ресурсами.
Закономерно обломился.
Что за проект такой, который нагружен, требует скорости Python, но не может себе позволить на хостинг тратить хотя бы 700 рублей в месяц?
Интересно, а зарабатывает этот человек хотя бы 17 000 рублей в месяц, если уж ему жаль 700 рублей на хостинг?
4. Мой оппонент вообще никак не реагирует на внешние раздражители (аргументы по теме), понятные любому настоящему программисту (то есть не техническим языком, а токмо эмоциями)
Я предложил вполне адекватные и прекрасно показывающие себя методы оптимизации - кэшировние ВНЕ Питона и кеширование С Питоном, хранение в memcached/Redis, оптимизация БД, прокси-сервер снимающий нагрузку, обработка статики вне Питона, использование JIT (JVM).
В ответ получил всего-навсего описание одного малосущественного на современных компьютерах минуса оптимизации с psyco.
Очевидно, что psyco - это единственное, что он пробовал (или просто прочитал где то статью такого же неудачливого недопрограммиста). Про остальное он даже теоретического понятия не имеет, потому стремается вступать к конструктивную дискуссию.
Вернемся к Drupal:
1. У Друпала есть одно-единственное сурьезное преимущество перед Python - часть сайта, которая отрабатывает шаблон у Drupal, благодаря PHP. Добиться хорошей шаблонизации на Python - сложнее.
А вот в реализации бизнес-логики - преимущество на стороне Python. Писать и оптимизировать программу, не выводящую HTML-теги, на нем проще и удобнее.
Не зря некоторые высоконагруженные сайты генерят странички на PHP, а бизнес-логику реализуют на Python.
2. Кстати, если кому интересно, - для Друпала использую примерно те же самые методы оптимизации. Единственно, что Друпал так сильно не изменишь, в частности структуру БД, но большая часть описанной выше оптимизации для Drupal применяю.
На определенном этапе развития сложного сайта становится удобнее перевести сайт с CMS Drupal на Python с BFG (хоть и существенно больше пишется ручками).
Django не рекомендую - не тот уровень возможной оптимизации. Слишком уж Django сковывает.
В смысле - скачок от Drupal к Django мне представляется не столь существенным.
Если сразу же создавать сайт на Django - тогда, да.
А если уж выжали из Drupal все, то имеет смысл смотреть на более custom'изируемую базу - ту же BFG, например.
ИМХО, конечно.
Если сроки сжаты и бюджет не велик, то Django - большой плюс.
с чего это вдруг? для python, вроде как, существует стая шаблонизаторов, на любой вкус. с xml и без. и все такое...
Вопрос не о том - есть или нет шаблонизаторы, а про производительность.
Питону трудно тягаться с специализированным решением, каким является PHP:
Взято отсюда:
http://code.google.com/p/spitfire/
hannosch:spitfire hannosch$ python tests/perf/bigtable.py
Genshi tag builder 671.49 ms
Genshi template 493.39 ms
Genshi template + tag builder 714.04 ms
Mako Template 74.78 ms
ElementTree 299.03 ms
cElementTree 179.47 ms
Cheetah template 58.67 ms
Spitfire template 65.32 ms
Spitfire template -O1 40.19 ms
Spitfire template -O2 15.99 ms
Spitfire template -O3 16.02 ms
Spitfire template -O4 11.09 ms
StringIO 80.85 ms
cStringIO 16.52 ms
list concat 12.93 ms
hannosch:spitfire hannosch$ python
Python 2.4.5 (#1, Jul 20 2008, 12:34:19)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
>>>
Two more examples from the Zope / TAL world:
hannosch:z3c.pt hannosch$ bin/py benchmark/benchmark/bigtable.py
z3c.pt template 25.43 ms
zope.pagetemplate template 564.55 ms
For comparison, here are two samples from PHP.
hannosch:spitfire/tests/perf> php4 bigtable.php
Smarty template: 21.04 ms
PHP: 12.01 ms
hannosch:spitfire/tests/perf> php5 bigtable.php
Smarty template: 13.16 ms
PHP: 6.24 ms
Вы своей тупостью провоцируете на эмоции, не удивляйтесь.
Пиздёж. Где вы прочли, что я вас об этом спрашивал? Процитируйте ту часть того комментария, где я писал — что МНЕ делать, когда...?
По пунктам 1 и 2
Во-первых, тред старый, 2009 год, во-вторых, из ваших же слов вытекает, что старые проекты еще будут как-то крутиться на питоне (под JVM, например), но в новые нагруженные проекты, такие как Wave, его (Python) не возьмут. А потом, возможно, и старые переведут на Java/C++.
Кто вам дает рекомендации? Гвидо? Медведев? Вы в туалет тоже по рекомендациям ходите? У нет своего опыта, отсюда страсть к рекомендациям, стандартам и тд.
Нет, не это, а игнорирование неудобных вам аргументов и съезжание с темы. Я сходу чую, когда оппонент треплется попусту.
Вопрос: где я писал, что отказались именно в пользу GO? Вы это выдумали. Я писал, что одновременно с отказом Гугла от питона начал развиваться язык GO. Хватит переиначивать мои слова.
Прекрасно известно, что на эмоции переходят, когда заканчиваются аргументы
Попытка переиначить смысл слов, не Вам, а именно мне.
Вот что Вы писали:
Опубликовано kyky в пн, 24/01/2011 - 13:45:
"Напишите мне, как вы будете тюнить проект, написанный на CPython, когда упретесь в производительность? Навтыкаете везде phyco? Напишите пример кода."
а) А Go когда начали делать по вашему? В 2010, что ли?
б) Судя по всему Вы не осилили английский язык, ибо кроме дат ни к чему придраться не можете
в) Я привел ссылку, текст по которой наиболее близок к тому самому пресловутому "официальному заявлению Гугла об отказе от Питона", на которое Вы ссылаетесь.
Ежели Вы знаете более верную ссылку - приведите ее.
Пока считает ваши слова сливом - ибо Вы ссылаетесь на то, на что не даете ссылок.
В отличие от меня
а) Простите, не из моих слов, а из слов ведущих разработчиков Гугля по приведенной выше ссылке
б) Осильте все таки приведенный мною текст на английском. Там не совсем так написано. Они напирают вовсе не на JVM.
Я понимаю, что человеку с недостаточной квалификацией и верящему тому, что пишут корпорации и не умеющему анализировать технические тексты в своей сфере деятельности трудно представить, что можно и самому думать своей головой.
Так чем Вы можете подтвердить свои слов. Окромя сортирного юмора?
Было бы интересно почитать ссылки на умные мысли серьезных разработчиков, которые НЕ рекомендуют делать того, что написано было у меня выше.
Пока я заметил, что неудобные аргументы - игнорируйте Вы.
Если хотите аргументировано то давайте - технически аргументировать, а не эмоции. По пунктам.
Из того, что можно считать аргументацией ТЕХНИЧЕСКОГО, а не эмоционального свойства с вашей стороны было только, что "psyco любит покушать".
1. Давайте подробно про этот ваш аргумент:
Я уже писал, повторюсь, что нормальная оптимизации, которая дает хороший эффект еще ДО включения Психа - дать памяти серверу баз данных. Если уж у БД достаточно оперативки, то Психу - тем более достаточно.
Если нагрузка шибко велика, то все равно придется заморочиться и переписать программу более существенно чем "import psyco", - научить программу работать с memcached/Redis/аналогами - то, очевидно, что памяти на сервере нужно еще больше и в этом случае о том, что Псих любит покушать можно вообще - забыть.
Если же проект стал популярны не неожиданно, а планировался таки изначально, то ситуация еще лучше.
Поскольку для подавляющего числа нагруженных веб-серверов использование memcached/Redis/аналогов дает существенный прирост производительности, то грамотный программист, которому заранее известно, что веб-проект будет сильно нагруженным, может СРАЗУ предусмотрит использование этой технологии. И к тому времени, когда понадобится psyco - проблем с лимитом памяти на сервере не будет вовсе.
2. Другие ваши аргументы сводятся к эмоциональной оценке (личным оскорблениям) меня и моей квалификации. Аргументом с моей стороны должны служить ответные личные оскорбления? Считайте что Вы их получили. Позориться публично с матерными словами - не желаю.
3. Третьи ваши аргументы (с которых и начался этот сыр бор):
То, что Гугль "официально заявляет от отказе от Питона". Обратите внимание - вы писали "ОФИЦИАЛЬНОЕ зявление от ОТКАЗЕ и ПЕРЕХОДЕ на Go".
Я привел ссылку, близкую к этому. Возможно, именно слышав краем уха из третьих уст, то, что написано по этой ссылке, Вы и решили про "заявление об отказе".
А там же всего лишь:
а) Описание серьезности проблемы, то что классический Питон слишком медленный.
С этим и не спорю.
Не согласен, что это проблема языка.
Это особенность интерпретаторов любых языков вообще, а не проблема одного Питона КАК ЯЗЫКА в частности.
Вы же пишете что "Питон тормоз как язык", я же пишу, что дело в РЕАЛИЗАЦИИ языка и в СРЕДЕ выполнения.
И проблемой производительность не является при использовании компилятора, а не интерпретатора не является. Для любых языков. Не только для Питона.
Как промежуточный вариант, имеющий очень большое практическое значение для решения проблемы производительности - использование JIT. Получается полуинтерпретация-полукомпиляция. Ну и соответственно - частичное решение проблем производительности.
Однако поскольку в этом промежуточном варианте программа на Питоне (и любом другом языке) не самостоятельно, а контролируется JVM, LLVM или т.п., то данный вариант и используют в production. Стабильность дороже производительности.
И именно поэтому одним из вариантов решения проблемы производительности (по ссылке приведенной мною) с точки зрения ведущих разработчиков Гугля является развитие именно виртуальной машины.
Язык Go, программа на котором компилируется и исполняется непосредственно в среде ОС призван решить другие проблемы - там где производительность критичнее.
А риски нестабильности решаются умным управлением памятью, встроенным в Go (если что - построенным по тем же принципам, что и управление памятью в JVM и в классическом Питоне) и обращением к более квалифицированным программистам.
Массовой технологией создания веб-сайтов это не является - Go позицируется как "язык системного программирования", о чем и написано на официальном сайте Go.
Go - занимает другую нишу нежели Питон в создании сайтов - на Go будут создаваться сервисы типа той же Кассандры или, база навроде фреймворков, к которым в свою очередь обращаются программисты создатели сайтов, пишущие на Питоне и т.п..
б) по ссылке выше всего лишь РЕКОМЕНДАЦИИ для новых проектов обходиться без Питона (при этом НЕТ рекомендаций переходить на Go) и нет ОФИЦИАЛЬНОГО заявления об категорическом ОТКАЗЕ от Питоне.
Жду ссылок, на официальную позицию Гугля, подтверждающую ваши слова об "отказе Гугля от Питона в пользу Go"
Пожалуй да:
Опубликовано kyky в вт, 18/01/2011 - 23:05:
Уже?
"Да как же тебя прикажешь понимать, ежели ты молчишь"? - фильм "Иван Васильевич меняет профессию"
Признаю, неверно трактовал ваши туманные слова. Если хотите быть понятым, а не обсмеянным - то выражайте свои мысли однозначно.
Вы писали:
1. Google УЖЕ отказался от Питона по причине производительности.
2. Про использование Java отозвались скептически для высокопроизводительных решений.
3. Текст про порог вхождения программиста исключает C++
4. Одобрительно отозвались о новой разработке - Go.
5. Что там еще остается из высокопроизводительного, на что УЖЕ перешел Гугль, отказавшись от Питона?
Тред спутался... Отвечаю в порядке поступления.
Я читал об этом в блогах гуглеров. Они так и пишут: НАМ НЕ РЕКОМЕНДУЕТСЯ ИСПОЛЬЗОВАТЬ ПИТОН В НОВЫХ ПРОЕКТАХ. Из вашей ссылки вытекает то же самое. Вот что пишет Collin Winter:
Намек понятен (с)?
Пиздежь. Я так не писал. Я спрашивал, что вы будете делать, когда упретесь а производительность интерпритатора.
Вы опять сочиняете. В треде я ни разу не писал о том, что речь вообще идет о МОЁМ сайте. Я писал с точки зрения Гугла — у них проекты хостятся не за 700 рублей.
С чего вы взяли, что с этими технологиями не знаком? Кешем, оптимизацией БД вы меня не удивили. А вот В ТОЙ ССЫЛКЕ, ЧТО ВЫ ЖЕ САМИ ПРИВЕЛИ, гуглеры пишут, что чрезмерные усилия по оптимизации слабых мест приложений снижают понимание кода, поднимают уровень вхождения для других разработчиков.
Учитесь читать!
Вот тут вы раскрыли всю свою дилетантскую сущность, поздравляю. Любая шаблонная система для питона, та же Джинжа2 или tornadoweb уделывает Дру по полной. Они поддерживают передачу функций как объектов, виджетов, регионы, наследование и тд. Советую вам на эту тему (шаблонизация Друпала vs Питон) даже не заикаться. То, что PHP вырос из HTML-шаблонизатора, еще не сделало его в в этом лучшим.
Будьте внимательнее при комментировании. Вы весь тред грешите тем, что приписываете ваши больные утверждения мне.
"Не рекомендуется использовать" как написано у Гугля, и "уже отказался" как пишете Вы - это разные вещи.
Тут они пишут, что у Питона есть ограничения по производительности.
Это мы с Вами и без них знаем.
Правда Вы ссылаетесь, на то, что проблема в ЯЗЫКЕ, а я - что проблема в РЕАЛИЗАЦИИ ЯЗЫКА.
Там же предлагаются пути решения - статическая типизация, повышающая трудозатраты программиста (как и переход на Java, к слову) и виртуальная машина (типа JVM), которая по их мнению перспективна.
Это просто: с вашей стороны технические аргументы не были приведены.
Следовательно - не знакомы.
Ну или знакомы, но не смогли разобраться с целью адекватного применения в своих проектах, что вынудило Вас начать утверждать, что Питон тормоз.
Ежели бы применяли на практики, то до тормозов собственно Питона дошли бы еще очень не скоро.
Там написано по сути следующее:
В частности и Гугль практикует малоквалифицированных программистов, а не только ваши заказчики.
Это само собой - деньги все экономят. Если программисту можно платить меньше, то следует этим воспользоваться.
Даже если есть проблемы в производительности. Дешевле один раз купить очередной сервер, нежели постоянно кормить программиста.
Тем более, что компьютер работает стабильнее человека.
Вполне здравый подход.
Я Вам даже подскажу Spitfire. Если Вы на Питоне пишете и хотите добиться максимальной производительности шаблонизатора - Вам должно быть интересно.
Я, простите, не писал, что все CMS Drupal в сборе благодаря PHP быстрее ЛЮБОЙ системы на Python.
Для такого сравнения нужно вычленить из Drupal шаблонизацию и рассмотреть ее отдельно.
Ибо сравнивать нужно сопоставимые системы.
Если уж Вы сравниваете голый шаблонизатор, то сравните jinja2 с Smarty.
Если уж сравнивайте Drupal - то сравнивайте с такой же по уровню CMS на Python.
Выше написано: что я рекомендую Drupal для начала, когда бюджет и время не позволяют разрабатывать custom'ные решения.
По мере развития проекта (или сразу, если речь идет о серьезном проекте) - более перспективными мне представляются заказные решения на базе Python.
Самым узким местом для проекта на Питоне будет шаблонизация. Именно шаблонизация у PHP решений (в частности у Drupal) хорошо работает. Тормоза у Drupal - прежде всего в замудренной внутренней логике.
До определенного этапа это не критично - не смотря на таблицу сравнения производительности систем шаблонизации, где видно явное преимущество PHP, за счет более эффективной реализации внутренней логики заказного решения на Python сколько-нибудь развитая CMS на PHP (типа Drupal) с тормозной внутренней логикой (тормозной по причине универсальности CMS) будет отставать от заказного решения на Python. Ну если программисты не полные идиоты.
А вот когда начнется столь интересующий Вас затык Питона про производительности, а начнется он (после оптимизации работы с БД, кэшем и после подключения memcached/Redis/пр.) именно в обработке Python шаблонов, то есть в jinja2, к примеру - то тут и может помочь PHP для шаблонизации. При том, что внутренности могут быть на Питоне даже без psyco или JVM.
Ну это как вариант, показывающий - в каких случаях лучше шаблонизация на PHP, а в каких на Python целесообразно. Разумеется, не обязательно поступать именно так - можно оставаться в рамках Python и jinja2, а попробовать ускориться тем же psyco.
Еще раз - "на балконе стояла мама и ваза с цветами".
Ваше сравнение сопоставление "(шаблонизация Друпала vs Питон)" не корректно в принципе.
Сравнивать следует сопоставимые вещи.
Все это наследование и виджеты - очень хорошо и удобно.
Но если мы с Вами говорим о проблемах производительности - от фантиков отказываются.
Это слова дилетанта и нуба. В плане шаблонизации вам учиться и учится. И весь ваш богатый запас умных терминов пролетает мимо.
Во-первых: в приведенном списке не все шаблонные системы. Я не вижу Джинжи, Django, WornadoWeb. Без них сравнение не имеет смысла.
Во-вторых: скорость шаблонной системы должна соотноситься с ее удобством. Я уже писал выше, какие классные фишки поддерживает та же шаблонная система веб-фрейморка Tornado, да и Джанга хороша. И пусть шаблон генерится в два или три раза дольше, потому что его результат всегда можно (и нужно) закешировать. А эти милисекунды никому нахер не сдались. И это приходится объяснять человеку, который считает себя спецом в IT? Очень сильный прокол: если бы вы кешировали шаблоны, то подобной фразы от вас просто не прозвучало.
Мне остается только посчитывать ваши сливы.
Сливы - это там где Вы не утруждаете себя разобраться в тематике, а выражаете свои эмоции - и ничего более.
Шаблонизатор Django - по производительности не конкурент тому же Spitfire, который сопоставим с Smarty:
http://habrahabr.ru/blogs/django/49636/
Если уж речь о производительности, то можно включить в рассмотрение и чистый PHP - без наворотов, только как шаблонизатор.
Должна. Но это очень субъективный показатель.
Производительность - много проще.
Выше есть цифры - на них можно как то опираться.
Удобство заочно не измеришь. Тем более, что задачи, под которую шаблонизатор используют, могут быть очень и очень разные.
Посему обсудить удобство сколько нибудь объективно у нас здесь не получится.
Джанга хороша прежде всего тем, что она Джанга, что это не один только шаблонный движок.
Про Торнадо подозреваю - то же самое, интеграция с прочими компонентами фреймворка - это дополнительное удобство.
В этом смысле выбор чаще всего таков:
Или быстрее и проще и удобнее пишется программа,
Или быстрее работает программа,
Или дороже железо, на котором программа выполняется.
Вы же писали, что у Питона все плохо по производительности?
Все же считаете, что удобства разработки - важнее?
Ну не всегда. Попробуйте закешировать страничку покупателя в интернет магазине. Когда есть страничка, где товар еще не в корзине и точно такая же, где часть товара на страничке показанного уже в корзине.
Реализуемо, конечно, но не тупой кэш, который можно было бы минуя Питон отдать через сервер, быстро обрабатывающий статику.
Там не миллисекунды, если верить тестам.
Поскольку Вы все на масштабы Гугля киваете - там и эти доли важны.
Вы когда нибудь разрабатывали сайты, в которых поведения сайта зависит от действий конкретного посетителя?
Сайты, ориентированные токма на анонимусов - вообще можно статикой делать. Самое умное что придется запрограммировать - это корректное обновление статических страничек....
Да и тупо закешировать такие сайты - большого ума не нужно.
Поскольку речь у нас в треде идет про Гугл, я задал этот вопрос с точки зрения Гугла, т.е. как оптимизировать высоконагруженное приложение Гуглу, когда кеширование и оптимизация БД уже есть? Вы банально переиначили смысл сказанного. Я не спрашивал, как мне тюнить мой сайт, это я знаю и без вас.
[/quote]
Формулируйте свои мысли лучше. Спрашивали, что Я будут делать.
Не Вам и не мне давать советы Гуглю, да еще не привязанные к специфики конкретного проекта.
Это даже в исследовательских целях бессмысленно.
Там "рекомендации для новых проектов воздержаться от Python", а не "официальное заявление об отказе".
Что вовсе не подтверждает вашу позицию.
Так же там ортогональное вашему утверждению обсуждение плюсов и минусов различных оптимизаций программ на Питоне, от которого "якобы УЖЕ ОТКАЗАЛСЯ ГУГЛЬ"
Что также не подтверждает Вашу позицию об отказе Гугля, а скорее наоборот - если думают в этом направлении, значит, считают, что шансы у Питона есть.
Считайте, что я даю, так проще.
Желаете опровергнуть - милости прошу с технической аргументацией.
Эмоции ваши для спора - бесполезны. Учитесь абстрактному мышлению - программисту сие полезно.
Угу. Пока выше по тексту Вы признались, что обломились с psyco.
Решили на системе с недостаток оперативной памяти по чужим рекомендациям, не вникнув в суть?
Или пропустили тот абзац, где в тех рекомендациях по которым Вы пытались - было про оперативную память?
Вы не въезжаете вовсе.
Видимо потому, что Псих - это единственное что Вы пробовали, вот к нему и сводите разговор.
Психа в общем случае я не одобряю, это костыль, полумера - об этом я выше уже писал неоднократно. Хотя и довольно дешевая полумера по внедрению в готовый проект.
Для мало зарабатывающих и неквалифицированных недопрограммистов - вполне подходящая метода.
Были бы аргументы, а то все больше - эмоции.
Признайтесь - Вы девушка?
Вы опытный форумный троль? Знаете как нужно писать?
"Не рекомендует", а не "не возьмут" - это разные вещи.
Официальное заявление - это несколько иное.
В принципе официальная позиция может быть и в блоге озвучана, не такой уж принципиальный момент, чтобы лично руководство Гугля подписывала официальные бумаги под этим заявлением.
При официальном заявлении об ОТКАЗЕ от Питона должно быть написано: "Все, мы все ушли на язык X, на Питоне ничего не делаем более, только баги в старых проектах правим".
Написано же: мы думаем, как побороться с узкими местами Питона, и по возможности обойтись без него.
Не более того.
Я думаю, что любая фирма, разрабатывающая веб-решения серьезно нагружающие сервера - так же решила бы, было бы куда уходить и были бы бюджеты времени и денег.
Вы говорите "А", и не берете на себя ответственно сказать "А" до конца.
Так куда все таки уходит Google?
На очень засекреченный язык?
По сути, одно и то же.
Крайне глупый аргумент. Если в этом треде я не пишу про шарп, это не значит, что с шарпом я не знаком.
Я вам даже подскажу джинжу, мощнейший шаблонизатор.
Мьсе не умеет кешировать?
Поздравляю, вы теперь сами себе противоречите. Вы сами начали сравнивать шаблонизацию Друпала и Питона, я указал вам на превосходство второго. Слив.
В реальной жизни действует не только бинарная логика.
Если УЖЕ ушли, то УЖЕ на чем то работают КОНКРЕТНОМ.
Если НЕ РЕКОМЕНДУЮТ, то дают программистам фору - можешь, пиши на Java, хочешь, рискни с Go, не можешь, оставайся с Python.
Это не одно и то же, по сути.
Сходные утверждения - не более того.
Если Вы здесь только как читатель - тогда да.
Если что то пытаетесь из себя изображать - было бы интересно почитать аргументацию.
Насчет Шарпа - понятно, он ни к Гуглю ни к большинству на этом форуме отношения иметь не может.
1. Вопрос был в производительности.
При чем тут jinja2?
2. Навороченность шаблонизатора не есть безусловный плюс.
Кроме вопросов производительности возникает соблазн смешения дизайна и программирования.
Сие безусловно полезно только для маленьких проектов. Когда программист один он же дизайнер.
Это собственно самый большой недостаток PHP и JSP, зачем повторять чужие прекрасно известные ошибки?
Я писал, что должно быть сделано, прежде чем упретесь рогов в тормоза Питона. Кэширование было ДО.
Простите, давайте и я придерусь к словам.
Поставьте Drupal - получите сайт, который останется только заполнять содержимым.
Поставьте голый Питон + голую jinja2 + шаблоны конечно же - не получите даже "Hello, world!"
Нет, сливы — это когда я рассчитываю получить внятный ответ, а получаю нечто невразумительное.
Это !!!__КРИТИЧЕСКИЙ__!!! показатель, потому что закешировать шаблон можно всегда, а добавить на сайт новый виджет, слайдшоу, социальный плагин - может вылиться в такую проблему, что трижды проклянете свою шаблонную систему. На той же джанге приходится писать свои теги и фильтры на каждом углу, я лично после одного такого проекта перешел на торнадо.
Эти цифры абсолютно ни о чем не говорят, им верят только дилетанты вроде вас. Профессионал никогда не выберет инструмент только потому, что в каком-то тесте он набрал на 6 милисекунд больше.
У вас опыта. Вы не слышали о том, что кешировать можно отдельные части шаблона? Записывайте рецепт: кешируется вся страница за исключением основной части. Т.е. если мы на странице корзины, то шапка, подвал, меню, блоки, виджеты, реклама и тд. берутся из кеша, а в середину вставляется таблица товаров, полученная из бд. И тогда на рендер уйдет гораздо меньше времени. В джанге и торнадо это реализуется проще простого.
Да. И если рендер становится узким местом, то применяю описанный выше метод.
Тады формулируйте ваши утверждения как утверждения, а не как тренировку для телепата.
Верно.
Собственно потому Гугль и не может так просто отказаться от Питона.
Удобство - важнейший козырь ЗА сложную систему шаблонизации, и ЗА Питон как за язык программирования.
Если проигнорировать производительность.
В том же месте на которое Вы отвечаете - рассматривается прежде всего ПРОИЗВОДИТЕЛЬНОСТЬ система шаблонизации на Питоне с возможностями PHP.
Так вот PHP чрезвычайно производителен как шаблонизатор (что подтверждают тесты, приведенные выше) и нельзя сказать что он край как неудобен именно как шаблонизатор.
Вот когда на нем пытаются программировать - это другое дело. Но к вопросу "шаблонизация: Python vs PHP" возможности программирования средствами PHP имеют весьма косвенное отношение.
Полноценное кэширование - это когда страничку можно отдать посетителю сайта миную логику на Python. То есть когда однозначно можно отделить статику. Хотя бы по времени жизни кэша.
Тогда Вы избегаете всех тормозов Питона.
Если содержимое страницы меняется в зависимости от поведения посетителя сайта - полноценное кэширование страницы - невозможно, к сожалению.
Скажем для интернет-магазина (ситуация, когда товар кладется в корзину).
Но кэширование - крайне эффективный алгоритм, потому даже в сложных случаях кэшировать стараются хотя бы отдельные блоки.
В том числе и Drupal так умеет.
Но тут уже кэширование подтормаживается тормозами Python или PHP...
Чисто черное и чисто белое, жизнь по правилам бинарной логики, безусловно хорошие и безусловно плохие люди - всего этого нет в реально жизни.
1. Профессионал выберет то, с чем он хорошо знаком.
2. В случае когда профессионал имеет фору выбора, задел времени, если он окончательно не отупел и развивается, экспериментирует, то будет ориентироваться на подобные тесты, чтобы не выбрать принципиально неподходящее решение. Но не более того.
В реальной жизни бинарной логики нет. Это всего лишь свойство человеческого мышления - упрощающая нам жизнь. Но не следует до такой степени лениться, чтобы полностью прекратить думать САМОМУ.
Молодца, что то знаете все таки.
Это безусловно используется во всех серьезных сайтах и секретом не является.
В том числе для посетителей этого сайта, ибо есть и в Drupal в том числе.
Решение позволяет существенно поднять производительность, потому есть готовые механизмы - не обязательно делать самому.
Но первоначальный вопрос об производительности был - об ограничения и затыках Питона. Когда все настолько плохо, что Питон уже является узким местом.
Напомню первичный вопрос: я написал что именно шаблонизация (в том числе и с кэшированными шаблонами) и будет узким местом.
Питон по сути не так уж и много трудоемких задач выполняет на сайте.
В общем случае:
а) Разбор URL и решение что делать по этому запросу
б) Обращение к БД
в) Рендеринг.
Угадайте, где именно Питон будет тормозить больше всего.
Даю подсказку. Сервера баз данных как правило не на Питоне сделаны.
Во, то есть Вы признаете, что в общем случае именно рендеринг является самым узким местом сайта на Питоне?
Там написано "как вы будете тюнить проект", "Я" там нет, у вас со зрением проблемы???
Вы банально прицепились к формулировке. Ежу понятно, что в такой огромной инфраструктуре, как Гугл, отказ и свертка не могут быть мгновенными. Но тенденция уже задана.
Вы избежали ответа, так держать. А лично я использование кеширования, психа и др. методов я не отрицаю. Но при этом не ссылаюсь на загадочные рекомендации, смысл которых сами не можете объяснить.
Не вижу, где я в этом признавался.
Из ваших слов выше следует притивоположное. Это сейчас вы изменили точку зрения.
Плохо соображающие люди меня раздражают, признаюсь.
Про девушку - толсто, но ожидаемо: аргументы на нуле.
Вы не видите скрытого смысла (с)!
А если серьезно, то там написано: "мы думаем, как оптимизировать уже готовые питон-проекты, но новые на питоне писать не будем".
Этого я не знаю, не работаю там. Видимо, всё по-прежнему: плюсы, джава.
У меня написано Я, а не "Я". В русском языке личные местоимения имеют 3 лица.
И эти лица местоимений меняются в зависимости от того, кто пишет или говорит.
Тук-тук, за пределами компьютера есть другая жизнь, где нужна не бинарная логика.
Это вообще не откровение.
Еще туеву хучу лет назад было известно для сложных веб-проектов - Java имеет существенное преимущество.
Нормальный программист (точнее не программист в смысле "кодер", а программист в смысле "архитектор проекта" - давно уже может выбирать какую часть системы делать на чем.
Видимо, программистам Гуглу в свое время ну очень понравился Python. Даже слишком сильно для их масштабов.
Что Вы находите там загадочного?
Любой действительно компетентный специалист никаких необычных вещей там не увидит.
Если то же самое пишет некий специалист Гугла - это для Вас повод действовать.
Если то же самое пишет Ваш коллега из соседнего города - это повод сомневаться в том, что ваши коллеги способны думать.
Как я уже писал выше - в Вас слишком сильна вера авторитетам, печатному слову. Думайте СВОЕЙ головой - это полезно для сосудов головного мозга.
Иначе коллеги Вас обойдут. Конкуренция меньше не становится.
Жаловались на проблемы с памятью при использовании Психа.
До Вас не доходит, что это - нормально.
Писали о том, что Псих компилирует машинно-зависимый код и говорили, что это не есть гуд.
До Вас не доходит - что именно в этом и заключается смысл ускорения средствами Психа.
Я предполагаю, что Вы читаете меня подряд - у Вас всегда есть возможность перемотать страницу выше.
Посему в каждом предложении я не повторяю полностью все - иначе в чем смысл беседы, организованной в виде треда с многими сообщениями.
С самого начала я не высказывался рьяно за JIT Психа, рядом с Психом упоминал - JIT JVM как более сурьезное решение.
Если Вы вынуждены пользоваться Психом, то, скорее всего, где то допустили ошибку на этапе проектирования или Вам пора переходить на Jython.
Ну что же делать, ежели у Вас крайне мало фраз с технической аргументацией.
Слишком много эмоций.
Для девушки - сие нормально.
Для парня - неестественно, в общем случае. Мужчины склоны к большей абстракции в мышлении, ибо женщины чересчур практичны для этого и более привязаны к реальной жизни.
Видимо потому и меньше среди женщин программистов.
Целая виртуальная машина которая должна решить проблему старых приложений?
Не слишком ли сильное решение по оптимизации?
После такой оптимизации вновь захочется Питона...
Повторю конкретный вопрос, от ответа на который Вы все уходите:
Чем отличается программа, выполняемая в JVM, написанная на Java и программа выполняемая в JVM, написанная на Python (Jython)?
Вы полностью скатились к унылому троллингу — обсуждение моего пола, эмоциональности, нездоровый сарказм.
Плюс вы не ответили на зашкаливающее кол-во моих вопросов, а на обсуждении питона обосрались по полной.
Утомили вы меня, обезьяну не обучишь за день, мне дорого свое время.
Я выхожу из обсуждения. Можете считать себя победителем.
Да любопытно просто. То что Вы девушка - ни в коем случае не является оскорблением.
Если почитать выше по ветке - то прекрасно видно кто вышел за границы обсуждения и перешел на личности.
Почему-то некоторые люди думают, что можно написать любое оскорбление, и - оппонент будет терпеть.
Ну как можно беседовать с человеком, если он не понимает, о чем именно написан реальный ответ?
Я даже писал Вам прямым тестом, что оставляю в своих текстах закладки, с помощью которых проверяю компетентность оппонента.
Человек, который в теме, легко бы нашел у меня целых 2 ошибки.
Учитесь, учитесь и учитесь как завещал великий...
Все, что Вы написали как бы по теме является является столь же эмоциональным как и ваша аргументация - ну например: когда обсуждали производительность шаблонизации - я привел конкретные цифры, Вы же сообщили, что на цифры плевать - важнее удобство, то есть свели разговор к непроверяемому факту (удобство для каждого свое).
Про жрущего память Психа - частный случай, на плохом хостинге. На современных серверах не есть большая проблема (не дорого) добавить оперативной памяти, чтобы Психу было хорошо. Если же проект такой, что не хватает денег на память, то я не знаю какие там затыки в производительности сурьезные, что программист бессилен (скорее попросту некомпетентен), а нужен сразу Псих.
Больше ничего по делу не написали.
Или эмоции или отсылки на непроверяемые факты - то бишь один из признаков троллизма.
Ну вот и очередное эссе.
Человек, у которого есть ЗНАНИЯ, которому действительно есть, что сказать по теме, но плохо воспитанный, пишет: "обосрались там то и там то конкретно потому то и конкретно поэтому то"
Есть маленькая деталь - Вы на тематическом форуме. Здесь "в теме" достаточно много народа.
Просто так лапшу на уши - не повесишь. Что Вы ожидали. Пишите бред про Питон на форуме дизайнеров.
Правда там тоже нередки программисты.
Многоуважаемый высококомпетентный специалист, готовый дать любую консультацию, Вас не стыдно за свой личный НЕРАБОТАЮЩИЙ сайт?
Зачем себя рекламировать во множестве мест, если ссылка ведет в никуда?
Одна из причин, по которой веб-сайты меняют мир, что информация на них доступна ВСЕГДА и БЕЗ УЧАСТИЯ ВЛАДЕЛЬЦА.
Веб сайт специалиста, позицирующего себя как грамотного - ну типа как Вы - должен функционировать ВСЕГДА. Ваш я смотрел с начала обсуждения и по сегодня. Не фурычит.
Чините. Сайт крутого спеца, как Вы, должен работать круглосуточно с минимальным вмешательством владельца.
Кстати, если Вы еще не знаете - есть такие сервисы, которые отслеживают доступность сайтов и упреждают владельцев - по почте, SMS... Такой сервис и самому можно сделать...
Прошло еще 2 недели....
Сайт http://www.studiol.ru/ крупнейшего в мире специалиста по тому как нужно затормозить Python, посетителя нашего форума господина kyky, указанный в его профиле http://drupal.ru/username/kyky, как лежал так и лежит.
Месяц лежит...
Крутой специалист kyky, неспособный поддерживать свой личный сайт, но предлагающий услуги за деньги - в веб-разработке просто 0
Время всё расставило по местам.
Сотрудник гугла дает официальное объяснение причин сворачивания Unladen Swallow, отказа от phyco и др. важные моменты.
http://habrahabr.ru/blogs/python/116314/
Человек спросил про использование Джанго в качестве движка для сайта, а вы уже про Unladen Swallow.
до середины читать было интересно
Товарищ kyky верно придумал себе ник. Куку (по русски), может и спец в коде и/или железе, но то что ты ничего не понимаешь в людях и технологиях - это факт. Durak - на самом деле, реально действующее положение вещей опубликовал.
Нахера нужно переписывать здоровенное приложение на другой язык или вообще придумывать новый, ради самой производительности, уж на много проще и дешевле докупить серверов.
Ты его клон?