Will PHP ever "grow up" and have threading?
in [General]
|
From: Rene Veerman on 24 Mar 2010 16:42 On Wed, Mar 24, 2010 at 10:34 PM, Sancar Saran <sancar.saran(a)evodot.com> wrote: > On Wednesday 24 March 2010 21:42:53 Tommy Pham wrote: >> On Wed, Mar 24, 2010 at 10:18 AM, Sancar Saran <sancar.saran(a)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 >> >> * 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 >> > >> > If you design and code correctly. Yes. >> > >> > >> > If you want to use someting alredy. Try TYPO3. >> > >> > PS: Your arguments are something about implementation not something about >> > platform abilities. You can do this things any server side programming >> > with enough hardware. >> > >> > Regards >> > >> > Sancar >> >> Platform abilities = PHP with/without threads. >> Implementation = If PHP has threads, how do I implement it. If not, >> what work around / hacks do I need to do. > > > Please forgive my low ability on English and you sound like. > > "I can drive a car, if it has a diesel engine and we want Ferrari for our > need. Is there any way to fit a diesel engine in Ferrari ?" > > Your problem isn't php, You problem is your way to think... > > You are trying to bend php to fit your way of the building web sites. > > I'm sorry, things does not work like that. > > You are trying to represent your business logic as "ENTERPRISE SOFTWARE > STANDARTS". > > I'm sorry, it wont ! > > Even with provocative subject, it still business logic at large. > > On Large Web sites, Site has own standards which enterprise must have to > obey.. (like Facebook or any other uber number cruncher you name it) > > Anyway... > > You want to build a damn huge web site with damn huge data set and damn huge > requests per second. > > and you still want to use that SQL for primary data store for reading. > > ARE YOU NUTS ??? > > With this kind of approach, > > You will be in deep trouble with any language, with any Reational SQL Server. > > If your customers need that kind of thing. You need lots of sophisticated > people which know how to handle big things under web enviroment. > > Good luck to you. > > Regards > how dramatic. how elitist. and btw, use of sql where other solutions (like shared mem and threading!) is exactly what i'm against. if you ppl just stop barracading, you'll see that with relatively minimal effort php can evolve with the times and make such things possible for us mere mortals.
From: Rene Veerman on 24 Mar 2010 16:44 Rene: >and btw, use of sql where other solutions (like shared mem and threading!) is exactly what i'm against. should read "where other solutions (...) are very likely to work better / more efficiently".. On Wed, Mar 24, 2010 at 10:42 PM, Rene Veerman <rene7705(a)gmail.com> wrote: > On Wed, Mar 24, 2010 at 10:34 PM, Sancar Saran <sancar.saran(a)evodot.com> wrote: >> On Wednesday 24 March 2010 21:42:53 Tommy Pham wrote: >>> On Wed, Mar 24, 2010 at 10:18 AM, Sancar Saran <sancar.saran(a)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 >>> >> * 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 >>> > >>> > If you design and code correctly. Yes. >>> > >>> > >>> > If you want to use someting alredy. Try TYPO3. >>> > >>> > PS: Your arguments are something about implementation not something about >>> > platform abilities. You can do this things any server side programming >>> > with enough hardware. >>> > >>> > Regards >>> > >>> > Sancar >>> >>> Platform abilities = PHP with/without threads. >>> Implementation = If PHP has threads, how do I implement it. If not, >>> what work around / hacks do I need to do. >> >> >> Please forgive my low ability on English and you sound like. >> >> "I can drive a car, if it has a diesel engine and we want Ferrari for our >> need. Is there any way to fit a diesel engine in Ferrari ?" >> >> Your problem isn't php, You problem is your way to think... >> >> You are trying to bend php to fit your way of the building web sites. >> >> I'm sorry, things does not work like that. >> >> You are trying to represent your business logic as "ENTERPRISE SOFTWARE >> STANDARTS". >> >> I'm sorry, it wont ! >> >> Even with provocative subject, it still business logic at large. >> >> On Large Web sites, Site has own standards which enterprise must have to >> obey.. (like Facebook or any other uber number cruncher you name it) >> >> Anyway... >> >> You want to build a damn huge web site with damn huge data set and damn huge >> requests per second. >> >> and you still want to use that SQL for primary data store for reading.. >> >> ARE YOU NUTS ??? >> >> With this kind of approach, >> >> You will be in deep trouble with any language, with any Reational SQL Server. >> >> If your customers need that kind of thing. You need lots of sophisticated >> people which know how to handle big things under web enviroment. >> >> Good luck to you. >> >> Regards >> > > how dramatic. > how elitist. > > and btw, use of sql where other solutions (like shared mem and > threading!) is exactly what i'm against. > > if you ppl just stop barracading, you'll see that with relatively > minimal effort php can evolve with the times and make such things > possible for us mere mortals. >
From: Sancar Saran on 24 Mar 2010 16:58 On Wednesday 24 March 2010 22:42:17 Rene Veerman wrote: > On Wed, Mar 24, 2010 at 10:34 PM, Sancar Saran <sancar.saran(a)evodot.com> wrote: > > On Wednesday 24 March 2010 21:42:53 Tommy Pham wrote: > >> On Wed, Mar 24, 2010 at 10:18 AM, Sancar Saran <sancar.saran(a)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 > >> >> * 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 > >> > > >> > If you design and code correctly. Yes. > >> > > >> > > >> > If you want to use someting alredy. Try TYPO3. > >> > > >> > PS: Your arguments are something about implementation not something > >> > about platform abilities. You can do this things any server side > >> > programming with enough hardware. > >> > > >> > Regards > >> > > >> > Sancar > >> > >> Platform abilities = PHP with/without threads. > >> Implementation = If PHP has threads, how do I implement it. If not, > >> what work around / hacks do I need to do. > > > > Please forgive my low ability on English and you sound like. > > > > "I can drive a car, if it has a diesel engine and we want Ferrari for our > > need. Is there any way to fit a diesel engine in Ferrari ?" > > > > Your problem isn't php, You problem is your way to think... > > > > You are trying to bend php to fit your way of the building web sites. > > > > I'm sorry, things does not work like that. > > > > You are trying to represent your business logic as "ENTERPRISE SOFTWARE > > STANDARTS". > > > > I'm sorry, it wont ! > > > > Even with provocative subject, it still business logic at large. > > > > On Large Web sites, Site has own standards which enterprise must have to > > obey.. (like Facebook or any other uber number cruncher you name it) > > > > Anyway... > > > > You want to build a damn huge web site with damn huge data set and damn > > huge requests per second. > > > > and you still want to use that SQL for primary data store for reading. > > > > ARE YOU NUTS ??? > > > > With this kind of approach, > > > > You will be in deep trouble with any language, with any Reational SQL > > Server. > > > > If your customers need that kind of thing. You need lots of sophisticated > > people which know how to handle big things under web enviroment. > > > > Good luck to you. > > > > Regards > > how dramatic. > how elitist. > > and btw, use of sql where other solutions (like shared mem and > threading!) is exactly what i'm against. > > if you ppl just stop barracading, you'll see that with relatively > minimal effort php can evolve with the times and make such things > possible for us mere mortals. Alright. Lets think different. And please don't take things personal... If the only problem is threading... Will Python with mod wsgi solve the problem ? with this programming approach ? Regards Sancar...
From: Robert Cummings on 24 Mar 2010 16:58 Rene Veerman wrote: > On Wed, Mar 24, 2010 at 10:24 PM, Robert Cummings <robert(a)interjinn.com> wrote: > >> Are you suggesting that you need to be a guru in C to write threaded C code? >> I think the word you're looking for is competent. > > plz dont make me repeat myself, i've already indicated my reasons as > to why i want to keep my codebase in 1 language, The above comment did not address your codebase and 1 language issue. It addressed the assertion that you need a C guru to write threaded C code. > and why i would like > to keep my large existing code base in php, and have php evolve with > the times, and allow applications written in it to grow easily to > large scale use. > > it would expand the user base of php as well i think. I think I'm going to win the lottery some day... I think. >> Are you suggesting cross platform thread libraries don't exist? I wonder how >> Apache does it... or MySQL... or any number of open source cross-platform >> systems. If they implement their own, then by the virtue of the source being >> open, you can feel free to incorporate. > > adding all these things as custom extensions that are hard to maintain > and increase software complexity, is not what i want. > > the reason i chose php is for it's simplicity of use. Perhaps you should have chosen based on the functionality YOU want. PHP remains simple for a reason. I think this will be me last comment to you. Your responses don't stay on track, they keep leading back to your constant "I want, I want, I want" screams. Let's list a few: I want to use PHP. I want threading in PHP. I want someone else to do it. I want to not have to change my designs. I want everyone to stop having their own opinion. I want to have my cake and eat it too. Ummm... so yeah... I can see why the discussion is mostly degenerative. Have you even subscribed to the internals list yet? Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP
From: Stuart Dallas on 24 Mar 2010 17:23
On 24 Mar 2010, at 19:35, Rene Veerman wrote: > > take this example, sorry for the crosspost; > > my main concern atm is my own cms (50-100k lines of my own); it's > graphics-heavy, does fairly complicated db based logic, and if it ever > is to be used for a site like facebook, it'll get large dataflows that > have to be distributed over the servers used to generate html and > accessoiries for end-users. > i've built a layer into it that caches the output of oft-used pages > (like articles and their comments). > but adding many comments / minute to an article would result in quite > a bit of overhead, to update the html for that page and distribute it > (fast enough) to the relevant servers. > > i'm worried about php's single-threaded nature; each request has to > fetch html updated in the last few seconds, or generate it from a list > of comments. that's also a big query from a big table for every > end-user.. :( > i'd rather keep them comments for an article in shared memory..... Shared memory in PHP generally means memcached. Look it up - it does exactly what you need here, and with the right usage strategy it's more than capable of handling data that changes many times a second. I think I'll need to spell this out, and I really hope you'll read this one properly. Use memcached to store data in the format in which you need to access it, update it when something changes not when requested and use the DB as permanent storage only. I've written highly scalable systems using this strategy, and the possibility that threading could improve the performance of said systems has never spent longer than a few seconds crossing my mind. And, if you don't mind me asking, when you say graphics-heavy do you mean it uses a lot of images? And if so, how the hell does that affect the scalability of PHP? -Stuart -- http://stut.net/ |