* 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]
