Решился таки делать большой проект с использованием готового фреймворка, чтобы не возиться с написанием с нуля, т.к. сроки сильно жмут, а своё хочется идеально спроектировать, на что конечно нужно кучу времени.
Первые впечатления такие:
- Я не знаю как работают другие фреймворки, CodeIgniter я выбрал из соображений легкости, и большого комьюнити. Тормозит. По сравнению с самописным тормозит просто дико. Вобщем-то понятно почему тормозит - куча ненужной “авто-логики”, которая выполняется при каждом запросе. Например поиск подмены для системных библотек CI, пользовательскими. При каждой загрузке страницы он бегает по диску и ищет переписали ли вы какой-то его класс, и какой класс ему использовать. Удобно в разработке, спору нет, но в продакшен не пойдет совсем.
- Пол вечера возился в проблеме с драйвером oracle - при использовании последовательных запросов, например в цикле (знаю что плохая практика, но поставил бы пива тому кто вытащит одним запросом параметры для запросов к ораклу по разным id, и потом данные по этим id с учетом что у каждого id параметры в запросе будут разные). Так вот,
выполняете два select’а, а результаты в обоих случаях получаете от первого запроса. Оказалось глюк - решение здесь. Пока разбирался решил что мне вобщем-то database класс из CI и не нужен - ActiveRecord’ом я все равно пользоваться не буду - т.к. запросы к ораклу в этом проекте на пол-страницы A4 каждый. Вобщем написал простенький враппер к PDO, сразу с поддержкой кеширования и т.п. - Кому нужен scaffolding во фреймворке? Нет реально, есть такие люди? Понимаю может быть удобно, но НУЖЕН? Почему бы не сделать эту фичу опциональной? Просто, зачем пихать это во фреймворк? Это же не CMS, чтобы запихивать всего и побольше, чтобы юзер был рад.
- Сделали скафолдинг, зато не сделали нормальную авторизацию, и возможность сделать back-end по-легкому. Пока решил юзать библиотеку Userlib от пользователей комьюнити, вроде легкая и довольно логично написана.
- Соответственно родные классы для работы с database-сессиями я пользовать не могу - database то у меня свой :) Вот сижу и переписываю класс session. Если дойдут руки сделать нормально, выложу сюда :)
Пока вроде все впечатления, будут еще - обязательно напишу :) Две мысли пока в голове - надо пока не поздно написать своё попроще, потому что и так большую часть переписываю и думаю надо было всетаки сравнить CI с ZendFramework - что-то мне подсказывает что Zend хоть и еще более монстрообразный, но сделан во многом логичнее.
декабря 12, 2007 at 02:34 #willwin
Блин, начал делать тоже большой проект на CI (и уже бОльшую часть сделал), всё бы клёво, всем доволен, разработку существенно ускоряет и делает приятнее, но вот по поводу скорости работы теперь тоже расстраиваюсь :-( На ноуте с core2duo 1.8ghz, 2gb ram, под fedora8, php 5.2.4 с установленным eaccelerator и при том что статику настроен выдавать nginx, максимум - 250 запросов в секунду отрабатывает к несложной странице, незагруженной запросами. Вот теперь голову ломаю, как ускорить. Кеш, само собой, будет, и будет в быстром memcache. Но как бы там ни было, просто сами скрипты долго отрабатывают от упомянутой тобой загруженности логикой :(
Хотя в данном случае и такой производительности должно будет хватить, всё равно хочется больше 250 в секунду:)
декабря 12, 2007 at 07:56 #Pavel
XDebug поможет найти самые медленные части, и оптимизировать их ручками.
250 запросов в секунду это на самом деле не самое маленькое число :) Что за проект с такими гигантскими требованиями к оперативности? :)
декабря 12, 2007 at 09:56 #willwin
250 может и не мало, но по сравнению с 10-12 тысячами запросов в секунду, которые в тех же условиях может обслуживать nginx, кажется совсем как-то неоптимистично :) Проект не столь глобальный и хватит такой производительности, но всё же просто хотелось бы знать, что система способна на бОльшее, потому как потом её же будем применять в новых проектах, более крупных.
Про XDebug не довелось слышать, сейчас поищу что это такое, спасибо :)
декабря 12, 2007 at 11:13 #Pavel
nginx обслуживает статику, это несколько другое. Нужно учитывать что apache тут тоже дает очень большую потерю производительности, так что косяки не только в CI, хотя он конечно сильно тормозит…
Я сдаю свой большой проект 1го января, а после запуска вплотную займусь оптимизацией CI. Более или менее универсальные части могу выкладывать сюда.
декабря 13, 2007 at 01:51 #willwin
Выкладывай, я подписываюсь на твой rss:-)
Кстати, я заметил что довольно сильно затормаживают работу CI autoload’ы. У меня вот несколько моделей подргужаются, хелперов и библиотек, и с этим загрузка почти в полтора раза дольше, чем без него.
декабря 13, 2007 at 10:28 #Pavel
Ну да, причем есть подозрение что встроенный в php5 autoload будет работать шустрее. Хотя не факт - ведь модели например наследуются от класса Model, соответственно это как минимум два инклуда/файловой операции на запрос.
У меня в планах как минимум убить весь autoload, но уже в продакшн версии. Плюс есть смысл в продакшне все конфиги засунуть в один файл, или даже в memcached, наследуемые системные библиотеки интегрировать в родительские. Я не думаю что обновления CI есть смысл ставить на продакшн версию, за исключением исправлений безопасности.
Вобщем работать есть над чем. Я оптимизацией пока и не занимался честно говоря.
декабря 13, 2007 at 02:46 #mihailt
насчёт быстрого back-end’а и авторизации посмотри http://www.rapyd.com - такая глобалная надстройка над CI, правда достаточно глюканутый, но исправить можно.
декабря 13, 2007 at 03:08 #mihailt
P.S. кстати никто не мешает ZF компоненты использовать в CI ;)
декабря 13, 2007 at 04:15 #Pavel
А я смысла не вижу огород городить, и так мееееедленный фреймворк, а со всякими зендовскими приблудами и прочим будет еще медленнее имхо. Если нативного нет, будем писать сами.
Тем более что авторизацию то написать не так сложно.
декабря 13, 2007 at 05:42 #mihailt
ну если потом точно знаешь кто будет поддерживать и развивать проект тогда да есть смысл писать свое, а вот если нет, то есть смысл взять за основу тот же Zend_Auth и Zend_Acl и потом разработчику не нужно будет голову ломать как что и где написанно.
декабря 13, 2007 at 07:21 #Pavel
Есть доля правды и тут.
Вобщем тут каждый выбирает для себя как я считаю. В моем конкретном проекте лучше все мелочи писать самому, т.к. слишком много переделываться будет в самом CI, так что даже в этом уже нужно будет разбираться, и дока особо не поможет.
Поддерживать думаю буду я.
декабря 27, 2007 at 03:49 #Илья
Как по мне, то из фреймворков с которыми я работал (CakePHP,PRADO,Symphony) СI самый быстрый. А 250 запросов в секунду для апача и пхп это достаточно неплохо. У меня на тяжелых проектах благо если 30-80 будет. Тут уже все зависит от настройки апача, если апач обрабатывает php.
декабря 28, 2007 at 02:39 #Pavel
Илья, согласен. С другой стороны всегда интересно смотреть на время генерации страниц гугла. С учетом того какая там логика отрабатывает по поиску. Так что стремиться надо.
Я кстати свой тоже немаленький проект на CI пока не тестировал, и не буду пока весь хлам из него не вытрясу.
марта 12, 2008 at 08:15 #Roland Chanishvily
Pavel, но тоже Гугля - там не один комп, да и задачи жутко распаралелны, как я читал. PHP штука отличная, но не будем сравнивать божий дар с яишницей :)
октября 13, 2008 at 06:21 #Дармен
Codeigniter, в отличие от того же Zend Framework, довольно шустрый. Да и сравнивать фреймворк с набором библиотек немного неправильно.
Во многом согласен с автором, скафоолдинг тут нафиг не нужен, автозагрузка библиотек во многих случаях себя не оправдывает (хотя кто запрещает каждый раз юзать $this->load->library()?)
Сам использую CI+некоторые классы ZF