Gracias a artículos o comentarios como estos, seguiremos trabajando con PHP. Desde hace mucho tiempo desarrollo con php y hasta ahora no he encontrado algo mejor para trabajar mis aplicaciones web’s. Espero que siga así por mucho tiempo, buena esa Bicking..!

This also means that PHP apps (Wordpress for example) end up having a huge range of extensions/plugins etc. (getting away with sloppy coding helps).

Doesn’t that get you pretty close to mod_php’s sandboxing/etc?

I had to do something like this to address a memory leak. I ‘died’ my script after more than one request, but the same principal applies.

PHP definitely has some big advantages in this realm.

• automagic resource, variable and memory teardown PER REQUEST (this is teh magic, baby)

  This is what gives imho php a bad rep on slashdot: you can code sloppy and get away with it! global vars are ok!

• no shared state (almost, and you can put that in the db, generally).

  I had a “revelation” moment once when I rewrote a C app running on text only wireless terminals: turning the quite-standard app into a simple “browser” that a - sent queries to the server and b - always displayed back the received results as ‘a page’ (plus handled a couple of error codes) shrank the codebase to one third, eliminated bugs and most importantly made all subsequent evolutions trivial (just change your code inside the db / server, no more recompiling or deploying ever!). State is your enemy!

• nice process / application isolation is a huge bonus, too, even though it is still quite common and not so unlikely to bring a server to his knees (tight neverending loop, allocating huge chunks of memory or a huge number of db connecions or filling up your partition with logs, etc).

All in all my only wish is for even more sandboxing and isolation, eg. running code at different security levels, only allowing a subset of functions/operations, checking it for correctness before executing etc. Then we would need no more stinking template libraries!

I get your point, PHP cleans up after itself and is fast and that’s super-critical in web environments. I did an eval of a Java based enterprise-class system (many machines each with 32 Gig) with scalability issues because they had many scripts that had to run per scale-level (each script did something different). Java likes to pre-compile and load all its stuff and scripts into memory and keep it there. That’s just the nature of Java. I’m not dissing Java in general - I’d use it instead of PHP in other applications - but it was the wrong tool for the job for a complex, web-based, frequently changing, many many calculation-based, enterprise-level system. The final implementation? A Java-PHP hybrid succeeding where Java by itself failed. But I digress.

My complaint is your use of the term CGI model. CGI (common gateway interface) is just an API for how to call standalone programs. CGI processes can be called from a server running in threaded or worker mode. PHP can be called in CGI mode or via mod_php. A badly written non-PHP CGI script won’t clean up after itself. In one case I saw a badly written OS (not Linux), run on a badly written web server (not Apache), calling a badly written CGI script (not PHP) and it ran out of total memory causing the server to have to reboot.

Again I agree, a badly written PHP script will not those memory issues. PHP cleans up after itself,loads amazingly quickly (even faster with optimizers), etc, etc.; but calling it CGI-based grates against the actual definition of CGI and kills me. Instead of calling it CGI-based I think you should call it something else. I don’t have a good term “requestional-based?” “session-y-ness?” “session-envelope-based?” “web-transactional?”, “web-module-based?” :) ANYTHING but CGI.

While modwsgi is designed for commodity shared hosting in mind, it could be used for dedicated hosts just as well. Using modwsgi on shared hosting largely depends on if those admins choose to adapt using modwsgi in a similar way that has made modphp and php omnipresent. Furthermore, using modwsgi apps will still only be able to serve up so many simultaneous sessions on a one application one site model, thus if each site has it’s own process, it will be limited. I’ve tested my python app which has a complex templating module in both modwsgi daemon and embedded mode at around 30-40 simultaneous sessions before it noticeably starts to really grind really slow. (Perhaps I don’t have things configured correctly, by using threading?…) 100 sessions pretty much locked the app up until the sessions ended. I’m also on a VPS w/ 128mb of ram for testing. To scale well, I am imagining that there would need to be several apps used that interact with each other, and some interesting things could be possible with modwsgi daemon mode. Each app could take care of many different sites, and be able to spawn child process if it needs. One of those apps could be to write to disk previous requests, so as to be able to bypass all the other apps and serve directly a static file, this would enable huge performance gains for serving thousands of people those pages simultaneously. As for the user login side, each logged in user could have a duplicate site process dedicated to them. This could allow them to possibly make site wide changes with out ever committing them live, and see them as if they were live. When they are finished they can merge that data with the site data and make the updates, the static process could then recreate the changed pages. All in all, modwsgi, and or a webserver with an equivalent function of daemon management of python apps via wsgi, has lots of potential. One of the downsides is that Apache must be restarted frequently for changes in configuration, and updates to scripts, although I could be missing something… as I havn’t tried configuring such behavior yet and to dig into how modwsgi works. Perhaps something built with Erlang could provide a better webserver for this kind of thing, and allow for python to have an omnipresence among hosting, with lower level control of the system. Thus this would enable far greater complex functionality outside the framework’s language and framework’s design scope more efficiently. A framework thus isn’t it’s own world, but would provide more interfaces to interact with any software on the system. Python can be great for this.