prime aip instance after an auto-restart

12 views
Skip to first unread message

Lukas Kahwe Smith

unread,
May 13, 2011, 6:12:45 AM5/13/11
to aip-p...@googlegroups.com
Hi,

I read the following comment:
"AiP workers die when PHP's memory_limit is exceeeded, and AiP will then restart them."

http://news.ycombinator.com/item?id=2544061

Now obviously after a restart the instance will perform slower as classes need to be reloaded etc. Is there a way to hook in some priming script that must be run before that particular AiP instance may be used again. I am mainly thinking about l loadbalanced setups where I can afford to keep a server out of the rotation in order to prevent latency spikes for users.

regards,
Lukas Kahwe Smith
m...@pooteeweet.org

Alexey Zakhlestin

unread,
May 13, 2011, 7:49:04 AM5/13/11
to aip-p...@googlegroups.com
Usually, application is represented by object of a class, which has __invoke() method. But, this class also has __construct(), which can be used for any kind of initialization. That's exactly what we use in all of our setups.


Is that enough? Or you need something more complex?

Lukas Kahwe Smith

unread,
May 13, 2011, 2:39:30 PM5/13/11
to aip-p...@googlegroups.com

No, I guess that should be sufficient.
One thing though, does the AiP instance block while the constructor is executing?
if you start doing a lot of work in the constructor this could become a problem. Then again I guess one could then simply as a first step remove the given server from the loadbalancer, do the priming and then readd the server to the loadbalancer. however i guess this would all lead to one poor request that caused the memory overflow to wait ages for a response? wonder if there is a graceful way to forward that single request to a different server.

Alexey Zakhlestin

unread,
May 13, 2011, 4:30:24 PM5/13/11
to aip-p...@googlegroups.com

Well… usually, AiP works using pre-fork model, with child-processes starting to accept connections after initialization is finished.
I don't see why there should be any slow requests (less active workers = less requests per second, but request-speed should be the same)

The only possible reason for the slow request is if some initialization happens lazily during request-processing, and not in constructor.

Lukas Kahwe Smith

unread,
May 13, 2011, 4:32:56 PM5/13/11
to aip-p...@googlegroups.com


ah ok .. so as long as i do the priming inside the constructor i am fine? sounds good .. even great! :)

Reply all
Reply to author
Forward
0 new messages