* Jamie Fields wrote: > toward PHP. The one thing I really need to know is how many concurrent > users PHP can handle at one time.
That depends on your application. With intelligent caching on the user level (i.e. caching HTML output in the file system) there are some PHP applications who can handle 17 reqs/s easily. I'm sure there are also PHP applications who can handle more reqs/s. If that doesn't suit you, then you can deploy caching systems on the ZendEngine level, i.e. tools like PHP Accelerator (free), APC Cache (free) or the commercial ZendAccelerator. Finally, if this isn't enough, you should scale by hardware. Furthermore you should be aware of that tuning PHP is not the only thing you have to do. Most bottlenecks are the database you use (i.e. wrong table design, no indexes on relevant fields etc.) and finally you should drive into tuning your webserver. For MySQL you should try to use HEAP tables (tables that are completely in RAM) when having many SELECTs. If your website is delivering many static pictures (<img ...>), then you should make a subdomain images.foobar.com. Put a small webserver like thttpd on images.foobar.com and let it deliver those images. Don't use <img src="makemyimage.php?id=5"> because that creates one PHP request per <img> Tag inside your HTML code. Instead, try to cache your pictures in the filesystem (on the images.foobar.com server) and let it be <img src="http://images.foobar.com/cachedimage5.jpg">. Have your eyes on the whole thing (webserver, DB, html code, images, ...), not only on PHP when tuning. If you need further consulting tips, send a private e-mail. -- Sichere PHP Applikationen / Notfall-Consulting mit der PHP Feuerwehr / Code inspection / Code rehearsal / API Checkup. mailto:[EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]