Will PHP ever "grow up" and have threading?
in [General]
|
From: Tommy Pham on 24 Mar 2010 00:49 On Tue, Mar 23, 2010 at 9:13 PM, Phpster <phpster(a)gmail.com> wrote: > Most if that stuff should only be in the db as a reference and when editing > te lists. The actual user acessed data should sit in simple XML files that > can be passed to the client, broken out by category or prod line. The > reasons are simple, database access time is going to suck, no matter what > you are running. And why would you ever need to run translation real time.. I > can tell you from persoanl experience that such solution totally blows. I > lost that battle at work and the current solution build every field on the > fly each time with translation ( supporting 12 languages) and it's damn > slow. Cache out whatever you can, to an in memory cache or to the file > system. Let the web server do it's job of serving files, not processing > upteen little bits of data from a db. > > It's about design, from all I've seen, threading introduces about as many > challenges as problems it solves. > > Bastien If having the products info in categorized XML files as you mention, why the need for DB then? What about some product name changes to correctly describe the product without the informed shopper having to read the description/specifications? The translation is fetched from the DB and not using any 3rd party software translation on the fly. > > Sent from my iPod > > On Mar 23, 2010, at 9: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 >> * 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 >> >> -- >> PHP General Mailing List (http://www.php.net/) >> To unsubscribe, visit: http://www.php.net/unsub.php >> >
From: Teus Benschop on 24 Mar 2010 00:55 On Tue, 2010-03-23 at 21:32 -0700, Tommy Pham wrote: > # of requests / second can be solved by load balancers/clusters. What > about the multiple answers for a simple request per user as in my > example? How you would solve that if not by threading? Amazon has > about 30 million products and they have filters similar to what I > mentioned. But when clicking on one of the I18n site at the bottom, > you're taken to another server, which looks like it uses a different > DB back end (I could be wrong) and you don't get instant translation > of the category you're looking at. Their response time is about 3 > seconds on my 10mbs (not cable) download. As for what programming > language they use... > Well, the multiple answers for a simple request per user as in your example, seem to be a lot of information to display all on one page, and present all that information to the user in one request. I would probably resolve it, IMHO, by using pagers. That is, only part of the information is shown to the user at one time, and the user can page through that information so as to get to other bits of information. If only part is shown, then the database query becomes so much faster (hopefully), and PHP still can do all of it in one thread. A PHP application, by the nature of PHP, consists of small page requests to be done at one time, rather than move a lot of information around per request. Thinking the PHP-way requires some study because, as said, the information is presented or moved about in small chunks. Desktop applications, and probably Java web applications (I have no experience with Java but have read up on it a little) work differently. A successful PHP application is redesigned from the ground up, rather than remorphing a Java or other desktop application in PHP without changing the design principles. The key to makign your eCommerce application snappy, is, I think, not threading, but optimization of database queries. And another key is that less information presented to the user is usually clearer to the user, and thus they feel better at the site, and would return sooner to buy something. The real head-ache here and the difficult part is: How to design a clear and clean interface for the user. It's not threading. Teus.
From: Tommy Pham on 24 Mar 2010 03:04 On Tue, Mar 23, 2010 at 9:49 PM, Larry Garfield <larry(a)garfieldtech.com> wrote: > On Tuesday 23 March 2010 11:32:10 pm Tommy Pham wrote: >> On Tue, Mar 23, 2010 at 9:06 PM, Teus Benschop <teusjannette(a)gmail.com> > wrote: >> > When looking at PHP as used in enterprise class applications, we can see >> > the following happening. Let imagine that we have a site that gets a >> > 1000 requests per second. That seems to be a good candidate for >> > threading so as to be able to handle the 1000 requests per second. The >> > site runs PHP and Apache. Well, what happens? Each request coming in is >> > handed of to a separate instance of Apache. Thus the site would be able >> > to process many requests simultaneously. It looks as if parallel >> > computing is taking place here, which looks much like threading. Even >> > though PHP itself does not know about threads, and does not need to, I >> > think, the whole process of handling the 1000 requests per second uses >> > parallel computing. There are no performance bottle-necks here. Teus. >> >> # of requests / second can be solved by load balancers/clusters. Â What >> about the multiple answers for a simple request per user as in my >> example? Â How you would solve that if not by threading? Â Amazon has >> about 30 million products and they have filters similar to what I >> mentioned. Â But when clicking on one of the I18n site at the bottom, >> you're taken to another server, which looks like it uses a different >> DB back end (I could be wrong) and you don't get instant translation >> of the category you're looking at. Â Their response time is about 3 >> seconds on my 10mbs (not cable) download. Â As for what programming >> language they use... > > Honestly, how WOULD you solve that with threading? Â You describe a page that > needs to be generated that has a half-dozen queries against the database > ranging from simple to moderately complex, some of which are site-generic and > some are user-specific. > > How does one solve that with threading? > > 1) Run the site-generic queries once and cache them in memory and let other > threads just use that query result. Â You can do that without threads.. Â Just > render that part of the page and cache that string to disk, to the database, > or to memcache. Â If the memecache server is on the same box then it should be > identical to the threading version, performance-wise. Â (Give or take VM > considerations.) > > 2) Push the user-specific DB queries to separate threads so they can run in > parallel. Â All that does is push the hard work off onto the DB server, which is > still running the same number of queries. Â And PHP can't respond until all of > the queries finish anyway, and the DB server will respond no faster, so you're > really gaining nothing. > > You keep saying "how would you solve this without threads?" as if they're some > magical speed fairy dust. Â Given the scenario you describe, I don't even see > how threads would buy you anything at all. > > Where threads would be useful is for lots of very small writes on rapidly > changing data. Â I would never want to write, say, the World of Warcraft > servers without threading and a persistent runtime, but then I wouldn't want > to write them in PHP to begin with. > > Insert that old saying about hammers and nails here. > > --Larry Garfield > The difference is doing all those queries in serial operations (one after another) versus parallel operations (threads). Instead of waiting, for example, about .05 to .25 sec for each of those queries, the total wait time would be diminishes since each thread would execute a query. Either way, the DB is still doing the required total work. Difference is serial & parallel operations as I iterated several times. Being running in parallel, the web browser will be getting the required info faster since PHP is able to get all the info faster.
From: Tommy Pham on 24 Mar 2010 03:11 On Tue, Mar 23, 2010 at 9:55 PM, Teus Benschop <teusjannette(a)gmail.com> wrote: > On Tue, 2010-03-23 at 21:32 -0700, Tommy Pham wrote: >> # of requests / second can be solved by load balancers/clusters. Â What >> about the multiple answers for a simple request per user as in my >> example? Â How you would solve that if not by threading? Â Amazon has >> about 30 million products and they have filters similar to what I >> mentioned. Â But when clicking on one of the I18n site at the bottom, >> you're taken to another server, which looks like it uses a different >> DB back end (I could be wrong) and you don't get instant translation >> of the category you're looking at. Â Their response time is about 3 >> seconds on my 10mbs (not cable) download. Â As for what programming >> language they use... >> > > Well, the multiple answers for a simple request per user as in your > example, seem to be a lot of information to display all on one page, and > present all that information to the user in one request. I would > probably resolve it, IMHO, by using pagers. That is, only part of the Pagers are needed when there's a lot of products to display. But using the filters and show them is different. Look at Amazon (not endorsing it). Click any category. You'll see what I mean by the filters (manufacturers, price range, subcategories, etc) and the display requirements (specials, bestsellers) as I mentioned. They also have other things, like shoppers' discussions, on that page too. Think about how many queries they have to run for all that info to show based on a simple request of a 'category'. Then time the response time. > information is shown to the user at one time, and the user can page > through that information so as to get to other bits of information. If > only part is shown, then the database query becomes so much faster > (hopefully), and PHP still can do all of it in one thread. > > A PHP application, by the nature of PHP, consists of small page requests > to be done at one time, rather than move a lot of information around per > request. Thinking the PHP-way requires some study because, as said, the > information is presented or moved about in small chunks. Desktop > applications, and probably Java web applications (I have no experience > with Java but have read up on it a little) work differently. A > successful PHP application is redesigned from the ground up, rather than > remorphing a Java or other desktop application in PHP without changing > the design principles. > > The key to makign your eCommerce application snappy, is, I think, not > threading, but optimization of database queries. And another key is that > less information presented to the user is usually clearer to the user, > and thus they feel better at the site, and would return sooner to buy > something. The real head-ache here and the difficult part is: How to > design a clear and clean interface for the user. It's not threading. > > Teus. >
From: Rene Veerman on 24 Mar 2010 03:33
stop bashing the people who DO have a use for threading and other advanced concepts eh. just because you don't have a use for it, it shouldn't be included?! kinda arrogant. also kinda arrogant: how do you know the guy needing threading is not working on projects many times as complex as your own projects?? On Wed, Mar 24, 2010 at 12:33 AM, 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. > > [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) > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > |