Re: Will PHP ever "grow up" and have threading?
| From: | Paul M Foster | Date: | Wed, 24 Mar 2010 01:57:18 +0000 |
| Subject: | Re: Will PHP ever "grow up" and have threading? | ||
| References: | 1 2 3 4 5 6 7 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-303161@lists.php.net to get a copy of this message | ||
On Tue, Mar 23, 2010 at 06:17:56PM -0700, 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
> * show all products for that category, if any,
> * show all manufacturers, used as filtering, for that category and
> subcategories
> * show price range filter for that category
> * show features & specifications filter for that category
> * show 10 top sellers for that category and related subcategories
> * the shopper can then select/deselect any of those filters and
> ability to sort by manufacturers, prices, user rating, popularity
> (purchased quantity)
> * have the ability to switch to another language translation on the fly
> * 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.
>
> 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?
That strikes me as a pretty stiff target, no matter how you look at it.
You effectively want 6 major queries at once, plus response in under 3
seconds on a 750000 row product table. I'm not sure I could produce that
kind of performance in C at the command line. (I'm sure some smart guy
on the list will say he can do it in 2 seconds flat over a 10 Base 2
network with teletypes and acoustic modems.)
Which brings me to my question. Why do people expect console-level
performance from a web browser? It's kind of rhetorical, since people
want everything they can get and more all the time. But if performance
came up as a customer question for me, I'd make it clear that they're
not going to get console-level performance from a web browser, unless
they want to spend a whole lot more money. Neither the world wide web
nor browser software were ever designed primarily with speed in mind.
The internet is not your local 64-bit 10 gigabyte memory loaded machine.
Paul
--
Paul M. Foster