Subject: RE: More Linux - general > > i can point you to PHP gurus if you need them, though. > > It would be good for me to gather more info about that option > now. I wasn't aware that PHP had taken the step to work as a > server module. Last time I used it I don't think it worked that > way (1996). If you have any good links handy, send em my way, > plz, otherwise I'll just see what the SE's bring me. one of the guys on my team wrote the book (literally.. on advance from the publisher and everything) on hooking PHP into Apache. his name is Charles Fisher, and with a little digging you can probably find some of the articles he's done online. i'll let him know you're looking for resources and pass along whatever he sends back. > > specifically why do you need database caching and precompilation > > of templates? obviously, they're both related to performance > > speed, but what's their value in absolute terms? > > How do I define the absolute terms? For the database caching, CF > keeps connections to the database open so many users can share > the same connection. I think they call it connection pooling, > but I'm not sure. End result, better performance and less > overhead. As far as precompilation of templates, I don't know > what the absolute benefit is, other than the claimed performance > gain, which comes as a combination of not having to keep parsing > the same templates and not having to do as much file IO. that's about what i expected.. my asking of the question was Socratic (aka: being a provoking jerk). ;-) the point to carry away from the whole deal is that the features pay for themselves with performance. the difference is that performance is the realm of measurement, and features are the realm of marketing. i've seen one too many pieces of electronic gear with a "mode standby indicator" (otherwise known as an LED that tells you the machine is turned *off*, of all things) to believe that any meaningful information can be extracted from user documentation. > > would an > > Apache/PHP server that can deliver the same number of pages in > > the same amount of time at equal or lower processing load be > > adequate? > > "Is that the case", is the question. Where do I get the answers? the more pertinent question is, "does solution X have the power to handle what i want to do?" close on its heels would be "if i go with solution X and it doesn't pan out, am i SOL?" my personal opinion is that unix/Apache gives you better odds in both areas than NT/IIS. it's also less expensive to test/reject unix and move to NT than it is to go the other direction. when it comes to server performance, the only rule which applies across the board is "your mileage may vary". benchmarks and reviews are nice, but unless you duplicate everything in the test conditions faithfully, you may see widely different results. if you want hard numbers about what will work with your hardware and load profile, you need to build and run your own tests. the good news is that the hard numbers are almost completely irrelevant unless they show a truly massive difference between two alternatives. benchmarks are strictly a "let's try it and see what happens" tool. they're great as a diagnostic for maintenance purposes, but that's about it. the ability to predict future performance in a new environment based on previous benchmarks has an accuracy rating somewhere between flipping a coin and reading tea leaves. in broad terms, almost any hardware/OS/software configuration you're likely to find these days will be adequate for low to high-moderate loads. the technology is so ridiculously overpowered these days relative to bandwidth that it's hard to screw up a machine badly enough that it won't provide adequate minimal performance. this is a religious issue for me, actually. i know enough about server performance that i start getting vehement when i hear most people talking about it. the simple fact of the matter is that in a webserver, the motherboard is a fancy interface between the network card and the hard drive. operating strictly on processing power, a 25MHz 386 can choke a T1. today's low-end consumer PC has roughly the same crunching power as the first Cray supercomputer, so forget the digital side of the eqation. there's so much overkill that any more is meaningless. the primary bottleneck in server performance is drive latency. it doesn't matter how many megahertz you have on the board when your drive seek time is measured in microseconds. it also doesn't matter how many simultaneous server threads you can run if they all have to stand in line waiting for the drive. if you want to kick the performance of a webserver through the roof, make sure your files stay in RAM. it cuts out about 99.999% of the access overhead. the best solution is to put everything in a RAMdisk, but that's not always feasible. the next best option is to increase the size and block size of your file buffers. with a little tuning, you can get one or two orders of magnitude improvement just with that. bottom line, a webserver with more than one CPU is like a fish with a pair of Air Jordans. if you're going to buy anything, buy RAM and know how to use it. at the drive level itself, if you're using anything less than SCSI2, you shouldn't be talking about performance. granted a well-tuned IDE/EDO system can prod some serious buttock, but that's not off-the-shelf technology these days. for really phenomenal load levels, or seriously large numbers of files which all see roughly equal demand, you can make good use of a redundant RAID stack. if you're not working under those conditions, though, you can probably save the money. when it comes to the OS, the big question is, "how much redundant, unnecessary crap does it carry, and how much of it can you turn off?" short of the ability to tune things like the filesystem block size and file buffers, the next largest waste of server performance is the latency due to unwanted processes chewing up CPU time. that's one of the areas where NT scores worst, in my book. aside from the fact that there's no capacity to tune the low-level system parameters, there's a bunch of gunk in the middleware that can't be eliminated. the OS is welded shut, so if Microsoft wants it to support a wide range of different uses, they have to build in hooks for all of them. for any given use, the OS is maintaining a load of unnecessary services that are pure waste. that overhead is the price of flexibility, but the price is unnecessary if you have a well-defined purpose for the machine. obviously, unix is at the opposite end of the scale. you can decide exactly what should and should not be included in the kernel, and define system parameters as you choose. you have complete control over the boot process, so once you know what you're doing, it's easy to create a system with exactly the capacities and services you want.