... этих систем
поддерживают использование ... тегов для объектов
, однако Memcached ...
Предисловие
В процессе разработки с использованием связки Zend Framework + Memcached приходится сталкиваться иногда как с (чрезмерной) обильностью имеющегося функционала фреймворка, так и с определёнными ограничениями. Об одном из таких случаев и найденном решении я и попытаюсь рассказать в этой статье.
Описание проблемы
Как известно, Memcached представляет собой относительно простое для использование Key/Value хранилище с простым, необходимым и достаточным функционалом. Предоставляемые ZF интерфейсы для взаимодействия с Memcached включены в общую библиотеку работы с кешем (включает в себя также адаптеры для Sqlite, Xcache, ZendServer и т.д.). Некоторые из этих систем кеширования поддерживают использование тегов для объектов кеширования, однако Memcached такой функцией не обладает, поэтому попытки использовать стандартные интерфейсы классов ZF для кеширования объектов с указанием тегов при работе с Memcached приведут лишь к ошибкам (в логах) вплоть до исключений. (Подробнее можно прочитать в документации).
Читать дальше →
... языку и системе
.
Описание проблемы
Представим среднестатистический высоконагруженый сайт. Обычно на таких сайтах между backend'ом и DB ставят прослойку кеша. С увеличением количества посетителей, вероятность того, что несколько пользователей одновременно наткнутся на "протухший" кеш увеличивается. Если такое случается, то нагрузка на backend и DB возрастает, что в свою очередь увеличивает время обработки запроса и увеличивает вероятность возникновения подобной ситуации. Вот такая вот система с положительной обратной связью:

Маленькие красные горбики — это "затупившие" на множественном обновлении кеша запросы.
Эта статья будет описывать один из подходов к решению проблемы на примере(
patch attached
) связки
PHP
/
APC
, однако теоретическая база
применима к любому языку и системе кеширования.
Читать дальше →
... большими нагрузками, включив
. Для этого существует ...
О пошаговых html формах написано не мало и в общем то ни чего особенного в реализации нет. Обычное ...
О пошаговых html формах написано не мало и в общем то ни чего особенного в реализации нет. Обычное дело для получения от посетителя объемных и связанных данных, многим не раз приходилось решать такую задачу.

Чуть более сложнее обстоит дело с реализацией, если пользователю необходимо предоставить возможность возврата на предыдущие шаги формы, с сохранением заполненных ранее данных (отмечу, что речь идет о форме в которой каждый шаг — отдельная страница). Когда требовалась такая функциональность и было не много данных (полей формы) я пришел к следующему решению:
- На каждом шаге проверяются данные в специальных hidden input-ах и при наличии используются при подстановке значений полей формы
- Каждый следующий шаг принимает POST данные с предыдущего(их) шагов, сериализует и добавляет в специальные hidden input-ы
- Action формы меняется динамически (js) в зависимости от нажатия кнопки «Вперед» или «Назад», т.е. либо url следующего шага, либо предыдущего
- После чего также с помощью js производиться submit формы
Но такой подход имеет проблему с потерей введенных ранее данных при переходе по прямому url (без submit-а) на любой шаг.
Усложняем задачу