Войти в систему

Home
    - Создать дневник
    - Написать в дневник
       - Подробный режим

LJ.Rossia.org
    - Новости сайта
    - Общие настройки
    - Sitemap
    - Оплата
    - ljr-fif

Редактировать...
    - Настройки
    - Список друзей
    - Дневник
    - Картинки
    - Пароль
    - Вид дневника

Сообщества

Настроить S2

Помощь
    - Забыли пароль?
    - FAQ
    - Тех. поддержка



Пишет mumuntu ([info]mumuntu)
@ 2010-09-20 06:27:00
Previous Entry  Add to memories!  Tell a Friend!  Next Entry
Хочу передать пламенный привет архитекторам системы "Битрикс", которые кэшируют на диск куски генерируемого PHP-кода.
Для начала, я не понял, зачем вы вообще генерируете то, что туда кэшируете.
Далее, я не понял, зачем вы это пытаетесь исполнить.
Я попал в достаточно редкую ситуацию - похоже, коробка упала как раз в тот момент, когда битрикс писал файл в этот самый кэш, в результате чего файл просто не дописался.
Оставшийся в нем мусор пытался выполниться каждый раз при определенных условиях, в результате чего часть функциональности портала просто отрубилась.
Тянете в рот всякое дерьмо, чисто как дети, а.
Забавно, что expiration date прописана прямо внутри файла, что исключает возможность отдискардить этот мусор автоматически по прошествии времени.

(Добавить комментарий)


[info]rogovsky@lj
2010-09-20 02:24 (ссылка)
Эта система работает за счет откатов, а не PHP кода :)

(Ответить) (Ветвь дискуссии)


[info]nivanych@lj
2010-09-20 03:32 (ссылка)
Перефразируя и чуть обобщая -
не всегда для заработка на программном продукте нужно хоть какое-то его качество ;-)

(Ответить) (Уровень выше)


[info]dil@lj
2010-09-20 03:44 (ссылка)
А я не понял, зачем они генерируют php-код

(Ответить)


[info]gmother_arised@lj
2010-09-20 04:20 (ссылка)
а если вручную удалить весь кеш - он его не восстанавливает?

(Ответить) (Ветвь дискуссии)


[info]alexclear@lj
2010-09-20 04:36 (ссылка)
Я не пробовал весь кэш удалять, только отдельные файлы.
Думаю, восстанавливает.

(Ответить) (Уровень выше)


[info]mkevac@lj
2010-09-20 09:53 (ссылка)
Проще почистить кэш в такой редкой ситуации, чем городить кучу кода для проверки записанного файла.

(Ответить) (Ветвь дискуссии)


[info]alexclear@lj
2010-09-20 10:02 (ссылка)
Проверять надо прочитанный файл, а не записанный.
Кода выйдет строчек, может, двадцать-тридцать.
Это включая именование файла таким образом, чтобы его можно было экспайрить, даже не читая.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]mkevac@lj
2010-09-20 10:11 (ссылка)
Это здесь может и можно его проверить легко. Не знаю что там с PHP. Но это не всегда так с бинарными данными.

(Ответить) (Уровень выше)


[info]korchasa@lj
2010-09-20 10:42 (ссылка)
Как проверить, что РНР-файл валиден? Читать его с диска? Какой тогда смысл кэширования в РНР-код?

С именованием косяк, конечно.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]alexclear@lj
2010-09-20 10:45 (ссылка)
> Как проверить, что РНР-файл валиден? Читать его с диска?

Прочитать, сделать синтаксический разбор средствами самого PHP, там есть для этого какие-то функции, подробностей не помню.

> Какой тогда смысл кэширования в РНР-код?

А никакого, по-моему.
Я не могу поверить, что у них в движке есть какие-то операции, выполнение которых делается медленнее, чем запись и чтение с диска.
Тем более, что они кэшируют в том конкретном куске, на котором споткнулось у меня, данные, причем, сериализованные.
Ну так и писали бы данные как данные, зачем было их в код оборачивать.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]korchasa@lj
2010-09-20 10:48 (ссылка)
Чтобы использовать прелести opcode-кэшеров. С диска в этом случае ничего не читается, да и парсинга нет.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]alexclear@lj
2010-09-20 10:54 (ссылка)
Ну правильно - сериализованные данные надо же не на диск писать, а в memcached.
На диск лучше вообще ничего не писать без крайней необходимости, тем более, кэш.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]korchasa@lj
2010-09-20 10:58 (ссылка)
У них может не быть memcached. Тут бы и APC хватило, оно умеет быть кэш-стораджем. А им нужно более общее решение, они же коробка. Да и зачем куда то бегать по сети, если можно этого не делать.

(Ответить) (Уровень выше)


[info]korchasa@lj
2010-09-20 10:52 (ссылка)
Защиту от недозаписи можно, конечно, сделать - писать во временный файл, потом переименовывать. Надо посмотреть как у нас сделано.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]alexclear@lj
2010-09-20 10:57 (ссылка)
Да, отличный вариант, кстати.
И имплементируется несложно.

(Ответить) (Уровень выше)


[info]alexshubert@lj
2010-09-21 06:23 (ссылка)
Сашенька, я так рад, что ты еще жив и в добром здравии

(Ответить) (Ветвь дискуссии)


[info]alexclear@lj
2010-09-22 09:06 (ссылка)
Взаимно
Как у тебя-то дела?
Я может, до зимы в Мск приеду в гости

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]alexshubert@lj
2010-09-22 09:22 (ссылка)
Правильно сделаешь.
у меня все смешно, расскажу при встрече.
Немного удивлен твоей пропажей отовсюду, надеюсь, причина в огромном количетсве клевых проектов

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]alexclear@lj
2010-09-22 10:05 (ссылка)
> причина в огромном количетсве клевых проектов

Все не так просто
То есть, причина верна, но проекты не слишком клевые

(Ответить) (Уровень выше)


[info]irishterrier@lj
2010-09-30 15:03 (ссылка)
кэширование на диск достаточно общий метод - мемкэша может и не быть, сам по себе такой механизм включен в различные фремвеки от шаблонизатора smarty до db-layer в Zend. по опыту могу сказать, что проект (железо года ~2004, 50 000 уников, DB ~ 20 таблиц, в под 70 000 записей) без дискового кэша в пиковое время показывал загрузку под 99% с ним ~50% хотя точные цифры могу наврать, но без кэша сайт ложился , с ним работал прекрасно в штатном режиме -- потому админы и мемкэшом не стали чесаться, а потом случилось всякое с самой компанией). Зачем его еще раз исполнять -- если битрикс пошел по пути смарти (то есть кэширует сгенрированную страницу), а не зенд (sql выборку) , то возникают вопросы о подстановке некэшируемых данных, типа банеров, пользовательского контента и чего-либо подобного, соответственно, эта часть подставляется из контроллера при каждом запросе. битрикс никогда не копал - просто разумное предположение. Ну и да, конечно, коллега выше прав -- правильный алгоритм писать во временный файл и делать ренэйм после. :)

(Ответить)