Tommy Pham wrote:

The response time, max 5 seconds, will be tested on local gigabit LAN
to ensure the adequate response (optimized DB & code & proper
hardware) without worrying about users' connection limit and site's
upload bandwidth limit (which can easily rectify).  Then thereafter
will be doing stress test of about 10 concurrent users.  As for the
major queries, that's where threads come in, IMO, because those
queries depend on 1 primary parameter (category ID) and 1 secondary
parameter (language ID).  This particular site starts with 500
products about 15 categories, without many of those mentioned filters,
later grew to its current state.

I don't know about the proposed scenario you give.
But I do know when my own site felt a little sluggish, I implemented APC and a cron job that preloads all the queries at the beginning of the day. Any changes to a table dump the cache and reload it. Site is now fast and the database is only pounded in the early AM cache preload (which may actually not even be necessary, but I do it just in case there are any scenarios where I change DB and forget to nuke cache for effected queries).

If database is your bottleneck, APC (or other caching methods) is your friend.

PHP General Mailing List (
To unsubscribe, visit:

Reply via email to