Slashdot Mirror
PHP3/4 as Web Development Platform?
Erestar asks: "I work for a small network integration company that also handles a good bit of web application design and hosting. Right now we're running 2 clustered NT servers along with Cold Fusion. Since my introduction to PHP3 I have been strongly pushing to run it in conjunction with IIS while still keeping the Cold Fusion server active. What I need are any comments or suggestions as to the validity of my cause. Will PHP3, running as a module for IIS, seamlessly fail over? Has anyone encountered any problems when running PHP3 and Cold Fusion Server at the same time? How limited is PHP3 as far as script size is concerned? Another issue that has arisen is the practicality of doing this. Are there any benefits to running PHP3 that Cold Fusion cannot provide (aside from "its just so damn cool")? Would I be better off committing myself to writing custom CF tags and COM objects with VB or C++? Would I be better off waiting to for a new release of PHP4?" Erestar goes on to describe his applications. Click below for more.
"We work with practically anyone; our clients range from Used Car dealerships to billion dollar banking firms. Nearly all of the sites are database driven, most with ODBC to Access databases (we're planning on turning MS SQL Server on any day now, though). We're also developing a tracking application that will manage most of our business requests and anything else we can toss in. It is this application that I would like to code with PHP3. Any information that you could supply would be greatly appreciated. "
You are misinformed here. PHP 4 is very much Open Source and it has been run by Bruce Perens. The Zend component is under the QPL which has been deemed to be Open Source compliant and the rest of PHP is under an Apache/BSD style license.
.htaccess files anyway.
And your cgi concerns aren't too well-founded. The thing you can do with the cgi version, at least under Unix, is to run it as your own user id through suExec which is quite safe. Under NT, who knows, but then I don't think IIS has
Also, ODBC support is not new to PHP 4. It was in PHP 3 as well and it hasn't changed much.
And finally, PHP 4 has an ISAPI version coming so from a performance perspective it should be quite competitive, and most likely quicker than CF on NT.
-Rasmus
We are currently using Solaris as a server platform, with Apache or phttpd as a webserver and we are using Oracle and MySQL as databases. We are running PHP as scriping engine as CGI version and as Apache module in some instances.
You seem to come from a mostly Microsoft background, which is not where PHP is at home. PHP3 does not run as an IIS module, as far as I know, but only as a CGI version. This will make it perform much worse that for example CF or ASP on IIS, due to the abysmal performance of the NT platform and IIS as a CGI host - NT just doesn't fork. PHP4 will be running as an IIS module, but is in beta now and I would not build any production code on it - yet. As soon as PHP4 proves to be stable under load, it should outperform PHP3 by a factor of 5-10, though, plus the speed gain coming from being able to use it as a module on IIS.
On a Unix system (Linux, Solaris, doesn't matter) with Apache, PHP3 performs excellently as a module and can take any reasonable amount of load, provided you have enough RAM. We already know this from the Mindcraft benchmark - Apache must not swap and you must tune your MaxClients to match your RAM size to avoid performance degradation under high load. Many sites are parsing all pages, including their regular HTML, through PHP3 for convenience and the performance overhead is neglegible - if Apache can take it, Apache and mod_php can usually take it as well.
PHP excels in portability, support and in connectivity when benchmarked against CF. PHP will run on any old server platform and will talk to almost anything, and natively, where CF will most probably talk through an ODBC adapter. PHP includes some 10+ native database interfaces, including all major database vendors, and does LDAP, SNMP, SMTP, NNTP, IMAP4, POP3, some OODB and fulltext database protocols, can generate pictures on the fly, can generate PDF on the fly and so on. Writing extensions for PHP is trivial, if you can do reasonable PHP programming.
One point must not be left out of the equation when talking about PHP, and that is the online support. There are many large PHP mailing lists, including THE PHP3 mailing list, which are extremely friendly and efficient and usually generate correct and useful answers within 15 minutes. Also, the annotated online manual is a unique ressource for help, because it is learning and growing, incorporating user annotations. I have nowhere experienced anything that comes close to this kind in support, commerical or not.
My recommendation: PHP on IIS on Windows works, but will most likely not perform as exspected. It is nice for testing, but I won't go productive in this configuration. PHP on Apache on Windows works better, but will still not use PHP to it's fullest advantage. Also, you will make installation and maintentance unnecessarily difficult for you. PHP on Apache on any Unix will perform extremely satisfactorily, generate only minimal TCO, and is supported excellently. If you have at least minimal Unix knowhow inhouse, I suggest that you go for the full plunge in a test installation instead of an incremental migratory approach, because this way you will maximize the advantages of PHP and your server platform.
Re the migration from version 3 to version 4: PHP4 and PHP3 are drop-in compatible. There is no need to "port" from 3 to 4, because both languages are virtually identical. The differences are extremely minimal and well documented, also the development team is working on closing these final gaps between versions. Changes between version 3 and 4 are completly internal, switching from a fully interpreted system to a byte-code compiler/interpreter hybrid for speed reasons. Also, some language features have been added in an upward compatible and transparent way. We have tested the beta and found it to be living up to its promises in speed _and_ compatibility. Waiting for PHP4 won't pay: You can use PHP3 to learn just now and all this knowledge as well as your code will be valid and valueable on PHP4.
If you'll be using the CGI version of PHP3, please be sure that you
If you have any further questions, please subscribe to the php3@lists.php.net mailing list or have a look at the PHP Knowledge base. These are great ressources.
- PHP-like language (called DTML), with new experimental XML-compliant form of DTML as well which can be handled by XML editors.
- Managed via your web browser, there is no need to have a shell account to maintain a web site, and no need to be in the
/etc/passwd file. - Access control including user-defined roles.
- User information, roles, and permissions can be local to a sub-tree of a larger site, and can override what is defined higher in the tree.
- Object persistence.
- Content management with session control. You can join a session to test new content without having that content appear to anyone who has not joined that session. Commit or discard the session when you are done.
- WebDAV (drag-and-drop management of web sites) works today. Too bad the only WebDAV client you can get is IE5, but that'll change - it's an open standard.
- FTP access to your web site and its dynamic methods.
- Database integration with built-in query system and sophisticated search interface.
- No need for CGI. Export methods of classes via the web. Persistent program rather than CGI which restarts an executable with every call.
- Transaction processing transparent to the programmer. If an uncaught error is posted during a transaction, the entire transaction is backed out of the database cleanly. Data is never left in an inconsistent state. There is also a programatic interface to transactions, but you don't generally have to use it.
- It's pretty fast and low-overhead, too. My Pentium III 450 running Linux and Zope has survived being slashdotted many times. Sure, my Pentium 120 does that using just Apache, for static files. My Zope site, on the other hand, is very dynamic.
- Web-based definition of classes, or you can use python.
- Call from Apache, or run it as its own web server. If your site is entirely Zope, you can turn off Apache and save the overhead.
- Multi-threaded.
- Written in Python, with a tiny bit of C.
It takes a few days to learn everything that's in there, there's so much. I suggest you go over to zope.org and get started.Thanks
Bruce
Bruce Perens.
PHP's nifty, but the trend is away from loading business logic and presentation logic onto the same layer, as PHP and Cold Fusion both generally do. Cold Fusion has been moving toward a 3-tier approach with the addition of a separate app server, but it's not really there yet in terms of being able to run on separate hardware and having intelligent failover at the middle tier.
This is where in the NT world the typical scenario of hosting COM objects on something like MTS comes in, and ASP or Cold Fusion in front of it.I've heard it doesn't work thrillingly well in some cases, especially when you're trying to host Java COM objects, but the approach is right and there are ways to make this work well.
The usual platform-independent approach is to use a CORBA (for C++ or Java) or EJB (Java) app server, or at least plain old Java Servlets, which does essentially the same thing, typically with JSP for the presentation scripting layer. One nice thing about JSP is that they compile to Java bytecode and run very fast indeed.
Yes, you can run ASPs on a number of Unixes, Cold Fusion on Solaris (and gosh, don't they have a Java implementation of their server piece now?). And a number of Unix-family OSes can also host and/or access COM objects, though they won't magically have access to Win32 APIs.
And yes, the JSP/Servlet/EJB/CORBA approaches work very well indeed on NT as well as Unixes, with most of the higher-end app server vendors all abandoning their proprietary technologies and standardizing on this set of technologies these days.. See Broadvision, BEA Weblogic, ATG, Sun NetDynamics, Netscape Appserver, and IBM WebSphere for just some examples of the vendors doing this. It's mighty compelling.
On the low-end, getting started with the JSP/servlet combo can be very inexpensive and very stable indeed on any OS. There are free servlet engines (which you can use to connect to CORBA and COM objects without much fuss) for all the popular webservers, free JSP environments that can sit on the servlet engines, and many choices for getting into EJB and CORBA, from free (albeit sometimes not ready for wide use) to commercial (industrial strength). The great part about this is that you end up with code at each layer that runs fast and is extremely portable to and between the most scalable and bulletproof app servers around.
As for commercial RAD tools, you may want to look into a new version of Drumbeat that generates JSP instead of ASP. And most modern Java IDEs make for great EJB and servlet development environments.
Can't speak for the forthcoming PHP4. It may come closer to this sort of thing.
One thing to say in PHP3's favor is that some pretty large and high-volume sites do use it, though the heavy-traffic ones probably have the nastier logic on a middl tier or as stored procedures in the database.
If you wanted to switch, I would highly recommend switching over full-scale and rebuild those NT boxes as Linux boxes, use Apache and PHP or mod_perl or what have you.
You might also look into doing servlet programming with Java. JDBC offers an excellent interface to databases and the advantage of going Java is that, at least with JDK 1.1, you really can move your code from the NT box to a Linux box when NT buckles under the load, and from there to a huge 64-processor Solaris box when the Linux box can't take it any more and it will all work essentially unchanged. (Write-once-run-anywhere works for the most part as long as you stick with straight JDK1.1 stuff and don't use too many third-party add-ins, or at least stick to add-on libraries that are 100% java.) IBM's JDK for Linux is quite high-performance and remarkably stable for what they call an "Alpha" version. (You can find it at www.alphaworks.ibm.com)
A warning about Java servlet programming -- Java is a highly structured language and if you're into the kind of "quick kluge" that languages like Perl seem to be designed to handle, or the "quick one-off" that PHP excels at, you're going to have some problems moving to Java servlets which requires a lot more thought and "engineering" to get a good design. The advantage is, at least in my experience, going the Java route winds up with much more maintainable and extensible codebase.
This is not intended as a poke at PHP or Perl, just that those two languages are really designed to do stuff "quick-and-dirty" and therefore are very easy to write nasty code -- lots easier than it is with Java. (although you can still write nasty code in Java.) I'm speaking from experience as I've written nasty code in PHP and had to try to clean it up into some sort of maintainable form without a lot of luck once the codebase gets to a certain size, and I've had to deal with nasty CGI Perl code written by other people that I was barely able to read, much less figure out how to change without breaking the whole thing.
-=-=-=-=-
-=-=-=-=-
My mom's going to kick you in the face!