6 ms·

Thank you for your reply. I will have a play with it if I find some free time. It's not the memory leaks in _my_ code I'm so worried about, it's the ones in oth

Thank you for your reply. I will have a play with it if I find some free time. It's not the memory leaks in _my_ code I'm so worried about, it's the ones in other people's code :-) e.g. Doctrine used to leak like a sieve and no amount of free()s and unset()s cleared the ORM objects up under some circumstances. Long-running Symfony tasks were a great way to illustrate that. It seems like a sensible approach to auto-restart the processes once memory_limit is exceeded.

bergie 15y ago
During one minute of siege to the "hello world" example from my blog post, the memory usage of my PHP processes didn't change. 13958 bergie 20 0 125m 10m 2136 S 1 0.6 0:00.28 php 13959 bergie 20 0 125m 10m 2136 S 1 0.6 0:00.31 php
- bergie 15y ago
  And the same thing with Node: 14051 bergie 20 0 615m 12m 4988 S 0 0.7 0:00.34 node Node and ExpressJS did 3.79 transactions per second, AiP and Silex did 3.80
- morganpyne 15y ago
  While I'm relieved to see that, I wouldn't expect anything less from a trivial example such as this. I wonder if the same would be true if you hit a database, hydrated a one-to-many related series of objects from multiple tables using an ORM, modified some of them and save them etc. However, I don't mean to harp on about the memory leaks; It's just that it seems to have been an assumed wisdom in my long association with PHP that you're going to need to restart PHP processes eventually. Perhaps the GC in 5.3 alleviates some of these concerns (including detection of circular references), as does the maturing of the code base and the commonly used libraries over the years. The fact that you are using AiP happily in production already means that there is both a niche and a successful way to implement this so I'm glad to see new approaches like this emerging.
  - bergie 15y ago
    The setup we run with AiP is the full Midgard Create stack: Midgard2 extension, Midgard MVC framework, a lot of CMS components. http://bergie.iki.fi/blog/introducing_the_midgard_create_user_interface/ http://bergie.iki.fi/blog/introducing_the_midgard_create_use...
  - indeyets 15y ago
    Hi. I am the author or AiP. There were a lot of leaks, when I tried this idea originally, back in php 5.2 days. See http://blog.milkfarmsoft.com/2007/06/php-as-appserver-vs-memory-leaks/ http://blog.milkfarmsoft.com/2007/06/php-as-appserver-vs-mem... for example. But 5.3 solved all of the issues. The only leaks happening these days come from "unofficial" extensions, which introduce errors on C-level. PHP code _never_ results in memory leaks these days, as far as I know.

bergie 15y ago

During one minute of siege to the "hello world" example from my blog post, the memory usage of my PHP processes didn't change. 13958 bergie 20 0 125m 10m 2136 S 1 0.6 0:00.28 php 13959 bergie 20 0 125m 10m 2136 S 1 0.6 0:00.31 php

bergie 15y ago
And the same thing with Node: 14051 bergie 20 0 615m 12m 4988 S 0 0.7 0:00.34 node Node and ExpressJS did 3.79 transactions per second, AiP and Silex did 3.80
morganpyne 15y ago
While I'm relieved to see that, I wouldn't expect anything less from a trivial example such as this. I wonder if the same would be true if you hit a database, hydrated a one-to-many related series of objects from multiple tables using an ORM, modified some of them and save them etc. However, I don't mean to harp on about the memory leaks; It's just that it seems to have been an assumed wisdom in my long association with PHP that you're going to need to restart PHP processes eventually. Perhaps the GC in 5.3 alleviates some of these concerns (including detection of circular references), as does the maturing of the code base and the commonly used libraries over the years. The fact that you are using AiP happily in production already means that there is both a niche and a successful way to implement this so I'm glad to see new approaches like this emerging.
- bergie 15y ago
  The setup we run with AiP is the full Midgard Create stack: Midgard2 extension, Midgard MVC framework, a lot of CMS components. http://bergie.iki.fi/blog/introducing_the_midgard_create_user_interface/ http://bergie.iki.fi/blog/introducing_the_midgard_create_use...
- indeyets 15y ago
  Hi. I am the author or AiP. There were a lot of leaks, when I tried this idea originally, back in php 5.2 days. See http://blog.milkfarmsoft.com/2007/06/php-as-appserver-vs-memory-leaks/ http://blog.milkfarmsoft.com/2007/06/php-as-appserver-vs-mem... for example. But 5.3 solved all of the issues. The only leaks happening these days come from "unofficial" extensions, which introduce errors on C-level. PHP code _never_ results in memory leaks these days, as far as I know.