Will PHP ever "grow up" and have threading?
in [General]
|
From: "larry on 23 Mar 2010 19:25 On 3/23/10 6:04 PM, Tommy Pham wrote: > If throwing hardware at it won't work because of the above mentioned, > then you would change the design right? How long would that take? > What if PHP has threads, how long would it take you implement threads > with minor changes versus and overhaul of application design, coding, > QA, etc... In summary, you're saying that PHP can not grow/evolve with > business right? If the company started small and want to use > available open source solutions, then grow quickly because of their > unique and quality products and services, and become enterprise level > with-in a few years, what then? Slow down business growth just so > that IT can migrate everything to another language? Of all the > enterprise applications I've seen, they used threads. > > Regards, > Tommy 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
From: =?UTF-8?Q?Hans_=C3=85hlin?= on 23 Mar 2010 19:30 2010/3/24 Tommy Pham <tommyhp2(a)gmail.com>: > On Tue, Mar 23, 2010 at 3:33 PM, Per Jessen <per(a)computer.org> wrote: >> Tommy Pham wrote: >> >>> On Tue, Mar 23, 2010 at 2:04 AM, Per Jessen <per(a)computer.org> wrote: >>>> >>>> Use the right tool for the right job - PHP is a scripting/interpreted >>>> language, it does not need threading (IMO of course). >>>> >>>> >>>> -- >>>> Per Jessen, Zürich (9.4°C) >>>> >>>> >>> >>> I couldn't agree more.  But here's a real life example.  Your client >>> has a forum and is using phpbb for their in house use.  They also have >>> an in house custom PHP app, integrated with phpbb, built to suit their >>> needs.  Now they want to implement some kind of CMS.  You come in and >>> implemented a PHP based CMS to integrate into their existing >>> applications.  Then you realize something troublesome, you have a >>> performance issue where it could be resolved by implementing thread. >>> What are you going to do? >> >> The standard, mature, experienced answer is - buy a bigger box. >> > > The company started small.  As their business grows because they have > products & services that do not exist in the marketplace, their > hardware are already growing along side with it, (load balancers, > clusters).  So then your solution is buy bigger/more boxes?  What if > the their server room is filled and already using recent hardware. > Their current business needs doesn't need to move to a bigger > building.  What then? Hire data center's services?  What if they want > to protect their proprietary break through products and services? > What about unnecessary additional total cost of ownership (licenses, > power consumption, etc...) for more/bigger boxes, even if they have > available space, that could be avoided by just implementing threads? > That screams poor code design. Then to solve the problem might not be threading or change of language but a reanalyze of the code and the design, probably a re-write. >> [snip] >>> What do you think the client's response is when their need for the >>> solution requires a short time frame of, if not immediate, >>> implementation? >> >> There are no immediate solutions to immediate performance problems.  If >> you have a poor design that restricts your throughput, you can 1) throw >> hardware at it or 2) change the design.  At some point you'll hit yet >> another limit with 1), and you are forced back to 2).  Somewhere along >> the line the original designer has presumably left or been made to. >> >> >> /Per >> >> -- >> Per Jessen, Zürich (7.5°C) >> > > If throwing hardware at it won't work because of the above mentioned, > then you would change the design right?  How long would that take? > What if PHP has threads, how long would it take you implement threads > with minor changes versus and overhaul of application design, coding, > QA, etc... In summary, you're saying that PHP can not grow/evolve with > business right?  If the company started small and want to use > available open source solutions, then grow quickly because of their > unique and quality products and services, and become enterprise level > with-in a few years, what then?  Slow down business growth just so > that IT can migrate everything to another language? Of all the > enterprise applications I've seen, they used threads. > Same answer as above. > Regards, > Tommy > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- MvH / Hans à hlin Tel: +46761488019 http//www.kronan-net.com/
From: "Michael A. Peters" on 23 Mar 2010 20:31 Tommy Pham wrote: > On Tue, Mar 23, 2010 at 3:33 PM, Per Jessen <per(a)computer.org> wrote: >> Tommy Pham wrote: >> >>> On Tue, Mar 23, 2010 at 2:04 AM, Per Jessen <per(a)computer.org> wrote: >>>> Use the right tool for the right job - PHP is a scripting/interpreted >>>> language, it does not need threading (IMO of course). >>>> >>>> >>>> -- >>>> Per Jessen, Zürich (9.4°C) >>>> >>>> >>> I couldn't agree more. But here's a real life example. Your client >>> has a forum and is using phpbb for their in house use. They also have >>> an in house custom PHP app, integrated with phpbb, built to suit their >>> needs. Now they want to implement some kind of CMS. You come in and >>> implemented a PHP based CMS to integrate into their existing >>> applications. Then you realize something troublesome, you have a >>> performance issue where it could be resolved by implementing thread. >>> What are you going to do? >> The standard, mature, experienced answer is - buy a bigger box. >> > > The company started small. As their business grows because they have > products & services that do not exist in the marketplace, their > hardware are already growing along side with it, (load balancers, > clusters). So then your solution is buy bigger/more boxes? What if > the their server room is filled and already using recent hardware. > Their current business needs doesn't need to move to a bigger > building. What then? Hire data center's services? Very few companies have a legitimate reason to run their own server room at this point in time and should be using a data center if they are not already. Data centers have excellent bandwidth, diesel generators to keep things live during sustained power outages, temperature control to keep things cool, and often have technicians on hand with spare parts that can take care of many hardware issues 24/7.
From: Tommy Pham on 23 Mar 2010 21:17 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? Regards, Tommy
From: Tommy Pham on 23 Mar 2010 21:44
On Tue, Mar 23, 2010 at 6:17 PM, Tommy Pham <tommyhp2(a)gmail.com> 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 forgot to mention: * show 10 random sale specials for that category and 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? > > Regards, > Tommy > |