Благодаря copy-on-write, такого не должно происходить. У меня не происходит. Но в доках, что-то читал про возможные проблемы на линуксах, я не особо вчитывался.
Невозможно, если архитектура изначально проектировалась на использование кеша. А это так в данном случае.
Само использование кеширования трансформирует арххитектуру системы. Например, обычно стараются делать меньше запросов. Кеширование же по событиям побуждает разбивать запросы на более простые, чтобы их можно было кешировать и инвалидировать независимо. Поэтому простое отключение кеша, даже если бы оно было возможно под нагрузкой, не даст адекватного сравнения.
От CACHEOPS_PROFILES, возможно, следует отказаться, не вижу я в нём особого толка пока.
Файловый кеш вообще не документирован пока, так что документировать его настройки было бы странно.
Ага, если «сделать всё правильно», то массовый апдейт с условием ортогональным условиям в выборка сбросит весь кеш. Что как-то не очень. Поэтому такие ситуации придётся обрабатывать вручную. К счастью, они не особо часты.
Тоже некоторое время использовал сессии в редисе, собственную реализацию. Когда занимаемая память перевалила через 400 мб, понял что надо от этого избавляться. Переделал на сессии в подписанных куках, это просто просветление — ничего не надо хранить, никуда делать запросов, сессия приходит вместе с запросом.
Какой прирост сложно сказать, проект в котором этот кеш используется, до его применения был реализован на совсем другой платформе. Но прирост есть.
И дело не только в экономии времени, такая автоматическая система позволяет кешировать, грубо говоря, все запросы к БД, что здорово её разгружает. А сервера приложений масштабировать в случае надобности куда проще.
А так неприятно в любом случае. Можно в письме рядом с паролем делать ссылку сменить пароль, на всякий случай. Ссылка должна заходить без ввода пароля естественно.
Творческий потенциал, может быть, статья не об этом. Сужение мышления уже ближе.
Мораль в том, что вы можете не увидеть возможность понижения уровня абстракции кода из-за кажущейся неделимости синтаксических конструкций. А понизить уровень абстракции бывает необходимо, чтобы устранить дублирование или просто добавить гибкости.
Понятие сахара относительно. Можно все циклы делать через map, можно все отображения (map) делать через for. Выбор зависит от предпочтений для каждого конкретного случая.
Я хочу отобразить список полей в список их имён поэтому map, кажется более подходящим.
Насчёт того, в чем другой человек быстрее разберётся — это зависит уже от его опыта и его предпочтений, но в вакууме, чем короче код или точнее чем меньше в нём синтаксических элементов, тем быстрее он читается.
Перловый вариант покрасивше будет. Да и по смыслу лучше — ты говоришь last или next поименнованному циклу, тут же ты выбрасываешься наружу. Синтаксис для настоящих самураев.
Само использование кеширования трансформирует арххитектуру системы. Например, обычно стараются делать меньше запросов. Кеширование же по событиям побуждает разбивать запросы на более простые, чтобы их можно было кешировать и инвалидировать независимо. Поэтому простое отключение кеша, даже если бы оно было возможно под нагрузкой, не даст адекватного сравнения.
Файловый кеш вообще не документирован пока, так что документировать его настройки было бы странно.
Документации далеко до полноты, это верно
Факт в том, что не требуется много информации, чтобы выдать большинство страниц. Частные случаи, для отдельных страниц следует решать отдельно.
И дело не только в экономии времени, такая автоматическая система позволяет кешировать, грубо говоря, все запросы к БД, что здорово её разгружает. А сервера приложений масштабировать в случае надобности куда проще.
Мораль в том, что вы можете не увидеть возможность понижения уровня абстракции кода из-за кажущейся неделимости синтаксических конструкций. А понизить уровень абстракции бывает необходимо, чтобы устранить дублирование или просто добавить гибкости.
Я хочу отобразить список полей в список их имён поэтому map, кажется более подходящим.
Насчёт того, в чем другой человек быстрее разберётся — это зависит уже от его опыта и его предпочтений, но в вакууме, чем короче код или точнее чем меньше в нём синтаксических элементов, тем быстрее он читается.