Forum Moderators: coopster
1. IIS with CGI module (is extremely slow when there many visitors & CPU goes 100%)
2. IIS with ISAPI module..(i've been reading people's review on internet about this causing them alot of crash. Don't know if it true)
3. Red Hat Linux with apache module.
btw, how does linux works with php? I never tried linux yet. does it use a threadsafety like ISAPI?
The ISAPI module for PHP/IIS I beleive is not 100% tested.
CGI is slow on both Windows/IIS and Linux/Apache avoid it if you can.
PHP is most stable with 1.3.x of Apache on Linux/Unix. No wories about thread safety as apache 1.3.x is not a threading program it is a forking program.
Apache 2.x is threading and PHP has threaded support for it but the PHP team does not yet recommened it for production use.
Your best bet for PHP is to run it on Linux/Unix with Apache 1.3. That is the most stable, reliable and fastest configuration at this point.
Though I'm not an expert on Windows it is somewhat common knowlege that on the same hardware a Linux/Apache/PHP configuration will give you more performance than Windows/IIS/[ASP,PHP].
daisho.
I'm looking for which is good that many visitors are requesting the same pages at the same time. ISAPI works fine for windows, but i don't know much about Linux Apache 1.3x and 2.x. can you tell me more about it?
A fork takes longer to initiate than a thread but once created it is basically it's own program with it's own memory space. Interfork communication can get a little tricky.
Anyway that's not to important.
dvduval as for your comments of PHP on Windows being faster you don't have a fair comparison. The 2 different servers are quite certainly different and the traffic on the servers are different. It's comparing Apples to Oranges.
daisho.
In general, given the same hardware and same applications Linux/Unix will be faster and can handle more concurrent connections than windows. If you just want to run a web server with PHP, go the Linux/Apache 1.3/PHP route. Also, be sure to get a PHP accelerator as well. There are a number out there some free, some must be purchased, but all do improve speed and performance of serving PHP pages.
Scott Geiger
is it reliable?
[edited by: jatar_k at 4:52 pm (utc) on May 23, 2003]
[edit reason] no urls thanks [/edit]
Scott
A fork takes longer to initiate than a thread but once created it is basically it's own program with it's own memory space. Interfork communication can get a little tricky.
Forking creates a new process with it's own task structure, stack, heap, copy of the executable code, place in the kernel's execution schedule, and so-forth. It isn't "basically" a new program, it *is* a new program. Cooperating processes created by forking can communicate through assorted inter-process communication methods, such as shared memory regions, semaphores, etc. Exactly which mechanisms are available depends on the OS. Separate processes are fairly well protected from eachothers' actions.
Threads exist within the same process, and share everything except and execution pointer. Since they share most or all of their memory space with eachother, they aren't nearly as protected from eachothers' misbehavior as separate processes. In return, they get to communicate more easily - it's two sides of the same coin.
Typically, Unix programs have made use of a forking model. As a result, lots of effort has gone into optimizing the process creation process on Unix systems, and they are quite "cheap" compared to Windows process creation. This is deffinitely true of Linux process creation. On the other hand, threads are relatively newer to the Unix scene, and fewer programs can make use of them. Windows programs, on the other hand, tend to use threads rather than forking cooperative processes. This is one reason why Apache hasn't always done very well on NT servers - Apache doesn't use threads in versions prior to 2.
See? I did get something out of that $100k education.
daisho.
Forking is basically a very inefficient mechanism and the "cost" involved in creating and destroying them is quite high (relatively). Threading on the other hand should be a far more efficient, and whilst dingman is right about the cost of a Windows process creation the parent/child analogy is better suited to this threading model.
Finally... NetWare has without a doubt the most efficient threading model of all OSes (see said I would). I haven't seen any PHP benchmarks on NetWare, but a NetWare kernal thread is fundimentally different to all other models. A NetWare thread is fundimentally seperate from it's execution context (memory, stack, pointers etc) and a NetWare thread can swap in swap out executing contexts dynamically. Therefore a thread rarely crashes it's executing context does. And it is then free to bind itself to another context, and begin executing that. Also processor context switches are extremely fast on NetWare, a key reason a single processor NetWare server could out perform a quad processor NT/Linux box on things like Perl etc.
asp sits back satisfied and waits for flames....
waits for flames...
being the well mannered and friendly types that we are it won't happen. ;)
being the well mannered and friendly types that we are it won't happen.
Jolly good I can take my helmet off then ;)
Having been involved in some web server kernal side development - this page is one of the finest I've come across in discussing the scalability issues: www.kegel.com/c10k.html
asp
[edited by: jatar_k at 10:42 pm (utc) on May 23, 2003]
[edit reason] delinked [/edit]
I turn PHP off (comment out the load line in conf file) when it is not absolutly necc for me local now.
dingman that is *basically* what I said :)
Um, yes. I just strengthened the assertion, and fleshed it out for anyone interested. I wanted to do more detail on threads, too, but there are so many diferent approaches to what they are, still, that I don't feel like I have a solid enough grasp to be that specific. I don't even know one of them well enough to confidently employ threads in any code I write.
Brett - it's been a long time since I tried running Apache on win32, and I'm sure it's improved since then, but I can't say what you describe suprises me. I love Apache and PHP, and I've never had a problem on the Linux and BSD machines I've had under my care, but I have significantly less confidence in the Windows ports of those programs than the *nix ones.
Does the combination of Apache and NT/2k/XP work any better than 98?
Let me just add that I run Apache and PHP under 98. I have had nothing but problem after problem with PHP.
Really? I have the same set up but I haven't had any of the problems you've mentioned. It is slow but that's my computer :-)
I'm running 1.3 and I always have to kill the task manually to shut it down if anything php has been called.
CPU P3 1GHz
256K Cache
18 GB IDE (yes I know SCSI is faster, had to go with cheaper)
512 MB RAM
1 GB Swap
RH Linux 7.2
Apache 1.3.x w/ PHP 4.3.x and OpenSSL
Also running on the same server:
MySQL 4.x
Qmail POP/SMTP services
Total requests for Tuesday, May 27, 2003 =~ 900,000 across 10 different sites. One site had over 430,000 requests alone. That works out to a bit over 10 requests per second on average. Now obviously there are times when there are more and times when there are less. The default configuartion of Apache is set to handle 150 concurrent connections. You can increase it to 255 through the configuration. If you want to go higher than that you need to edit the source. However, if you go high and don't have the resources to handle it, your server will crash (learned from experience).
With regard to Novell - I have to agree, Novell Netware is a superior OS, it's more stable than any other, is probably more secure than Windows and *nix. The problem is that Novell doesn't/didn't know how to market. They missed the boat a long time ago when they continued to press forward with IPX/SPX (which is a better packet transport than TCP/IP - but that's a whole other discussion). The rest of the world was going TCP/IP and Novell was still stuck on IPX/SPX. If they had either marketed IPX better or had been able to switch to IP faster they would have been at least where Linux is today if not further ahead. Just my $0.02
Scott
18 GB IDE (yes I know SCSI is faster, had to go with cheaper)
Probably not a bid deal on a server. After all, no matter how fast you get it off the disk, the data still has to go through the ethernet card and across the internet. The hard drive is highly unlikely to be the bottleneck. I've more often heard reliability cited as a reason to use SCSI, but there is less of a difference in reliability between SCSI and IDE drives than there used to be.
daisho.
