Is the future of PHP in jeopardy?

I’d generally argue that the main reason PHP is keeping going is not because of breathtaking new work in PHP but because drupal and wordpress have won large parts of the CMS war at this point. Making significant breaking change would break those apps and if you are starting fresh in 2014 do you a) pickup some new, potentially broken version of a language without a great reputation or b) pick up something like python or ruby which has loads of solid options, good standard libraries and effective benevolent dictators making sure the language don’t get too FUBAR.

Moreover, many of the sorts of features advanced developers would want perhaps fly in the face of PHP’s other use case – for “designer-developers” who aren’t looking to make sense of a MVC framework, they are just trying to get a little server-side voodoo into what is really a static HTML site.

So basically PHP has hit a point where they are damned if they go forward and damned if they don’t go forward.

Well, I think you’ve hit the nail on the head there. It sounds like Zend corporation is playing the strategy of keeping PHP backwards compatibility going for as long as possible and future improvements are not a priority as that goes against their business model of keeping PHP as pervasive as possible.

Look what happened to Cobol 20 years ago. You virtually never hear of it today. They tried to bring out an object oriented version but it never went anywhere. Nevertheless, back in those days, Cobol developers were in great demand but primarily to keep their legacy apps going.

PHP is not quite in the same boat but its close. PHP still has the advantage of a small memory footprint. However there is a real chance it would go the way of Perl, becoming of interest only to “language archaeologists”.

Yet your phone billing system and airline ticketing system run COBOL (or other things of that era). There won’t be much new PHP work in 20 years but I’ll bet you can keep body and soul together patching 25+ year old apps.

On memory – I think PHP “cheats” a bit here. Unlike everything you’d compare it with the memory lifecycle of any PHP script is just the script wheras just about everything else anyone programs anything in in 2014 has some sort of persistent server running. So PHP is alot more approachable for the uninitiated – leaving a database connection open has little consequence if everything just ceases to exist at the end of execution. And it also means that PHP doesn’t sit on ram and occupy resources at rest the same way a ruby or uwsgi or .NET app would.

That’s an interesting point as I made the same argument (against certain rails deployments) here:

I did a quick Google of uWSGI vs WSGI. I generally use Django with WSGI which is an apache module Wheras uWSGI is not. uWSGI runs as a separate process with all the extra ram that entails.

The claim seems to be that if you have web application processes sitting around all the time, that they eliminate the startup and shutdown time of a script that needs to be invoked on every request.

However the feeling I got is that PHP didn’t perform badly in language benchmarks so maybe I need to see if I can get some good stats on that.
In most web applications its not the language performance that matters but the database performance and the biggest lag in the request/response cycle seems to be I/O bound (database lag) most of the time. However I must admit I haven’t done any high volume traffic testing with php against other language or framework configurations but would be interesting.

.NET doesn’t sit on ram and occupy resources at rest. It is entirely dependent on how your IIS is setup, but by design, it doesn’t do that. I use that daily, and I’d see that, if that were happening.

.NET definitely sits on RAM when you’ve got the app pool spun up – that is somewhat by design though. They trade an ugly first hit and big load for very, very fast loads behind it. You’ve certainly experienced this if you have done any .NET development.

As for .NET and IIS, the default is to spin down app pools after 20 minutes as well as automatically recycle apps once a day – both were precedents from previous IIS setups and from the day where you were running some horribly memory leakin. From what I understand, the general recommendation out of Redmond these days is to never spin down nor recycle automatically if you can help it. In any case, inside of the bounds of the app pool a .NET app is certainly persistent across requests even if an individual Page (or Controller) is a per-request instance. You can certainly shoot your app in the foot by failing to properly clean up resources or mishandling static variables.

There is a lot more than startup time involved in the differences. PHP’s shared nothing model lets one do some things very quickly but precludes a lot of fancy stunts (such as dynamic-proxy based ORMs) that other platforms excel in. I don’t think benchmarks make a whole lot of sense in general but especially between platforms – end of the day the question isn’t who can serve the most pages on the least hardware but “do you have enough throughput to keep your customers happy at a price you can afford.”

On first hit, it may cache your runtimes, but it doesn’t just sit there automatically and it disappears after a lack of requests. This is as you say to ensure quick runtime, but I think it is a bit misleading to say it sits in memory all of the time, that part just isn’t true.

So maybe a difference in how it is “stated” more so than anything here between us. I’ve written a LOT of sites in IIS and the memory usage of the server isn’t all that different from some of the Linux PHP servers I’ve built. You’ll see it rise at the application being hit, and go back down when it isn’t (granted in .NET servers it goes down a bit slower due to waiting to ensure there isn’t another request coming in – unless you knock down the app pool spin down time significantly).

The servers I’ve setup, we never have to restart/recycle the app pools unless we need to clear the cache (and that is only because we never have zero requests coming in long enough for the app pools to spin down).

I think you are a bit mistaken here – the app domain remains in memory so long as it’s containing app pool is alive. App pools by default shut down after 20 minutes of inactivity so they do “disappear because of lack of requests” but for no reason internal to ASP.NET and everything to do with the hosting environment. This is unlike PHP where the longest anything can stay in memory is the life of the script period end of story. As I said the auto recycle (every 1740 minutes to be exact) is also there by default unless you actively disable it.

Where this memory use matters is in the land of el cheapo shared hosting – you can pack a lot more low-load PHP sites on a server and not see side effects than you can for any other platform because resource use is so focused to the execution time which is typically measured in milliseconds even for the slowest scripts. Contrast this with ASP.NET where that first hit and all the JIT stuff takes a fair amount of CPU and that app domain is going to want to remain standing for a bit consuming precious memory.

If you are dealing with dedicated servers and non-trivial apps then you’ll likely see somewhat similar resource consumption for similar scales of traffic no matter what the platform.

Yes, but that is IIS, not .NET. I could just as easily create my application using mono, host it in apache and see that it doesn’t use any additional memory just sitting there. .NET is not the culprit here. So I’m not mistaken.

I don’t buy that one bit. It is entirely dependent on how poorly the script is written, it isn’t hard to see the affects of one bad site on a shared hosting account with PHP. Just because it doesn’t sit there idle, doesn’t mean it can’t affect memory worse.

So does PHP, all execution occurs on every hit, thus CPU and memory shoot up. With .NET at least, the subsequent hits on CPU and memory are far less. Plus the only thing really sitting in memory (and I’m not sure this is true; as .NET utilizes temporary folders to hold dlls processed recently by JIT), would be the basics for needing to kick the app off again quickly, it isn’t storing much more than a bare minimum initialization process in actual memory.

We have servers setup with over 50 app pools and 50 sites, no problems what-so-ever. There are 16 GB of RAM so across each app pool, there is roughly .32 gigs each. If memory were really an issue, this server would show it, but it doesn’t.

This is getting to be quite a bit of a derail but what the hey I’ll bite.

You are certainly mistaken about Mono’s structure – see http://www.mono-project.com/Mod_mono for details but mono clearly runs as a separate process and persistent apps server behind apache. Reading through the documentation it seems that it works much like phusion passenger does for ruby or uwsgi apps in terms of mating apache with a persistent back end that apache does not do well at.

In any case the model works like this – you have an app pool which has an application manager which in turn spins up and destroys app domains. App domains are what your program typically sees – IE if you have a typical static class with a static member variable it is shared throughout the app domain. Individual requests are threads within said app domain in general. Overall, you might want to read http://www.west-wind.com/presentations/howaspnetworks/howaspnetworks.asp – it is a bit dated (based on IIS6) but still very valuable in terms of understanding the nuts and bolts here.

I don’t buy that one bit. It is entirely dependent on how poorly the script is written, it isn’t hard to see the affects of one bad site on a shared hosting account with PHP. Just because it doesn’t sit there idle, doesn’t mean it can’t affect memory worse.

You can certainly bring down the server in a single badly written script in any language. But that is fundamentally harder to do when the script has a limited lifecycle and will either hit the memory limit or the timeout and die. Compare that with persistent app servers which will continually leak memory until they have to be reset and also keep other apps and then keep soaking up RAM.

So does PHP, all execution occurs on every hit, thus CPU and memory shoot up. With .NET at least, the subsequent hits on CPU and memory are far less. Plus the only thing really sitting in memory (and I’m not sure this is true; as .NET utilizes temporary folders to hold dlls processed recently by JIT), would be the basics for needing to kick the app off again quickly, it isn’t storing much more than a bare minimum initialization process in actual memory.

Exactly – .NET loads a lot up front then subsequent requests are cheaper. I’d also note that PHP tries to do at least some of this stuff inasmuch as most modern php setups include an opcode cache to cut down on the work of parsing the php script every time it is requested. I know the WebPI version includes this by default; most *nix setups include APC or something similar. You might want to do some memory profiling of your own apps – my general experience is that if an app is typically using 250mb of RAM then you’ll see it eat 175 or so on the 1st request and ramp up a bit after as caches and pages get hit and hydrated to memory.

We have servers setup with over 50 app pools and 50 sites, no problems what-so-ever. There are 16 GB of RAM so across each app pool, there is roughly .32 gigs each. If memory were really an issue, this server would show it, but it doesn’t.

That is pretty typical usage – our big, mean, busy apps sit in ~250mb app pools, the lower priority ones seem to live in ~150mb. Moreover, for a typical oversold shared hosting scenario 50 apps is a drop in the bucket – how would your servers handle 5000 apps at that scale? That is apparently a light load for alot of the $3/mo hosting outfits – the more the merrier there.

FWIW, from what I know bad mojo starts happening when the app pool hits 6-800mb though that could have been a .NET 2.0 thing as we’ve typically avoided said mojo since those days so I don’t know if that has moved a bit.