Разочарование в Yii
Я обычно не любитель писать минипосты или делиться своими мыслями, но сегодня настал момент такого первого поста.
Как понятно из названия, разочаровался я в фреймворке Yii, но обо всем по порядку.
Более трех лет я занимаюсь разработкой на php с использованием фреймворка CodeIgniter. Так получилось, что основная работа почти всегда заключалась в доработке готового продукта, и места для творчества с использованием CI почти не оставалось. В итоге, я занимался разработкой одного минипортала, посвященного браузерной игре heroeswm. Почти сразу я перевел его фронт-энд на CI. Админки как таковой и нет. На протяжении трех лет она почти не нужна была, ведь большая часть информации получается в результате выполнения CRON-скриптов. 99% информации — это различная статистика. Посещаемость ресурса «в мирное время» 400-500 уников в день. Если администрация запускает войну или турнир, то посещаемость возрастает до 1500-2000 уников в день. Причем все это дело крутится на хостинге за 4$/мес. Судя по информации о нагрузке на сервер, портал запросто выдержит и 5000 уников.
Кто-то может подумать, что данные для вывода просты и однотипны, раз сайт держит такую нагрузку. И он ошибётся. Общий размер таблиц MySQL составляет 1,3 Гигабайта. Одна из основных таблиц, по которой производится более 60% всего поиска, содержит 800000 записей (и 25 полей). Для пользователей на сайте существует форма поиска, позволяющая выбирать данные по 10 критериям, которые в итоге выливаются в сложные SQL-запросы.
Так как хостинг достаточно простой и недорого, ни какой речи о MemCache и не идет.
Сайт работает на CodeIgniter v1.7.2, используется библиотека MPCache для кэширования результатов запросов в файлы. Лёгкий фреймворк и оптимизация кода дали такой хороший результат.
Итак, с полгода назад назрела необходимость переписать текущий движок с добавлением типичных фишек (регистрация, блог, голосования и т д). CodeIgniter 2.0 казался мне унылым (ведь за последние 2 года он почти не изменился, не оброс функционалом, выглядел полутрупиком, да и многие активные разработчики переползали в стан Kohana|FuelPHP), и я стал смотреть в сторону других фреймворков. В Kohana понравилось много фишек, но скудная документация и постоянные заморочки с выходом новых версий оттолкнули от дальнейших раскопок. FuelPHP — вкусно, быстро, но PHP5.3 в минимальных требованиях — большой минус.
Yii — видел я давно. Нравился. Манил своими возможностями, кучей расширений, активным сообществом. Скачал. Прошел все этапы создания блога. Запустил. Потребление памяти — 10Мб (а в пике — так почти 14Мб!). Пустой проект, почти без кода, с несколькими записями в базе. Проект, который сделан на коленке за вечер — и 10Мб. Могу сказать, что вышеописанный проект на lgnd.ru занимает всего 0,9-1,5Мб памяти в зависимости от страницы, причем, экспериментируя с полным выключением построителя запросов, удавалось снизить потребление до 0,6-1Мб.
10Мб — это перебор. Отключил AR, переписал модели на прямые запросы — 4,5Мб. Всё равно много. Полазил по форуму. Пишут про кэширование, про оптимизацию и т. д. Но тут выходит 2 проблемы — на дешевом хостинге нет больших ресурсов и инструментов для кэширования. В итоге нужно будет переходить на более дорогие решения при более-менее серьёзном онлайне.
На сайтах с очень большой посещаемостью всё и вся не закэшируешь — все равно будут обращения мимо кэша с выеданием всех ресурсов сервера. Всё равно в итоге нужен будет более мощный сервер.
Моё мнение: фреймворк должен быть хорошим инструментом в руках разработчика, а не десятитонной бандурой для забивания гвоздя в стену.
PS. Я не хочу холиварить, какой фреймворк лучше/хуже. Но большое потребление памяти это минус Yii. Я за оптимизацию!
Ты бы еще zend попробовал %)
Я кстати тоже за оптимизацию и за кодеигнайтер, жаль что я пока просто быдло кодер %)
@As
В далеких планах протестировать различные php фреймворки на производительность и прожорливость.
Ведь обычно, в тестах, упоминается только скорость генерации страниц, и часто, просто забывают о расходе памяти.
Не думаю, что стоит подходить к выбору фреймворка исключительно с точки зрения употребляемой памяти. Гораздо проще купить более качественный хостинг (особо с тем учётом, что 128 Мбайт это уже далеко не проблема), чем городить всякие грабли с оптимизациями и, наверно, лишними. Вспомним только, что использование оптимальных с точки зрения быстродействия структур, таких как бинарные деревья или массивы эйлера, требуют гораздо больше памяти, чем плоские списки, или, не дай бог, массивы…
Лично я пишу на yii уже год, и попутно изучаю другие фреймворки, в частности kohana, и до сих пор он мне кажется наиболее простым и удовлетворяющим основные потребности.
Спасибо за чуточку внимания)
Наверно это единственный нормальный отзыв — мнение относительно CI и Yii. Даже на Хабре фигня холиварная. Я уже думал, что я один Yii не перевариваю.
Вы бы поподробней в вопросе разобрались, такое большое потребление памяти из-за особенностей реализации методов renderPartial и render (использования буфферизации вывода ob_start/ob_get_contents). Вам никто не мешает попробовать другой подход:
1) Отказаться от использования CClientScript
2) Перекрыть в BaseController все «ресурсоемкие» методы: widget, render, renderPartial (на деле renderInternal нужен и поразбираться с viewRenderer). Вам никто не мешает все это организовать. Есть вопросы — пишите на форум, поможем.
P.S.: Но мое имхо, что 5-10 мегабайт оперативной памяти не так уж много.
А вы не пробовали максимально оптимизировать потребление памяти?
Было бы не плохо, если бы вы сделали замеры:
— базовый пример. потребление Xмб.
— вырезали _что_то_ресурсоёмкое_. Описали чего лишились. потребление Xмб.
и в таком духе. было бы интересно и вашим и нашим.
С радостью, тока сперва блог запущу. 🙂 Пока завал по работе. Но скоро. Спасибо за идею для статьи.
А кто сказал, что отношение сложность-кода/затраты-памяти линейное? Вы проверяли затраты на рабочем проекте?
@ALex
Когда я работал в РДВ-Медиа, над проектом rabota.ru, у наших было схожее отношение: пофиг что странички при генерации жрут много МБ памяти, пофиг что ОРМ тащит тяжелые данные — закэшируем. Не хватит места/памяти/серверов — сделаем апгрейд.
Выше я упоминал, что ситуации могут быть разные, и в условиях ограниченных ресурсов выбирать «тяжеловеса» не стоит.
имхо должен быть разумный баланс производительности и возможностей. Сколько стоит оптимизировать фрейм чтобы он так маниакально экономил память? И сколько стоит память? Неужели высокопосещаемый проект не может позволить себе норм сервер?
@ryst
Поэтому прежде чем реализовывать проект необходима стадия анализа и проектирования, на которой и принимается решение о выбора инструмента/фреймворка.
Высокопосещаемый проект может быть википедией, которая каждый год побирается по всему миру, что бы заплатить за сервера.
Иногда изначально задача такова, что нет смысла использовать что то большое и прожорливое.
Меня тоже удивляло то сколько памяти кушает. Но самое интересное что на бесплатном хостинге topua.net он кушает меньше чем на денвере где я его тестирую и разнице где-то ~2 мб. Максимально что я видел у себя так это 9.89 мб
Вас смущает потребление память 10мб, вы не щупали друпал когда там и 128мб может не хватить, в целом движку требуется 48-64мб. Хехе и работают крупные сайты на нем — летают даже, там все кешируется и поэтому все кажтся быстро, но когда прорамист без кеша входит в админку друпала — можно повеситься
Просто руки надо иметь прямые! Если вы пишите SQL запросы с пятью JOIN сразу, а потом обсераете Yii, то идите полечитесь у психиатра, а потом читайте учебники по основам программирования. Просто вы не умеете готовить на Yii. Я знаю 2 огромных проекта на Yii и они летают! А оптимизация так или иначе необходима для любого проекта, независимо от его нагрузки.
А вообще Yii в тысячу раз более функциональный, чем тот же CodeIgniter с его слабой защитой от sql инъекций.
@Номад
Если бы более внимательно читали мой пост, вы бы заметили, что свои выводы я сделал по официальному руководству «Создание блога с использованием Yii».
Я знаю с пяток крупных проектов на CI, с посещаемостью более 100К уников/сутки. Это ничего не меняет.
И про sql-инъекции — вы наверно сами придумали. Если использовать AR, фильтровать данные, использовать CSRF защиту форм — sql будет надежно защищен. Причем всё это доступно из коробки.
И я не говорил, что CI идеален. Подобный пост есть и про CI. Чем глубже знакомишься с инструментом, тем больше узнаешь о его слабых сторонах.
Разные настройки оп-кэша.
И это его совсем не красит. Не так давно видел историю типа «Мы потратили Х-месяцев и полностью перевили проект с Drupal на Kohana3. Боже, как мы счастливы.»
Автор абсолютно прав. Слишком много есть он памяти… Тоже постоянно переживаю из за этого, хотя не перестаю писать на Yii.
А еще обидно, что в официальной документации, в разделе производительность, приведены «читерные» графики. Будет время — обязательно проведу нормальное нагрузочное тестирование Yii и других фреймворков.
А debug mode выключали?
Дело было давно. Помню, что я просто перенес на хостинг официальный демо-пример блога. Настройки все по-умолчанию. База — MySQL.
Все ясно с вами. Разберитесь сначала во фреймворке, потом пишите подобные посты.
У меня часто вызывают непонимание люди, которые набрасываются на других из-за того, что вторые пытаются думать. Первых я называю «программист-вордпресс». Что характеризует. Новое поколение «программистов» высокопрофессионально «разбирающиеся» в решениях c прилавка хлебного магазина и умеющие складывать пазлы из этого конструктора лего.
К сожалению, подавляющее большинство таких «программистов» интеллектуально слабо развиты, и таким остаётся сублимировать недостаток интеллекта в поношение более развитых особей.
Вместо того, чтобы саморазвиваться.
@Владлен
Не понятно к кому адресован комментарий.
Программисты бывают разные, с разным уровнем опыта и кривизны извилин. Порог вхождения в мир PHP очень низок. Это является как плюсом языка (многие популярные решения написаны на PHP, найти PHP-программиста проще всего и т д), так и минусом (некоторые «программисты» — совсем не программисты).
Виновато еще и наше время. Раньше оптимизировали каждую строку кода, что бы программа просто работала. Сейчас действует правило «проще докупить железо» и разработчикам не обязательно знать многие нюансы.
Что касается темы этого поста. За два прошедших года я успел поучаствовать в разработке на Yii биллинга крупного провайдера, причем я настаивал что бы был выбран именно этот фреймворк. Столкнулся с множеством фишек, которые нигде вообще не описаны. В целом Yii оставил приятные впечатления. Но мелкие и средние проекты на нем я выполнять не буду.
Вы не изучили фреймворк а уже пишете комментарии. Я перешел на Yii с CI и остался очень доволен, по тому что кеширование работает тут по моему на любом хостинге (встроенное кеширование), не обязательно использовать Memcache, Yii имеет много готовых решений в отличии от CI и развивается быстрее. А если судить как Вы, то как выше говорили, попробуйте Zend и Вы поймете что Yii это самый оптимальный вариант. У нас работает не один портал на Yii и отлично справляется с таблицами и в 5Гб. Для каждого конкретного проекта, нужно с умом и осторожностью подходить к выбору фреймворка. Но пока для меня лучше варианта чем Yii нет.
Любой проект необходимо заранее планировать.
Структуру базы нужно приводить к нормальной форме.
Разобраться с тем (как писали ранее) где join нужны, а где нет.
По возможности пользоваться DAO.
Поменьше пользоваться подключением готовых библиотек, то есть не всегда (а скорее в большинстве случаев) оптимальным решением будет использовать готовую библиотеку в проекте (это относится и к jquery).
CI сейчас реально мёртвая система, хотя иногда бывают и на ней проекты…
Вообще многие хотят создать своё решение и не важно CI, Yii или другой фреймворк, а в итоге переходят на CMS, так как просто не хватает терпения и желания к изучению…
К какому выводу ты в итоге пришел?
Yii г?
Какой фреймворк лучше?
Та же фигня и тоже сейчас нужно выбирать что то для проекта с большой посещаемости.
Отпишись на почту если не лень.
На мой взгляд стоит смотреть в сторону Yii или Laravel.
Если вы новичок начните с Code Igniter
Нужен маленький каркас для мини-приложения, то стоит посмотреть в сторону мини-фрейморка Silex
ps. Два года назад при разработке биллинга для местного провайдера выбрали Yii потому-что:
— большое русское сообщество
— хорошая документация
— фреймворк активно развивается
— Yii вышел в 2008 году, то есть является проверенным инструментом
Да, у него есть минусы, но надежность превыше всего
Сайт icons8.com — не блог но и не «Hello, world!» — 3 мегабайта на страницу. Естественно, всё и вся кэшируется. Да, есть memcached и даже Redis, но настроен автоматический fallback в файловый кэш, на всякий случай.