Introduction to PHP5

Yet Another OO Fanatic writes "PHP core developer Sterling Hughes has a excellent presentation (mirror) about PHP5 online. So far it seems to be the best coverage of the new features in PHP5; highlights include the new object model, namespaces, interfaces, access control and exceptions. Java by any other name..."

Comments

And, if you want it right now...

[oGMo]

And, if you want it right now, instead of waiting for PHP5, go get Ruby today. It's got all of this, and many more neat features. I've recently been moving PHP over to Ruby, because PHP wouldn't scale to a large project (taking 4-5 seconds to load and generate a page on a hefty server, the codebase was only about a meg and a half of PHP), and because it was incessantly segfaulting for mysterious reasons. I've had no such problems since.

And ruby's a lot of fun... you can use it for tiny scripts, sites, or large projects.

Re:And, if you want it right now...

[oGMo]

Specifics are about the same. Little over 300 files total (only a small fraction of the complete system unfortunately), about 1.5 meg of code. This is not just a simple database interface, though. It's a complete persistant object system, widget framework, with object access controls, interface building, and the like. It makes development very fast, and lets me do things that would be very difficult with straight PHP (or anything else).

Unfortunately, when it came to building pages themselves, generating them from objects recursively was the final straw. The times really shot up, although they had been building for some time as the codesize and functionality increased.

With the new Ruby version, most of the processing, including building the pages, is moved to a backend server (written in Ruby), with a thin layer of CGI (in Ruby) that calls it. Loading the interpreter, parsing, calling the backend, processing, returning, and output is down to half a second on my old p2-350. And the capabilities are far beyond what the PHP version had (although, this was in part due to the fact it's a newer version, but some things PHP's object model would not have been able to handle, such as the integration of any given object, and adding syntax for class and method metadata).

We need good examples

[phorm]

Hopefully... PHP5 will either address some of the common mistakes (without becoming brainless) or at least have some good example out there.

If anyone has noticed... one of the major areas of death/slashdotting of sites apart from bandwidth are php URL's... and/or mySQL queries (often on PHP URL's). I've not yet noticed many Perl-run pages that have been slashdotted so successfully as PHP.

Now, I'm not sure if that's a faultof PHP itself, or that some of the "easier" features of PHP tend to attract less competent programmers and/or misconfigurations?

Re:We need good examples

[Arethan]

Slashdotting occurs mainly because 1 of 2 things happens. Either a) the pipe to the webserver is too small and the traffic overwhelms their connection; or b) the hardware falls behind in servicing the requests, and thus pages start failing.

Usually, it's b). Particularly, database queries being the main culprit. When people write database backended websites, they take 1 of two approaches. Make calls to the database every time a page is requested (most used), or they call the database for the first request, caching the result, and feed the cached copy to all other requests that occur within the cache's lifetime.

Method 1 is easier to do, but is flawed, in that you are placing all of the load on the database server. Once the requests start to pile up, it immediately becomes a bottleneck.

There was a nice write up about how some group put together a slashdot proof system, consisting of only modest Sun hardware. Their key was the use of java to run the website. Java allowed them to create system-wide objects that could be referenced by unrelated page requests. So they took method 2 in website design, and had a system that only made calls to the database when the cache didn't already hold a requested page.

PHP4 (and 3), unfortunately, do not allow for persistant system-wide objects. Not even lowly variables. So you can pretty much bet that any stock webserver using PHP will not handle a slashdot link on it's own. It would need a caching server to keep the requests to the database at a minimum. Hopefully, PHP5 will fix this little problem, as even ASP allows for system-wide objects.

So the short answer to your last question is: It is the fault of the programmer for choosing the wrong model, but PHP doesn't give them any other option, making their only alternative to use a different language.

Hope that helps. :)

Java? Hardly.

[Graelin]

Java by any other name...

Leave it to a Perl guy to compare PHP to Java.

features in PHP5; highlights include the new object model, namespaces, interfaces, access control and exceptions.

Of course, Perl has had all this for some time.

Just curious, how can you have an object model without namespaces? Or interfaces for that matter? Isn't that like "New Car - with tires!"??

Either way, PHP makes for a good interface language for web apps - I guess. You can throw it on top of an application layer to do the real work. Last I checked, you could only use SOAP to do this - has anyone tested how well that performs? SOAP doesn't scale all that well.

It would be nice to let the HTML monkeys handle some of this stuff while the serious development can take place in a real language. /me dawns the flamesuit.

Nice and stable

[Bob Bobbinson]

From the blog :

PHP5 isn't ready

This is what I get for running a server on pre-alpha software.

Ok, so as many of you already know, I have my talk for NYPHP online. This talk is hosted on NYPHP's servers, and is running Apache 1.3.27 + PHP5.

PHP5 leaks worse than the titantic. With MaxRequestsPerChild at 100, apache children grew to 37MB (before we stopped counting). At MaxRequestsPerChild at 40, it was around 27mb. Finally, we've settled on a reasonable default 25 requests per child. MaxClients at 50.

This is a box that can easily handle 20 times this load. ugh.

PHP5 is pre-alpha. Don't think otherwise.

Re:PHP Is *not* an application server

[bahwi]

Best reason not to move to Java: click.

Programmers determine coding practices, structure, etc. You can find obfuscated java code, obfuscated python, obfuscated perl, or obfuscated php. It all depends on the _programmer_, not the programming language. It's like blaming car accidents on the type of car a person drives.

Structured code is a good thing though, and so is efficiency.

Most PHP Projects are put on a shared server, so using shared memory will generally anger the host. For enterprise level, maybe for a simple simple form I'd go with PHP, everything else I would go with something more hardcore, and yes, even Java. Java is a good language, but it's bad to be trapped to a single company for your language.

Mod_Perl on Apache does shared memory, along with several other improvements. With strict coding practices in a company, and someone going over the code(should be done with _every_ language and _every_ project) the code is easy to read, easy to re-use, and easy to modify. Yes, even Perl. High level enough to do things quickly and easily, and powerful enough to do it very quickly, using shared memory, etc.. Don't underestimate the power of mod_perl, it's easy to get a dynamic database page with mod_perl to load faster than static content.

And with mod_perl, and good practices(again, necessary even in Java) it will scale easily to multiple servers, legacy systems, etc...

Of course, we're waiting on Parrot. Yeah, kinda Perl 6, but yeah, it will compile Java. And yeah, cross platform, unlike Java (Java on BSD is a PITA, _and_ reminds me of Win 3.1 on my 33mhz system back in the day).

So again, the problem is the programmer, not the language. Although you are correct that PHP is not an application server. But look at Parrot and look at Perl, things can grow into even better things.

Parrot also has a BF (Brain****) interpreter.

Re:Where is the unified database interfase ?

[Christianfreak]

It does of course it still sucks, its not near as powerful as Perl's DBI but its a start and its much better than stupid_function_names()

Re:PHP Is *not* an application server

[Synn]

The "a scripting isn't a REAL programming language" arguement is as tired as it is old.

I started with Java back when the only IDE out was Symantec's Cafe(not Visual Cafe) and frankly over the years I've found myself to be most productive using scripting languages like perl and php.

They get things done faster with less code needed to be written in a world where fewer lines of code typically translates into fewer bugs and more productivity per programmer. And I can code in any amount of structure into a project as I see fit.

Now if I worked in a huge corporation where any idiot could submit code into my project, then yes a language that forces your hand could very well be a good thing.

But in skilled hands things like strong typing and forced OO really only get in the way.

Scale

[Synn]

I'm not too sure what kind of system/traffic your site had, but our company runs web-based apps for over 40 insurance agencies across the US.

We have one server that hosts 42,000 lines of PHP code and sees around 1300 insurance agents each day who log in, generate term/ltc quotes and download forms.

Most of the above code drills into a seperate MSSQL database server running Win2k, which actually has become our only bottleneck. That server fails rarely during very high traffic.

Locally the web server also sports a MySQL database server instance which hosts a little under 5 megs worth of rates for Long Term Care quoting.

For Term Life quoting I pull in a 50-200k XML datastream from an outside vendor.

The server hosts 1.7gigs worth of downloadable insurance forms.

All of this runs on a 1Ghz Pentium 3 with a half gig of ram. A good 300 megs of that ram is currently free.

In the three years this has been running I've yet to see php cause a crash in apache.

I'd say it scales pretty damn well.