Re: [HELP! searching performance info]

Your problems will probably not be because of PHP. PHP is as "scalable" as Apache if you're running PHP as an Apache module because PHP becomes part of Apache. If you're running PHP as a CGI application, it becomes as scalable as the OS and Apache combined because that's the platform you're using when running it that way. Any performance problems you encounter will be related to application design, the quality of the code that implements the application, and/or inadequate capacity planning. I wouldn't advocate a Microsoft solution for almost anything anymore, but I suspect that a Microsoft platform could handle your app with a little bit more work. After finding the problems with your app as it was implemented in ASP, you could have taken the next step and wrote particularly time-intensive portions as OCXs (or whatever they're calling them this month) and registering it with MTS on every server in the farm. I'd recommend the exact same thing with PHP! If you find something that PHP isn't doing as fast as you need or like, code the algorithms up in C and call them with PHP. No matter what platform you choose, though, you'll have to throw a bit of hardware at this project. A hundred thousand people hitting a site at an average (I pulled this out of my hat because only you and your users can really estimate this) of 25 page hits per hour is 2.5M page hits per hour or 41,667 page hits per minute or 694 page hits per second. Let's say that an average page has about 4 graphics, you'll be hitting the web server an average of 3,470 ((1 HTML + 4 graphics) * 694 = 3,470) requests per second. If you triple this (because you're in a real-world situation and not a benchmarking situation and because you're not serving up static pages), you'll find that you need more power than a single box can provide (even a quad Xeon, which seems to be a favorite "high-end" server to benchmark on). It looks like linux can handle somewhere between 1,000 and 2,000 requests per second in most of the benchmarks on http://www.kegel.com/nt-linux-benchmarks.html. So let's just say it can deal with 1,000. We've already included a fudge-factor for scripted content and real-world file sizes when tripling the 3,470 requests per second, so we figure that we need enough servers to handle 10,410 requests per second. That's eleven servers we'd require to handle the load. If it were my project, I'd probably start with a cluster of four to six servers (optimized all to heck and back!) and I'd be prepared to double the number of servers. You're in a much better position to calculate the capacity requirements a lot better than I can, though. There are many things to consider. For example, if your users do not all work the same 5 hours per day, the load is distributed throughout the day and you will need nowhere near this number of servers! The backend database is a whole different ballgame. I don't even know where to go for even rudimentary performance benchmarks. Even the site mentioned above doesn't have much info on database benchmarks. So I cannot begin to calculate what you'd need for it. HTH (even a little), Doug At 04:45 PM 7/10/00 +0200, Paco Ortiz wrote: ... snip ... >we are talking about 20000 to 100000 authentified (non-anonymous) people >accessing a Web on a regular basis (they MUST work there for at least 5 >hours a day, so imagine ~10e7 hits a day). The web has a customized >behaviour for every user (typical notebook, agenda, custom static contents, >access to resources...). > >(*boss leaves smiling*) >(*sysadmin evacuated to the nearest hospital*) > >It's about 300 complex scripts + 10-100 GB of static contents >(files,HTML,images). We also estimate a 10-100 GB database. ... snip ...