зенд зендом, но я добрую половину переписал/дописал. ООП сила, брат.
тем не менее, очень радуюсь когда что-то такое же как и самописное имплементируют зендовцы :). Я с ним дружу с 0.4 версии и уже неоднократно это было. Только что глянул в Zend_Db, действительно кеш метадаты там теперь есть. Почти зеркальная копия моего :-P
Если есть руки - любой фреймворк можно "разогнать". Причём особых усилий для этого не нужно. Различными ухищрениями я умудрился разогнать зенд в 4 раза (с 20 до 80 req/s). Это и кеширование explain таблиц, кеширования frontcontroller состояние которого между запусками, даже на разных страницах в общем-то не меняется, кеширование. При этом у меня результаты бизнес-логики не кешируются вовсе. Кеш - в shmem (apc || xcache).
При этом ГОТОВЫЙ проект на Xeon 2.4GHz DualCore (4 CPU, 8 Cores) выдает 480 req/s. Т.е. приблизительно 50 req/s на ядро. Или 0.02 сек на запрос. Я нахожу это отличным результатом ;). Удобство разработки на фреймворке стоит куда дороже.
они игнорируются интерпретатором ещё на стадии парсинга - поэтому влияние настолько мало, что лучше о нём и не думать :). Просто если что-то генерировать автоматически - то лучше обрезать всё что не нужно.
В зенде есть минус, который достаточно трудно лечится ввиду концепции системы - использование схемы "один-класс-на-файл" и в результате - более 100-150 require-ных файлов во время работы. Из которых обычно процентов 90% вообще каждый запрос (!) таскаются. Даже при использовании opcode-кеширования на это уходит ~0.02сек на celeron 2.4ghz. На в-два-раза-более-шустром компе двухкратного преимущества в скорости при этом не будет ;). Даже отключением проверки изменений файлов в opcode-кешере проблема не решается.
Как вариант - для production собирать "особенный" билд проекта, впихнув в один файл, например, все зендовские классы которые грузятся каждый запрос. У меня получается 4.5-мб файлик с 12 тысячами строк %). При этом первый его require выходит в те же 0.02сек, а вот последующие (уже собранный из opcode-кеша) - 0.003сек, что уже вовсе не является критичным.
При создании такого зендовского файлика-библиотеки нельзя запихать туда весь зенд - иначе размер файла будет более 80мб и работать с ним нереально. При этом нужно высматривать процент загрузок на запрос, просматривая данные о кешах apd, xcache и тп. Вырезать из всех зендовских файлов комментарии и require_once (там их полно, особенно - на эксепшены). При определённом стечении обстоятельств - работает %).
Надо попробовать написать нормальный инструмент. Вообще хоть кто-нибудь сталкивался с проблемой скорости при использовании zend framework?
орейли - господь бог? Случайный весьма не глупый мужик, придумавший фразу. И всё. Я вам больше скажу - категоризации web2.0 не существует вообще. Это маркетинговый рычаг.
бред какой. Если вы перестанете ездить на метро и пересядете в личный автомобиль - умнее вы от этого не станете. Будете быстрее, но и проблем будет больше.
на lighttpd и на apache можно сделать одинаковые по скорости работы проекты. На Debian, FreeBSD, Linux - так же возможно сделать одинаково по скорости работающие проекты. Всё зависит от того на чём умеет работать комманда разработчиков и администраторов отдельного проекта. На mongrel тоже можно сделать безумно быстрый проект если приложить усилия.
Из списка, например, у Truemors абсолютно не "суперпрофи" в админах. Проект уже неоднократно рассыпался на составные части.
Многие проекты на лайти специально выводят инфу об апаче. В этом есть смысл. Но его мало. Часто проекты состоят из уймы разных вебсерверов и проксей, данный список отражает только мордашку.
На питоне и django можно легко написать проект вообще куда более шустрый чем apache+php-или-что-там-у-вас. На питоне без django - ещё быстрее. На си без этих вебсерверов - ещё быстрее. На асме - легче застрелится, но теоретически возможно.
Собственно на Windows+IIS можно так же написать достаточно быстрый проект (не ручаюсь, не пробовал, но это должно быть возможным).
А теперь вопрос: о чём может сказать такое тестирование? О том что кто-то там любит линукс больше чем виндовс? О том что это тестирование должно крутится в памяти при решении на какой платформе писать собственный проект? А может даже - какой вебсервер использовать в собственном проекте? Чушь какая.
Пробуйте сами создавать HA-приложения. На чём получится - на том и работайте :).
web2.0 это:
* приложения между девайсами а не на них
* открытость к ре-использованию информации другими ресурсами
* приложения не как какие-то артефакты, а как постоянный (!) процесс участия с пользователями (pbeta)
* приложения где от количества пользователей качество сервиса улучшается
web2.0 - это смысл, а не технологии. AJAX тут даже и боком не стоит, если честно. Читайте Тима Орейли.
непонятна связь web2.0 с внутренней архитектурой приложения. Но это не смертельно.
Смертельно другое - в том же ZendFramework есть огромный (!) пакет примеров. Где пошагово (!) добавляется фунциональность. Проект примеров содержит уйму объяснений (в т.ч. и на русском языке), и очень грамотный (ибо вылизанный многими программистами код).
имхо, куда полезнее вместо таких постов просто положить ссылку на примеры и объяснить как их достать и запустить.
Примеры лежат в svn и крайне полезно новичкам (там fisheye стоит) посмотреть историю и комментарии к изменениям отдельных файлов. Коммент вида "тут убрали это отсюда, потому что может развалится в таком-то случае" крайне полезен для общего развития :). Естественно с анализом исходного кода.
Тут же.. не хочется лезть глубоко - но то что код не идеален видно невооруженным глазом (korchasa, +1). Как минимум швыряться рутовым Exception - головная боль для последующих разработчиков.
мне кажется слегка глуповатым насиловать компы пользователей такой кучей 2D-графики. Под линуксом разве что в kk не подтормаживает. FF стоит на пару с оперой (хотя у оперы дела получше). Сейчас ещё в сафари залезу.. :)
Если честно - я ещё ни один пост на хабре не читал, где человек бы эти слова упомянул, кроме вашего. А то что на сайте они всюду - до лампочки как-то. Никогда не удивлялись почему в играх топор зачастую называют "супер-мочилка-инопланетян"? Непонятно только _зачем_ вы об этом думаете? Заняться нечем? :)
Юношеский максимализм в каком возрасте бывает? Вот такой же максимализм и у разработчиков после 2-3х лет занятия этим ремеслом. Сродни крикам "нет! будет у нас XSLT в одном месте и PHP в другом!! Чтобы отделить логику от представления!!!". Хотя вроде бы надо логику от представления отделить - но никак не HTML от PHP :). То же самое с блочной версткой vs. табличной - делать такой (X)HTML чтобы одним CSS стилем можно его было с ног на голову поменять - глупо. Это всё - представление. Тут нету модели данных даже (если скажете что xhtml выступает в её роли - мои тапочки со смеху подохнут). (X)HTML+CSS это целиком логика представления, так что если для изменения дизайна надо менять и то и другое - это абсолютно нормально и естественно.
Я вот кстати не понял - каким образом XHTML связан с блочной вёрсткой ^_^. Оба понятия настолько тесно переплетены в цитируемом документе - как будто одно целое :).
Сам я пишу на XHTML в основном из-за более аккуратного внешнего вида кода :) ("внешний вид кода".. хм.. надо же). Ну и возможность без определённых проблем работать с документом как с обычным XML - тоже чего-то стоит. А вот дебаты табличная верстка vs. блочная мне в целом совсем непонятны :). Если заглянуть в мир глянцевых журналов и книжек - то станет понятно что блочная верстка действительно крута при очень четких понятиях размера шрифта, гегля, размеров блоков, размеров VIEW (т.е. страницы). В браузерах же - всё бесконечно тянется во всех направлениях (т.е. view не лимитирован). Ладно, фиг с ним - можно сайт резиновым по ширине не делать. А вот уж по вертикали - извините, но постранично сайты листать это совсем что то новое :). Помимо всего прочего табличная верстка как правило куда быстрее реализовывается и куда более одинаково отображается :). Ещё пинок - есть варианты которые решительно невозможно реализовать методами "всплытия поплавков". Ещё есть вариант создания заточенного под один сайт VIEW путём разрисовки всего UI блоками на яваскрипте. Тем более что после внесения в блок всех составляющих - т.е. текста картинок и тп - становится ясным и четким его физических размер ещё _до_ отображения на экране. Тогда проблема смены медиа-устройства (normal,print,tv) будет совсем порстенькой - JS отвечающий за позиционирование и раскраску поменять и всё :). Но это огромная куча лишней работы, которую совсем не нужно делать компаниям.
p.s. в первом абзаце я обращался не к автору поста на хабре, а к автору 15-ти пунтков отсюда http://www.i2r.ru/static/476/out_23437.s…, с автором поста на хабре (Novikov) я согласен почти целиком (что странно ;)) и столь же скептически отношусь к таким взываниям "мир, труд, май, XHTML!"
не.. шотаут этот заточен именно под скорость языков, на синтетические тесты, а не на конкретные примеры реализаций (я имею ввиду крупные примеры - типа веб-приложение с реализацией MVC и т.п.)
почему не использовали tokenizer?
да и какая-то каша у вас в примере. То ZendCompiler, то ZendMake. Тем более нету ZendCompiler::make() :).
кошу под европейца. Суровая реальность.
нужно разве что будет написать свой класс View, имплементируя методы Zend_View_Interface. В мануале зенда об этом рассказано.
тем не менее, очень радуюсь когда что-то такое же как и самописное имплементируют зендовцы :). Я с ним дружу с 0.4 версии и уже неоднократно это было. Только что глянул в Zend_Db, действительно кеш метадаты там теперь есть. Почти зеркальная копия моего :-P
При этом ГОТОВЫЙ проект на Xeon 2.4GHz DualCore (4 CPU, 8 Cores) выдает 480 req/s. Т.е. приблизительно 50 req/s на ядро. Или 0.02 сек на запрос. Я нахожу это отличным результатом ;). Удобство разработки на фреймворке стоит куда дороже.
Как вариант - для production собирать "особенный" билд проекта, впихнув в один файл, например, все зендовские классы которые грузятся каждый запрос. У меня получается 4.5-мб файлик с 12 тысячами строк %). При этом первый его require выходит в те же 0.02сек, а вот последующие (уже собранный из opcode-кеша) - 0.003сек, что уже вовсе не является критичным.
При создании такого зендовского файлика-библиотеки нельзя запихать туда весь зенд - иначе размер файла будет более 80мб и работать с ним нереально. При этом нужно высматривать процент загрузок на запрос, просматривая данные о кешах apd, xcache и тп. Вырезать из всех зендовских файлов комментарии и require_once (там их полно, особенно - на эксепшены). При определённом стечении обстоятельств - работает %).
Надо попробовать написать нормальный инструмент. Вообще хоть кто-нибудь сталкивался с проблемой скорости при использовании zend framework?
Из списка, например, у Truemors абсолютно не "суперпрофи" в админах. Проект уже неоднократно рассыпался на составные части.
Многие проекты на лайти специально выводят инфу об апаче. В этом есть смысл. Но его мало. Часто проекты состоят из уймы разных вебсерверов и проксей, данный список отражает только мордашку.
На питоне и django можно легко написать проект вообще куда более шустрый чем apache+php-или-что-там-у-вас. На питоне без django - ещё быстрее. На си без этих вебсерверов - ещё быстрее. На асме - легче застрелится, но теоретически возможно.
Собственно на Windows+IIS можно так же написать достаточно быстрый проект (не ручаюсь, не пробовал, но это должно быть возможным).
А теперь вопрос: о чём может сказать такое тестирование? О том что кто-то там любит линукс больше чем виндовс? О том что это тестирование должно крутится в памяти при решении на какой платформе писать собственный проект? А может даже - какой вебсервер использовать в собственном проекте? Чушь какая.
Пробуйте сами создавать HA-приложения. На чём получится - на том и работайте :).
* приложения между девайсами а не на них
* открытость к ре-использованию информации другими ресурсами
* приложения не как какие-то артефакты, а как постоянный (!) процесс участия с пользователями (pbeta)
* приложения где от количества пользователей качество сервиса улучшается
web2.0 - это смысл, а не технологии. AJAX тут даже и боком не стоит, если честно. Читайте Тима Орейли.
Смертельно другое - в том же ZendFramework есть огромный (!) пакет примеров. Где пошагово (!) добавляется фунциональность. Проект примеров содержит уйму объяснений (в т.ч. и на русском языке), и очень грамотный (ибо вылизанный многими программистами код).
имхо, куда полезнее вместо таких постов просто положить ссылку на примеры и объяснить как их достать и запустить.
Примеры лежат в svn и крайне полезно новичкам (там fisheye стоит) посмотреть историю и комментарии к изменениям отдельных файлов. Коммент вида "тут убрали это отсюда, потому что может развалится в таком-то случае" крайне полезен для общего развития :). Естественно с анализом исходного кода.
Тут же.. не хочется лезть глубоко - но то что код не идеален видно невооруженным глазом (korchasa, +1). Как минимум швыряться рутовым Exception - головная боль для последующих разработчиков.
Я вот кстати не понял - каким образом XHTML связан с блочной вёрсткой ^_^. Оба понятия настолько тесно переплетены в цитируемом документе - как будто одно целое :).
Сам я пишу на XHTML в основном из-за более аккуратного внешнего вида кода :) ("внешний вид кода".. хм.. надо же). Ну и возможность без определённых проблем работать с документом как с обычным XML - тоже чего-то стоит. А вот дебаты табличная верстка vs. блочная мне в целом совсем непонятны :). Если заглянуть в мир глянцевых журналов и книжек - то станет понятно что блочная верстка действительно крута при очень четких понятиях размера шрифта, гегля, размеров блоков, размеров VIEW (т.е. страницы). В браузерах же - всё бесконечно тянется во всех направлениях (т.е. view не лимитирован). Ладно, фиг с ним - можно сайт резиновым по ширине не делать. А вот уж по вертикали - извините, но постранично сайты листать это совсем что то новое :). Помимо всего прочего табличная верстка как правило куда быстрее реализовывается и куда более одинаково отображается :). Ещё пинок - есть варианты которые решительно невозможно реализовать методами "всплытия поплавков". Ещё есть вариант создания заточенного под один сайт VIEW путём разрисовки всего UI блоками на яваскрипте. Тем более что после внесения в блок всех составляющих - т.е. текста картинок и тп - становится ясным и четким его физических размер ещё _до_ отображения на экране. Тогда проблема смены медиа-устройства (normal,print,tv) будет совсем порстенькой - JS отвечающий за позиционирование и раскраску поменять и всё :). Но это огромная куча лишней работы, которую совсем не нужно делать компаниям.
p.s. в первом абзаце я обращался не к автору поста на хабре, а к автору 15-ти пунтков отсюда http://www.i2r.ru/static/476/out_23437.s…, с автором поста на хабре (Novikov) я согласен почти целиком (что странно ;)) и столь же скептически отношусь к таким взываниям "мир, труд, май, XHTML!"