Will PHP ever "grow up" and have threading?
in [General]
|
From: Stuart Dallas on 24 Mar 2010 17:31 On 24 Mar 2010, at 19:42, 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 Cache it in something like memcached - I doubt these change very often. >>> * show all products for that category, if any, Cache it in something like memcached, and update that cache when products change. >>> * show all manufacturers, used as filtering, for that category and >>> subcategories Cache it. >>> * show price range filter for that category No need to cache this. >>> * show features & specifications filter for that category Cache it. >>> * show 10 top sellers for that category and related subcategories Generate offline and cache it. >>> * the shopper can then select/deselect any of those filters and >>> ability to sort by manufacturers, prices, user rating, popularity >>> (purchased quantity) Use something like Sphinx to handle searching the data. It's far quicker for doing filtering like this than SQL. >>> * have the ability to switch to another language translation on the fly Doing this would simply change a prefix to the cache keys. >>> * 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. I run a site that does very similar operations to this and response times average around 0.1s with the cache on, and 3-5ss with it off. Oh, and using a stopwatch doesn't take into account network latency or external dependencies. If you want an accurate timings you need to add that functionality into the code. >>> 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? You want an example? Facebook! -Stuart -- http://stut.net/
From: Stuart Dallas on 24 Mar 2010 17:42 On 24 Mar 2010, at 20:34, Rene Veerman wrote: > > 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: > 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. Again, improving the graphical content of a website has absolutely no effect on the performance of PHP. The additional time the page takes to load is all about network latency and how well you've arranged your static file serving. > oh, and the fact "cloud computing" is becoming more and more of a buzzword in the industry. Cloud computing really doesn't mean what you think it means. >> 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. By "realtime-web-app" you mean something like Facebook? They use a combination of PHP, Memcached (and lots of it), MySQL and lots of other layers in-between to do what they do, and threaded PHP is not one of them. > 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. What I'm getting here is that you want everything without paying for it. When it comes to scalability it's cheaper to achieve it by adding servers than it is to squeeze every last drop of performance out of a single box. The cost in development time alone to implement effective threading strategies would far outstrip the cost of adding a couple of servers and ensuring that your app is scalable. What you seem to be ignoring is the fact that these issues have been solved already, and the techniques that exist are more than adequate to build systems that scale as well as Facebook. What will it take to get you to accept that the way you want to skin the cat is exceedingly messy? -Stuart -- http://stut.net/
From: Stuart Dallas on 24 Mar 2010 17:46 On 24 Mar 2010, at 20:42, Rene Veerman wrote: > > 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. Minimal effort? You clearly have no understanding of what would be involved to get threading into the PHP core. It's not a minimal amount of effort, it means severe upheaval, not only for the core itself but also for every extension in existence, and potentially a fair amount of userland code that's out there. Oh, and I absolutely love the fact you think it's we who are barricading. Love it! -Stuart -- http://stut.net/
From: Tommy Pham on 24 Mar 2010 18:29 On Wed, Mar 24, 2010 at 1:24 PM, Robert Cummings <robert(a)interjinn.com> wrote: > > > Tommy Pham wrote: >> >> On Wed, Mar 24, 2010 at 4:28 AM, Per Jessen <per(a)computer.org> wrote: >>> >>> Tommy Pham wrote: >>> >>>> On Wed, Mar 24, 2010 at 3:44 AM, Per Jessen <per(a)computer.org> wrote: >>>>> >>>>> Tommy Pham wrote: >>>>> >>>>>> On Wed, Mar 24, 2010 at 3:20 AM, Per Jessen <per(a)computer.org> >>>>>> wrote: >>>>>>> >>>>>>> Tommy Pham wrote: >>>>>>> >>>>>>>> What I find funny is that one of opponents of PHP threads earlier >>>>>>>> mentioned that how silly it would be to be using C in a web app. >>>>>>>> Now I hear people mentioning C when they need "productivity" or >>>>>>>> "speed"... >>>>>>>> >>>>>>> I think I was the one to mention the latter, but as I started out >>>>>>> saying, and as others have said too, it's about the right tool for >>>>>>> the right job.  When choosing a tool, there are a number of factors >>>>>>> to consider - developer productivity, available skills, future >>>>>>> maintenance, performance, scalability, portability, parallelism, >>>>>>> performance etcetera. >>>>>>> >>>>>> Funny you should mention all that.  Let's say that you're longer >>>>>> with that company, either by direct employment or contract >>>>>> consultant. You've implemented C because you need 'thread'.  Now >>>>>> your replacement comes in and has no clue about C even though your >>>>>> replacement is a PHP guru.  How much headache is maintenance gonna >>>>>> be?  Scalability? Portability? wow.... >>>>> >>>>> Who was the idi... who hired someone who wasn't suited for the job? >>>>> Tommy, that's a moot argument.  You can't fit a square peg in a round >>>>> hole. >>>>> >>>>> -- >>>>> Per Jessen, Zürich (12.5°C) >>>>> >>>> Suited for the job?  You mean introduce more complexity to a problem >>>> that what could be avoided to begin with if PHP has thread support? >>>> hmmm.... >>> >>> Tommy, it's perfectly simple:  in my company we hire people with C >>> skills for C programming jobs. We hire people with database skills to >>> be database administrators.  We hire people with Linux skills to work >>> on Linux systems.  We explicitly do _not_ hire PHP web-programmers to >>> maintain our C code.  And vice versa for that matter.  No problem, no >>> complexity. >>> >>> >>> -- >>> Per Jessen, Zürich (13.4°C) >>> >>> >> >> That may just work out fine if you work directly for the company with >> all the proper staffing.  But some of us work as consultants or for >> companies without the proper staffing.  As such, let's dissect what >> you mentioned: >> >> 1) PHP with internal thread support >> 2) PHP with external C/C++ thread support >> >> * Performance - having external thread support, now you have to call >> an extension (more memory usage and CPU cycles).  If you happen to >> have a C/C++ guru who can then code that thread support into PHP >> extension, wouldn't it still perform better at the core vs as an >> extension because it's not talking to a 'middle man'?  Having said >> that, not everyone has access to a C/C++ guru.  Thus not mass >> availability. > > 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. > >> * Portability - if you're currently running PHP on Windows, but manage >> to convince management to switch to *BSD/Linux, then you'd have to >> rewrite that external thread support.  But for us consultants, we may >> have 1 project the runs on Windows, the next may be *BSD/Linux.  PHP >> code snippets goes a lot further versus your custom work around. >> * Managability - should your need to upgrade PHP for either bug fix, >> new features you'd want to implement to add more functionality to your >> site, will that then break your custom external solution?  How much >> more manageable is it if it's done under 1 language versus 2+? > > 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. > > Cheers, > Rob. > -- > http://www.interjinn.com > Application and Templating Framework for PHP > Suppose I have an idea and make it a project. I'd then want to make it open source and offer it to the world. With your custom thread solution, how much acceptance is it going to be for a decent PHP programmer to implement versus something that's already in pure PHP. Unzip/rar/tar > minor config for DB > Live. How does that sound for portability? Now that you mention cross platform threading, do you think you can take the MySQL compiled for linux and make it work under BSD withouth BSD's linux binaries compatibility, nevermind Windows? Have you looked at the source of PHP? For whatever OS PHP compiles for, it uses the header library pertaining to that OS. So if I want to implement thread solution similar to Per's solution, I'd have to be an expert at Windows, Linux, and *BSD just to make my PHP open source project to be readily acceptable to the world. I'll pass on that.
From: Tommy Pham on 24 Mar 2010 19:31
As some of you mention that implementing threads will make the DB work harder than the standard serial operations queries, let me ask you these then: * How often does your DB server(s)/cluster utilizes 100% CPU (SMP/MC), memory, and disk IO? * How long is the duration when 100% utilization occurs? * If you could implement threads and run those same queries in 2+ threads, the total time saved from queries execution is 1/2 sec or more, which is pass along as the total response time reduced. Is it worth it for you implement threads if you're a speed freak? (I remember a list member, not mentioning his name, does optimization of PHP coding for just microseconds. Do you think how much more he'd benefit from this?) * If the requests are executed in parallel, the sooner the request fulfillment completes, the faster it is to move to the next request and complete it right? |