Will PHP ever "grow up" and have threading?
in [General]
|
From: Robert Cummings on 23 Mar 2010 21:47 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 I don't currently know a site, sounds like a fun job though. > 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? Yes, I do. There's nothing in your requirements above that sound particularly difficult for PHP to handle with a good design and lots of caching... and of course the right hardware. I think you're hung up on the numbers a bit... those aren't very big numbers for a database. Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP
From: Paul M Foster on 23 Mar 2010 21:57 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
From: Tommy Pham on 23 Mar 2010 22:08 On Tue, Mar 23, 2010 at 6:57 PM, Paul M Foster <paulf(a)quillandmouse.com> wrote: > 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 > 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.
From: Robert Cummings on 23 Mar 2010 22:27 Paul M Foster wrote: > 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.) I'm not sure why you consider this 6 major queries. To show all sub-categories for a category is a major query only if you need to recursively gather sub-categories. Admittedly that would be a slow hit to the database server on first request, but afterwards one would expect the tree to be cached so the next request would be very fast due to priming of the cache. Show all products for a category should be quite fast, the category would be associated with an integer ID upon which I would presume indexing has occured. Presumably "show all" means show all products in a paged manner. The same principles should show true for manufacturer. Price range also plays nicely with indexes. Features and specifications may be a biut of a hump, but it depends. It's hard to say exactly what is meant by this filter. The top 10 sellers might be an issue, but I don't see why a cron job can't handle updating top sellers information so that this is an indexable field. I'm not sure why language translation would be an issue. Presumably if you have support for one, switching to another requires the same legwork with different pants. Also, it's notable that all of the search data is based on need to read only. This screams replication to me if the server is very busy. The big thing about indexes is that the more rows you add, the time to retrieve a particular indexed row only grows logarithmically. Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP
From: "Daniel P. Brown" on 23 Mar 2010 23:53
First of all, I'll apologize for the top-post. My DROID doesn't give me the option of top or bottom. So not ready for enterprise. Secondly, I'll append to the statements made by Larry that, unless it's non-web based, there are far more layers involved before, during, and after PHP's execution. Threading is fantastic.... if you're not relying on several other components (which are likely non-threaded themselves). On Mar 23, 2010 7:27 PM, "larry(a)garfieldtech.com" <larry(a)garfieldtech.com> wrote: On 3/23/10 6:04 PM, Tommy Pham wrote: > If throwing hardware at it won't work because of the above ... The word "enterprise" is meaningless in this context because it provides no context for the distinction. What does "enterprise" mean? Gets Captain Kirk to his next date? Is OpenOffice.org's plugin download site enterprise? Is Sony BMG enterprise? The sites for the cities of London and Athens? Whitehouse.gov? That's just a couple of sites now running on Drupal, a particular single-threaded PHP application. That's not counting the thousands of similar organizations running PHP (not even PHP-wrapping-custom-C like Yahoo) applications of various and sundry kinds. (Wikipedia anyone?) PHP *is* in the enterprise and quite happy there. "Not ready for the enterprise" is a totally meaningless statement. Similarly, if you cannot think of any way to scale an application that doesn't involve threads then I question your competence as a programmer. Sure, threads can be one way to speed things up. There are lots and lots of others that may be more or less appropriate depending on the circumstances. Threads have their own scaling issues, namely they have to live within the same process on the same box. That means when you hit the maximum size of your server, you're done. That doesn't mean threads are bad, but they have their trade-offs just like everything else does. But let's consider what adding threads to PHP would take. That would mean making PHP a shared-memory architecture, so that different requests now operated in the same memory space. That means RAM-based persistence. That means needing to write thread-safe PHP libraries. (Not the ones in C; I mean the millions of lines of code of PHP already out there.) In short, adding threading support to PHP means PHP is no longer PHP. It's Java with dollarsigns. It's a complete and total rewrite of the entire language runtime and environment, and all of the code build atop it. The idea that you could "just add threads" to PHP and make it "enterprise-ready" is so naive it's mind boggling. --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub... |