Re: Will PHP ever "grow up" and have threading?
| From: | Stuart Dallas | Date: | Wed, 24 Mar 2010 21:31:06 +0000 |
| Subject: | Re: Will PHP ever "grow up" and have threading? | ||
| References: | 1 2 3 4 5 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-303383@lists.php.net to get a copy of this message | ||
On 24 Mar 2010, at 19:42, Tommy Pham wrote:
> On Wed, Mar 24, 2010 at 10:18 AM, Sancar Saran <sancar.saran@evodot.com> wrote:
>> On Wednesday 24 March 2010 03:17:56 Tommy Pham wrote:
>>> Let's go back to my 1st e-commerce example. The manufacturers list is
>>> about 3,700. The categories is about about 2,400. The products list
>>> is right now at 500,000 and expected to be around 750,000. The site
>>> is only in English. The store owner wants to expand and be I18n:
>>> Chinese, French, German, Korean, Spanish. You see how big and complex
>>> that database gets? The store owners want to have this happens when a
>>> customer clicks on a category:
>>>
>>> * show all subcategories for that category, if any
Cache it in something like memcached - I doubt these change very often.
>>> * show all products for that category, if any,
Cache it in something like memcached, and update that cache when products change.
>>> * show all manufacturers, used as filtering, for that category and
>>> subcategories
Cache it.
>>> * show price range filter for that category
No need to cache this.
>>> * show features & specifications filter for that category
Cache it.
>>> * show 10 top sellers for that category and related subcategories
Generate offline and cache it.
>>> * the shopper can then select/deselect any of those filters and
>>> ability to sort by manufacturers, prices, user rating, popularity
>>> (purchased quantity)
Use something like Sphinx to handle searching the data. It's far quicker for doing filtering
like this than SQL.
>>> * have the ability to switch to another language translation on the fly
Doing this would simply change a prefix to the cache keys.
>>> * from the moment the shopper click on a link, the response time (when
>>> web browser saids "Done" in the status bar) is 5 seconds or less.
>>> Preferably 2-3 seconds. Will be using stopwatch for the timer.
I run a site that does very similar operations to this and response times average around 0.1s with
the cache on, and 3-5ss with it off.
Oh, and using a stopwatch doesn't take into account network latency or external dependencies.
If you want an accurate timings you need to add that functionality into the code.
>>> Now show me a website that meets those requirements and uses PHP, I'll
>>> be glad to support your argument about PHP w/o threads :) BTW, this
>>> is not even enterprise requirement. I may have another possible
>>> project where # products is over 10 million easily. With similar
>>> requirements when the user click on category. Do you think this site,
>>> which currently isn't, can run on PHP?
You want an example? Facebook!
-Stuart
--
http://stut.net/