Slashdot Mirror

← Back to Stories (view on slashdot.org)

Introduction to PHP5

Posted by michael on from the getting-hacked-with-phpnuke-now-50%-easier dept.

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..."

6 of 338 comments (clear)

  1. And, if you want it right now... by oGMo · · Score: 4, Interesting

    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.

    --

    Don't think of it as a flame---it's more like an argument that does 3d6 fire damage

    1. Re:And, if you want it right now... by oGMo · · Score: 4, Interesting

      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).

      --

      Don't think of it as a flame---it's more like an argument that does 3d6 fire damage

  2. Nice and stable by Bob+Bobbinson · · Score: 5, Interesting

    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.

  3. Re:We need good examples by Arethan · · Score: 4, Interesting

    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. :)

  4. Re:PHP Is *not* an application server by Synn · · Score: 4, Interesting

    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.

  5. Scale by Synn · · Score: 4, Interesting

    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.