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 (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
