Will PHP ever "grow up" and have threading?
in [General]
|
From: Rene Veerman on 24 Mar 2010 16:25 On Wed, Mar 24, 2010 at 10:21 PM, Robert Cummings <robert(a)interjinn.com> wrote: > > > Rene Veerman wrote: >> >> On Wed, Mar 24, 2010 at 9:45 PM, Robert Cummings <robert(a)interjinn.com> >> wrote: >>> >>> Rene Veerman wrote: >>>> >>>> On Wed, Mar 24, 2010 at 9:31 PM, Robert Cummings <robert(a)interjinn.com> >>>> wrote: >>>>> >>>>> Rene Veerman wrote: >>>>>> >>>>>> On Wed, Mar 24, 2010 at 3:25 PM, Robert Cummings >>>>>> <robert(a)interjinn.com> >>>>>> wrote: >>>>>>> >>>>>>> Rene Veerman wrote: >>>>>>>> >>>>>>>> php is not a hammer, its a programming language. >>>>>>> >>>>>>> It's hard to discuss anything with someone who doesn't comprehend a >>>>>>> metaphor. >>>>>> >>>>>> haha. "comprehend". you mean "accept". >>>>>> that metaphor is stretched to breaking point as far as i'm concerned. >>>>>> >>>>>>>> one that i feel needs to stay ahead of the computing trend if it is >>>>>>>> to >>>>>>>> be considered a language for large scale applications. >>>>>>> >>>>>>> Personification of PHP doesn't make your argument any more salient. >>>>>>> PHP >>>>>>> isn't trying to stay ahead of anything. People are using it to solve >>>>>>> problems, not to meet some phantom ideal of a "computing trend" >>>>>>> threshold. >>>>>>> >>>>>>>> but you nay-sayers here have convinced me; i'll be shopping for >>>>>>>> another language with which to serve my applications and the >>>>>>>> weboutput >>>>>>>> they produce.. >>>>>>>> >>>>>>>> thanks for opening my eyes and telling to abandon ship in time. >>>>>>> >>>>>>> Obviously we didn't open your eyes. >>>>>>> >>>>>> Well excuse me for not dumping 50-100k lines of my own cms code >>>>>> instantly now that i realize that in order to scale it, i could really >>>>>> use features like threading and shared memory. >>>>> >>>>> Actually, you are th eone suggesting dumping your code since you said >>>>> you >>>>> were jumping ship. Many of us suggested that your problems can almost >>>>> certainly be mitigated without threading. >>>>> >>>> "almost certainly". at least you're acknowledging that you might be >>>> wrong. >>> >>> I'm certianly not right all the time. once I thought I was but I was >>> wrong. >>> >>>> 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..... >>> >>> I think you'll find when you get even close to the size of facebook, >>> everything you think you know now about how it all stays running will be >>> thrown out the window. But then, I'm not a fan of early optimization of >>> this >>> magnitude. A good design is usually flexible enough to allow redesign >>> without recoding everything. Baby steps to the moon IMHO. >>> >> yea, well, if i'm going to keep using php i need a path towards >> scalability, for this particular problem. >> >> i'd like to code the kinds of applications with big dataflows. >> call me a golddigger all you want, it's what i am ;) >> just not in the sexual sense hehe.. >> >>> Your tools are up to date. Threading is in the future if at all... it's >>> certainly not in the present. >> >> True, lets _keep_ 'm up-to-date, please. > > It is up to date. You mean make it have all the features you want. PHP is by > it's very existence and ongoing development "up to date". > yet you seem to oppose said development into the threading/shared-mem corner. without giving an alternative way to implement my previous case description (facebook/twitter level commenting to graphics-heavy pages at busy times). and that's just 1 case description. hundreds if not thousands more can be thought up or simply the best solution in the near future.
From: Robert Cummings on 24 Mar 2010 16:28 Rene Veerman wrote: > On Wed, Mar 24, 2010 at 10:21 PM, Robert Cummings <robert(a)interjinn.com> wrote: >> >> Rene Veerman wrote: >>> On Wed, Mar 24, 2010 at 9:45 PM, Robert Cummings <robert(a)interjinn.com> >>> wrote: >>>> Rene Veerman wrote: >>>>> On Wed, Mar 24, 2010 at 9:31 PM, Robert Cummings <robert(a)interjinn.com> >>>>> wrote: >>>>>> Rene Veerman wrote: >>>>>>> On Wed, Mar 24, 2010 at 3:25 PM, Robert Cummings >>>>>>> <robert(a)interjinn.com> >>>>>>> wrote: >>>>>>>> Rene Veerman wrote: >>>>>>>>> php is not a hammer, its a programming language. >>>>>>>> It's hard to discuss anything with someone who doesn't comprehend a >>>>>>>> metaphor. >>>>>>> haha. "comprehend". you mean "accept". >>>>>>> that metaphor is stretched to breaking point as far as i'm concerned. >>>>>>> >>>>>>>>> one that i feel needs to stay ahead of the computing trend if it is >>>>>>>>> to >>>>>>>>> be considered a language for large scale applications. >>>>>>>> Personification of PHP doesn't make your argument any more salient. >>>>>>>> PHP >>>>>>>> isn't trying to stay ahead of anything. People are using it to solve >>>>>>>> problems, not to meet some phantom ideal of a "computing trend" >>>>>>>> threshold. >>>>>>>> >>>>>>>>> but you nay-sayers here have convinced me; i'll be shopping for >>>>>>>>> another language with which to serve my applications and the >>>>>>>>> weboutput >>>>>>>>> they produce.. >>>>>>>>> >>>>>>>>> thanks for opening my eyes and telling to abandon ship in time. >>>>>>>> Obviously we didn't open your eyes. >>>>>>>> >>>>>>> Well excuse me for not dumping 50-100k lines of my own cms code >>>>>>> instantly now that i realize that in order to scale it, i could really >>>>>>> use features like threading and shared memory. >>>>>> Actually, you are th eone suggesting dumping your code since you said >>>>>> you >>>>>> were jumping ship. Many of us suggested that your problems can almost >>>>>> certainly be mitigated without threading. >>>>>> >>>>> "almost certainly". at least you're acknowledging that you might be >>>>> wrong. >>>> I'm certianly not right all the time. once I thought I was but I was >>>> wrong. >>>> >>>>> 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..... >>>> I think you'll find when you get even close to the size of facebook, >>>> everything you think you know now about how it all stays running will be >>>> thrown out the window. But then, I'm not a fan of early optimization of >>>> this >>>> magnitude. A good design is usually flexible enough to allow redesign >>>> without recoding everything. Baby steps to the moon IMHO. >>>> >>> yea, well, if i'm going to keep using php i need a path towards >>> scalability, for this particular problem. >>> >>> i'd like to code the kinds of applications with big dataflows. >>> call me a golddigger all you want, it's what i am ;) >>> just not in the sexual sense hehe.. >>> >>>> Your tools are up to date. Threading is in the future if at all... it's >>>> certainly not in the present. >>> True, lets _keep_ 'm up-to-date, please. >> It is up to date. You mean make it have all the features you want. PHP is by >> it's very existence and ongoing development "up to date". >> > > yet you seem to oppose said development into the threading/shared-mem corner. > > without giving an alternative way to implement my previous case > description (facebook/twitter level commenting to graphics-heavy pages > at busy times). > > and that's just 1 case description. hundreds if not thousands more can > be thought up or simply the best solution in the near future. I'm not sure why you think I'm opposed to such development. I've already told you to subscribe to internals or write your own patch. Do you need me to use a larger font? Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP
From: Sancar Saran on 24 Mar 2010 16:34 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 Sancar
From: Rene Veerman on 24 Mar 2010 16:34 On Wed, Mar 24, 2010 at 10:19 PM, Ashley Sheridan <ash(a)ashleysheridan.co.uk>wrote: > On Wed, 2010-03-24 at 22:15 +0200, Rene Veerman wrote: > > On Wed, Mar 24, 2010 at 10:05 PM, Ashley Sheridan > <ash(a)ashleysheridan.co.uk>wrote: > > > > > > > So you're basically saying that you'd discount anyone who opposes you > > purely because you think you know best? > > > > Nice attitude. > > > > I ain't saying that at all, nor did i intend to imply it. > > In fact it's the anti-threading/shared-mem camp that thinks they know > everything best with their instistance that "throw more hardware at it, more > sql servers, more programming languages in a single project" will solve all > software design / growth problems with enough efficiency. > > They're offering the alternative. You keep disagreeing with their viewpoint > because you seem to think you know best on this matter and won't even > concede on a point. > they're offering an alternative that would not solve the use-case i could think of within 1 day.. and they also say 'add more hardware' which means more overhead of every kind, resulting in wasteful business practices. > In this case, you still haven't given me any other reason to oppose the > evolution of php with the market trend > > Do you have any proof of this 'market trend'? I suggested a vote, but you > 'nay-sayed' it on the basis that you'd lose to people who couldn't possibly > know as much as you do. > yes, twitter. facebook. the fact that a graphics upgrade would likely increase business for the first ones on that popularity level to implement it. that's the proof i have for the market trend. oh, and the fact "cloud computing" is becoming more and more of a buzzword in the industry. > > I wouldn't say I belonged to any particular camp at the start of this > thread, but now, having read what my betters have said, I'm inclined to > agree that threading isn't the magic wand that you seem to think it is. I > personally see one of the largest sites in the world running on PHP without > needing threading and without insulting half the list to attempt to get it. > > you haven't offered me any description at all of how i'd solve the large-scale realtime-web-app with existing techniques. and if i explain why i'd need the features we've discussed, you dismiss it by accepting a generalized "that can be solved with more sql servers" answer that is admitted to increase costs in every department, including energy consumption. on a non-linear scale btw.
From: Rene Veerman on 24 Mar 2010 16:39
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, 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. > 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. |