Комментарии 25
Что-то я как-то начинаю смотреть в сторону Yii
Symfony очень удобный и производительный фреймворк. Даже метафреймворк. На его базе можно создавать множество различных приложений. В том числе и фреймворков. Например, Silex.
Есть просто некоторые вещи, которые неудобно делать. А именно, проекты где контент меняется в зависимости от авторизации пользователя. Причем когда этого контента много. Как в случае с хабром. И то это проблема больше реализации кэша, чем самого Symfony. Ничто не мешает написать свою оболочку.
Есть просто некоторые вещи, которые неудобно делать. А именно, проекты где контент меняется в зависимости от авторизации пользователя. Причем когда этого контента много. Как в случае с хабром. И то это проблема больше реализации кэша, чем самого Symfony. Ничто не мешает написать свою оболочку.
А почему не на ZF2, как там у него дела, не знаете?
Вроде еще нет финального релиза 2-й версии.
Обычно работа с Zend Framework начинается со встраивание в него Doctine ORM и становится как в symfony, очень уж неудачное решение Zend_Db_Table, не в курсе что там изменят в ZF2
я использовал всегда свои DAO классы
Если свой, то проще дописать обёртку к Zend_Db_Table. По крайне мере до того что предлогают во второй довести не проблема framework.zend.com/wiki/display/ZFDEV2/ActiveRecord+-+Arthur+Bodera
Другое дело, что хочется их коробки с документацией, чтобы тот кто будет дорабатывать проект или сам через год не забыл как это работает.
Другое дело, что хочется их коробки с документацией, чтобы тот кто будет дорабатывать проект или сам через год не забыл как это работает.
Лучше посмотрите в сторону Rails. Я после года плотного использования Yii погрузился на неделю в Ruby и Rails и теперь не могу без боли смотреть на PHP, а уж что касается кода Symfony… там конечно все очень круто и очень 'decoupled', но столько лишней писанины, жесть просто.
мы в нашем проекте после 2 месяцев тыканья в симфони 2.0 перешли на Yii. Вся команда в диком восторге, 01.11 в опытно-промышленную эксплуатацию запустились вот.
>>Решение данной проблемы я пока не нашел. Возможно, хабрасообщество поможет.
Читаем внимательно
Читаем внимательно
А можно подробнее? Я не понял, что вы имеете ввиду.
Там написано что если отдавать в заголовке public — то кеш считается одним на всех пользователей. Если отдавать private — то для каждого пользователя свой кеш. По-умолчанию кеш считается private
Правильно. И на уровне Symfony это работает. Но Varnish видя куку не авторизованного пользователя это дело не кэширует. Как различить в Varnish авторизованного и не авторизованного пользователя я пока не нашел.
Что-то вы видимо не так делаете. Причём тут вообще Varnish к пользователям внутри вашего приложения
И вообще кука создается всегда. При вызове session_start() например. Авторизирован пользователь или нет, у него всегда будет кука как минимум с PHPSESSID и она всегда будет разная для каждого нового пользователя. Тогда по вашей логике кеш долен быть всегда разный для каждого пользователя. Но ведь не зря же существует private и public. И что это за термин вообще такой — «уникальная кука»?
И вообще кука создается всегда. При вызове session_start() например. Авторизирован пользователь или нет, у него всегда будет кука как минимум с PHPSESSID и она всегда будет разная для каждого нового пользователя. Тогда по вашей логике кеш долен быть всегда разный для каждого пользователя. Но ведь не зря же существует private и public. И что это за термин вообще такой — «уникальная кука»?
1. Varnish по-умолчанию не кэширует страницы при наличии куки.
2. Кука создается всегда при старте сессии. Не стартовать сессию для не авторизованных пользователей в Symfony нельзя, пользуясь стандартным механизмом Security Component.
3. Научить Varnish игнорировать конкретную куку можно, но как по ней различить авторизованного пользователя(кэшировать нельзя) и не авторизованного(кэшировать можно) я пока не придумал и не нашел.
4. уникальная кука — имелось ввиду значение.
2. Кука создается всегда при старте сессии. Не стартовать сессию для не авторизованных пользователей в Symfony нельзя, пользуясь стандартным механизмом Security Component.
3. Научить Varnish игнорировать конкретную куку можно, но как по ней различить авторизованного пользователя(кэшировать нельзя) и не авторизованного(кэшировать можно) я пока не придумал и не нашел.
4. уникальная кука — имелось ввиду значение.
Почитал документацию по варниш.
Varnish will not cache a object coming from the backend with a Set-Cookie header present. Also, if the client sends a Cookie header, Varnish will bypass the cache and go directly to the backend.
Очень странно. Т.е. получается что варниш вообще никогда не будет кешировать ничего, так как клиент постоянно отправляет Cookie в заголовке. Бред какой-то
Varnish will not cache a object coming from the backend with a Set-Cookie header present. Also, if the client sends a Cookie header, Varnish will bypass the cache and go directly to the backend.
Очень странно. Т.е. получается что варниш вообще никогда не будет кешировать ничего, так как клиент постоянно отправляет Cookie в заголовке. Бред какой-то
Мне кажется название статьи должно быть не «подводные камни», а проблемы с кэшем. Или что-то в этом роде.
2 схожих по функционалу проекта даже на одном фреймворке можно написать так, что количество запросов в секунду будет различаться на порядок.
там целая куча вариантов кеширования. просто глужбе надо копать :) может клад найдете :)
Также, исходя из идеологии кэширования, Symfony2 лучше не использовать в проектах, где контент меняется в зависимости от авторизации пользователя.
не согласен, можно,
1. роль, ADMIN SUPER_ADMIN
2. аутентификация: IS_AUTHENTICATED_FULLY
объясните, в чем причина, если не прав :)
не согласен, можно,
1. роль, ADMIN SUPER_ADMIN
2. аутентификация: IS_AUTHENTICATED_FULLY
объясните, в чем причина, если не прав :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Symfony2. Подводные камни кэширования