Slashdot Log In
PHP3/4 as Web Development Platform?
Posted by
Cliff
on Wed Sep 22, 1999 11:24 AM
from the using-the-right-tool dept.
from the using-the-right-tool dept.
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. "
This discussion has been archived.
No new comments can be posted.
PHP3/4 as Web Development Platform?
|
Log In/Create an Account
| Top
| 204 comments
(Spill at 50!) | Index Only
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Re:Silly argument (Score:3)
The note you quoted from Bruce was written in July. He says right there that we agreed to fix those issues back in July. Being September now, that has obviously been done. And they were just slight wording changes.
As for your CGI thing. You are being silly. You quoted a CERT advisory from 1996. Being September 1999, that has obviously been addressed as well.
-Rasmus
Re:CGI (Score:5)
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
Some PHP experience (Score:5)
We are currently using Solaris [sun.com] as a server platform, with Apache [apache.org] or phttpd [signum.se] as a webserver and we are using Oracle [oracle.com] and MySQL [mysql.com] as databases. We are running PHP [php.net] 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 [mailto] PHP3 mailing list, which are extremely friendly and efficient and usually generate correct and useful answers within 15 minutes. Also, the annotated online manual [php.net] 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 [mailto] mailing list or have a look at the PHP Knowledge base [e-gineer.com]. These are great ressources.
Counterpoints (Score:3)
JSPs are okay, but so is embedded Perl or VBasic.
Cocoon is very unwieldy right now, and probably not yet worth the effort unless you are a huge shop with lots of Java and XML devotees. The examples assume an Oracle backend. That should tell you something. (Yes, I've played with Cocoon as well. Cocoon 2 may inded be revolutionary...)
I have never heard of Midgard and I've been around for a while now. This indicates to me that it could be difficult to hire someone quickly and get them up to speed on it. OTOH, if it's just like PHP only better, I could be quite wrong.
Just my experiences and thoughts.
Personally, I don't mind servlets, mod_perl, OR mod_php. They're popular for different things, so for maximum code reuse (laziness) I choose whichever gets the job done fastest.
(Zope, incidentally, is quite cool and OO, and would be great for a new installation, but too much of a transition IMHO for a preexisting site)
PHP, Zope, and CF (Score:3)
I think PHP is great. Its fast, it works well and is very well featured. I think that it works best statically built into apache, and I have only used it with Linux and FreeBSD. I think you are best off to wait on PHP4. Just start with 3, and then migrate as needed. I don't forsee too much incompatibility between the two, and as someone who gets way to many "Its broke" phone calls, I can't imagine delivering a beta backend for an important app.
As for Zope, it looked to me to be a simpler language than PHP, although powerful. I think it is good for dynamic web pages, but big web apps (such as the sort I create) are out of its scope.
I think that sticking with NT and CF is a poor choice. My firm almost always either hosts the web app for the client (we have one client that is a conglomerate of 300 companies nationwide) or delivering an inexpensive unix (linux, freebsd) dedicated server. I think that web apps are so easy to decompile, or just yank the source, that clients think they can edit it, and you have to fix it. I prefer to lock them out unless I truly feel they know how to code at all. I think NT is a terrible OS and that you need to get away from that, fast.
But, I suppose I am a bit of a zealot. grin....
My take on Zope (Score:5)
- 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
CGI (Score:3)
I would seriously recommend using the mod_php3 modules under Apache due to performance and security. If you run PHP as a CGI script, you can do nasty-evil things like read the .htaccess files under apache. There is also no "safe mode" for the CGI module (I haven't verified this, however).. which means one coding slip-up and you hand the remote user all the priveledges the webserver has on the system (which given that you'd be running NT, is probably full access). Even with safe mode, you will still have some additional security concerns that the apache module doesn't have. :(
The other problem with PHP4 is the licensing - it is not open source. Bruce Perens and the OSI have been working on it for awhile now (a long while ago *muttering*) but it isn't fixed yet. Go over the license and see if you can live with it.. otherwise stick with PHP3 (which meets the OSD).
The single compelling reason to use PHP over third-party or Microsoft offerings is the database support. You should know that PHP4 brings ODBC driver support (via iodbc under linux, YMMV under NT) so that you can access alot more RDBMS systems than before. This is a definate consideration when looking at the client's needs. I will again reiterate that NT isn't the best platform for serving dynamic content from.. and would urge you to consider using a unix-based solution.. it's more scaleable, easier to maintain, and more reliable than it's NT counter-parts.
--
Go three-tier (Score:4)
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.
Re:asp2php (Score:3)
Although some people will probably not like his (definitely not open source) licensing for ASP2PHP, he did release the source a while back, so it may be possible for you to fix the problems you encountered. Getting him to accept the changes back may be somewhat more problematic, as he is a bit picky about how he will take things (he doesn't like diffs). Also the code isn't commented as well as I'd like to see for other people to work with it (something the author did not dispute, as he hadn't intended originally to release the source).
He also offered to look at ASP code that wasn't converting properly, so if you are willing to send him examples, he may be able to enhance the product so it would work better for you.
Go for Zope 2.x! (Score:3)
Zope, on the other hand, is very impressive!
Object Oriented, tight, finegrained security model, very dynamic, runs on several platforms, Python, connects nicely to databases.... OpenSource!!!
Zope has an extremely high Feel Good Factor(tm) (a Jamiroquai term); in fact, it's very addictive!
Once in a while you come by a ware and this strange, warm feeling fills you up... these people have created a product with a lot of brains in it and behind it... everything is good!
Zope is of this kind.
Btw. you can get nice commercial support from the creators at http://www.digicool.com/
Best regards,
Steen Suder
Re:Wait for PHP4. (Score:3)
Yes, it does take a while to figure out how PHPLIB works, but once you've figured it out you'll be hooked. I highly recommend it.
As far as Cold Fusion goes, I wouldn't recommend the Solaris version. We developed one of our sites in CFML and we had nothing but problems with the CF server. Hopefully the Linux version will be more stable.
-Philip
http://www.buymp3.com/ [buymp3.com]
Perl is too easy (Score:3)
On the other hand, many of the mod_perl applications I've looked at have been sophisticated and clean. They've actually been designed and structured. They're a pleasure to read and to maintain. And they're written in the same language as those CGI scripts from hell that the script kiddies mutilate. Yet it seems like it's galaxies far removed.
Interesting, eh?
I believe this is saying more about the average CGI script kiddie versus Apache mod_perl hacker than it is saying about Perl. But yes, it's easy to write bad perl code. I guess it's easy to write bad C++ code too, but the barrier to entry is higher.
I don't know that there's ever been a language written in which it's been the least bit hard to write bad code. If you outlaw bad code, only outlaws will code badly. :-)
Re:PHP, Zope, and CF (Score:3)
Certainly not. First of all, Zope isn't a language -- Zope's DTML language is just a small component in a large system. You don't even need to use DTML in order to reap Zope's benefits.
Secondly, Zope's strength is its open-ended, object-oriented nature. Comparing Zope to PHP is largely meaningless. PHP is a preprocessor; Zope is a middleware platform. Zope has been specifically tailored for enormous, complex, high-volume web systems.
With the recent introduction of the Zope Enterprise Objects [digicool.com] (ZEO), which will let you set up multiple object database servers that may mirror their data through replication, Zope grows to even higher planes of scalability and capacity. Combine ZEO with round-robin DNS and you have a good load-balanced failover solution.
A little research into what Zope really is might have helped. You're just spreading disinformation.
Unmentioned options (Score:3)
(1) Midgard (www.midgard-project.org). It layers on top of PHP, adding functionality, remote administration, more code generation, etc. They plan to do an NT version soon (might be more a matter of just compiling it than doing any coding).
(2) Java Server Pages. They let you embed code into pages the way you do with PHP, ASP, and the rest. But since they're Java, you don't need to learn a new syntax, and you're guaranteed to be able to do anything (remember: Java can also use Perl and C/C++ modules, so anything is fair game). And apache.org supplies a free engine for it. I use JSP's regularly, and they're great.
(3) Servlets. Yes, they're useful and powerful, and standard syntax.
(4) Cocoon (ava.apache.org/cocoon/). It's a project using COM, XML, and XSL, and will probably be the most powerful framework around (but I want to wait to see anybody use it before I try; it's difficult to be first, since there's nobody to ask how to do it!).
Use PHP4!! (Score:3)
I use PHP very seriously. I also use a Linux platform, and would strongly recommend that.
PHP3 has some big problems. 1) effeciency is not very good, especially noticeable on a large website. As I understand it, PHP3 has no capacity to cache the result of parsing code. Thus everytime a function is called or a file included, the parser must re-check the code. 2) OOP sucks! Reference support is extremely bad. Be prepared to undergo major hacks to get OOP working with PHP3.
I have used PHP4 beta 2 for over a month now with no glitches. It is a wonderful thing. OOP actually works great! And the parsing engine caches results (similar to Perl). Also lots of other handy stuff has been added... including output buffering (enables you to send HTTP headers even after HTML output) and a bunch of other functions that you will see in the PHP3 manual that look great and have a footnote saying "added to PHP version 4".
As I understand the licencing for PHP4, PHP4 itself is open source and free. Something called "Zend" is the parsing engine for PHP4, which you must pay for if you intend to take the Zend code and use it within a commercial application.
There is something called PHPLIB available for PHP3 which takes care of a lot of web authentication, page rendering, etc with some high-level object code. I looked at PHPLIB and decided not to use it because use PHP4, and I prefer to know every little detail of how my code behaves. However, PHPLIB gives a good structure for how a complex PHP-driven website can be built, so it is a good starting point for anyone.
Zope, PHP, Jserv, Roxen (Score:3)
ZOPE: Very nice development interface, easy to add functionality using python, XML support, good cross-platform ability. The object-based development platform takes a little getting used to, but is extremely powerful and convenient.
See An Introduction to Zope [devshed.com] for a very good overview.
PHP: Can do just about anything. Great database support. We've had no performance problems due to php at all. Run it as an apache module, of course. I have not used it much on Windows, but PHP4 promises to have excellent Windows support.
We have a number of articles, tutorials and docs about PHP at DevShed [devshed.com].
APACHE JSERV: Efficient, powerful, mature. Apache talks to "Servlets" that do most of the work. The servlets stay in memory, no new processes are forked. Multiple servlets may be used, I believe across multiple servers if necessary. Session management is included. It's all Java. Apache Jakarta will also include Java Server Pages (JSP), a strong competitor to PHP and ASP.
ROXEN: Similar to PHP, written in Pike, a C-like object oriented language. Easy separation of layout and content, easy database integration, very efficient. This one includes its own multipurpose server (web/proxy/ssl/ftp).
See Introduction to Roxen by Kai Voigt [devshed.com] for more information.
We're still sticking with PHP for now, but looking most seriously at Jserv for the future.
Our #1 qualifier:
OPEN SOURCE - all of the above solutions are!
Reason for switching? (Score:5)
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.
-=-=-=-=-