В PHP приложении есть несколько тяжелых и сложных объектов, которые необходимо инициализировать при старте практически каждого скрипта. При инициализации, эти объекты выполняют подключение к базам данных, загрузку справочников, построение хитрых структур данных в памяти, всякие проверки и т.п. То есть тяжелая для CPU и RAM операция, которая выполняется практически при каждом обращении к серверу. После завершения скрипта объекты разрушаются, и при следующим запуске скрипта опять начинается тяжелая инициализация (стандартная схема работы с PHP).
Хотелось бы создать эти объекты только один раз и держать их в памяти постоянно готовыми, так, чтобы при выполнении скриптов не происходила постоянная переинициализация объектов. А то эта постоянная переинициализация съедает 90% ресурсов, хотя реально ее можно делать раз в сутки.
Я думал реализовать эти объекты как отдельный серверный процесс, где они однократно инициализированы при старте и обращаться к ним например по XML/JSON протоколам. Или кидаться сериализованными PHP-объектами.
Какие есть подходы для такой архитектуры? Что бы вы посоветовали использовать? Хотелось бы иметь поменьше прослоек. В идеале, хочется обращаться к этим объектам как к обычным объектам PHP.
Еще думал, что бы просто кэшировать такие объекты в виде сериализованного объекта, а при десериализации выполнять проверку, не пора ли обновить объекты в кэше. Но это какое то костыльное решение.
Сериализуйте объекты в инициализированном состоянии и только восстонавливайте их при каждом запросе.
Подключения к базам и прочее, делайте по мэджик методу __wakeup (или __set_state если используете var_export).
Причем большинство "подключений к базе" не потребует дополнительной работы за счет сохранения состояния между запросами на уровне расширения.
Ну и не забудьте сделать профилирование, а то может спички оптимизируете на самом деле.
Так же можно использовать job сервера в блокирующем режиме. Так как воркер обычно постоянно висит в памяти, инициализация тяжелых объектов происходит единижды.
Таким образом, при написании небольшой прослойки получается объект с данными и любой логикой их подготовки для клиентского кода.
Средний
