Re: [PHP] Will PHP ever "grow up" and have threading?
On Tue, Mar 23, 2010 at 9:49 PM, Larry Garfield wrote: > On Tuesday 23 March 2010 11:32:10 pm Tommy Pham wrote: >> On Tue, Mar 23, 2010 at 9:06 PM, Teus Benschop > 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. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
On Tue, Mar 23, 2010 at 9:55 PM, Teus Benschop 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. > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
Tommy Pham wrote: > 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. Same answer - buy a bigger box (i.e. serverroom). I would certainly also start a redesign from the ground up, but to solve the immediate problem, get more 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? Rent space and maybe hardware. That's what most businesses do. > 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? If you believe threading is such a silver bullet, I really think you need to reconsider. This business has already invested in more hardware to satisfy demand, so the application has some scalability - presumably achieved by running multiple processes. Threads have some advantages over processes, but when your design doesn't take that into account anyway, why do you need threads? [snip] > In summary, you're saying that PHP can not grow/evolve with > business right? Certainly not. PHP is just a language, like most other programming languages, it doesn't grow nor does it evolve a lot. (the OOP paradigm is an example of where PHP evolved). I'm saying that a back-of-a-fag-packet design won't grow nor evolve very well, and its inevitable shortcomings will not be solved by bolting on "threading". > 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. Tommy, that's not about the language, that's a design issue. Run PHP in multiple processes, and you've got the parallelism you seem to seek. /Per -- Per Jessen, Zürich (6.8°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
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 wrote: > Tommy Pham wrote: > >> On Tue, Mar 23, 2010 at 2:04 AM, Per Jessen 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 > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP to access shell script to print barcodes
The problem you're getting is that your web-server interprets the
request as a request for a normal file and just sends it - in effect,
you're not outputting the postscript file, you're just sending the
.php file. Normally, you'll only get your php executed if the file
requested is a .php or .phtml - unless you've changed your server
config.
Try creating a serveps.php that uses the header("Content-Disposition:
attachment; filename: 'serveps.ps'") instead, see if that helps you.
Regards
On 24 March 2010 06:09, Rob Gould wrote:
> Well, that did something, and it does sound like it should work. I've
> scoured the web and haven't found anyone with code that does what I'm trying
> to do.
>
> I've got a working, hardcoded Postscript file here:
>
> http://www.winecarepro.com/kiosk/fast/shell/barcodemerge.ps
>
> But I need to somehow serve it with PHP, so I can change some variables in it.
>
> By putting headers in place with PHP, and then doing an "echo" of the
> postscript, I get postscript errors (though Preview doesn't tell me what the
> error is):
>
> http://www.winecarepro.com/kiosk/fast/shell/serverps.ps
>
> Trying to trick the web-browser into thinking it's receiving Postscript from
> a PHP file is tricky. I don't know what to do next.
>
> Here's the code I was using in the above url:
> http://www.winecarepro.com/kiosk/fast/shell/serveps.php.zip
>
> It's not clear to me if the server is parsing the postscript first and then
> serving it, or if the server is server the postscript as-is and the browser
> sends it to Preview which interprets it.
>
> I basically want to replicate the functionality found here:
>
> http://blog.maniac.nl/webbased-pdf-lto-barcode-generator/
>
>
>
> On Mar 23, 2010, at 5:37 PM, Peter Lind wrote:
>
>> You can create a .php script that sets a proper header to make the
>> browser download the file rather than display it. That also allows you
>> to set the filename for the download. What you'd need to do is include
>> something like:
>>
>> header("Content-Disposition: attachment; filename: 'barcodemerge.ps'");
>>
>> That tells the browser to download the file. You can also try setting
>> the content-type
>>
>> header('Content-type: application/postscript');
>>
>> Either of the above might do the trick for you.
>>
>> Regards
>> Peter
>>
>> On 23 March 2010 22:10, Rob Gould wrote:
>>> I love the idea of using PHP to insert data into Postscript. I'm just not
>>> sure how to make it happen.
>>>
>>> The good news is that I've got barcodes drawing just the way I need them:
>>>
>>> http://www.winecarepro.com/kiosk/fast/shell/barcodemerge.ps
>>>
>>> The bad news is that's all hard-coded Postscript. I'd like to take your
>>> suggestion and use PHP to loop-through and draw the barcodes - - - however,
>>> if I put anything that resembles PHP in my .ps file, bad things happen.
>>>
>>> Anyone know the secret to creating a postscript .ps file that had PHP code
>>> injecting data into it?
>>>
>>> Here's the source file that works. Where PHP would be handy is at the very
>>> bottom of the script
>>>
>>> http://www.winecarepro.com/kiosk/fast/shell/barcodemerge.ps.zip
>>>
>>>
>>> On Mar 23, 2010, at 7:48 AM, Richard Quadling wrote:
>>>
On 23 March 2010 05:48, Jochem Maas wrote:
> Op 3/23/10 3:27 AM, Rob Gould schreef:
>> I am trying to replicate the functionality that I see on this site:
>>
>> http://blog.maniac.nl/webbased-pdf-lto-barcode-generator/
>>
>> Notice after you hit SUBMIT QUERY, you get a PDF file with a page of
>> barcodes. That's _exactly_ what I'm after.
>> Fortunately, the author gives step-by-step instructions on how to do
>> this on this page:
>>
>> http://blog.maniac.nl/2008/05/28/creating-lto-barcodes/
>>
>>
>> So I've gotten through all the steps, and have created the
>> "barcode_with_samples.ps" file, and have it hosted here:
>>
>> http://www.winecarepro.com/kiosk/fast/shell/
>>
>> Notice how the last few lines contain the shell-script that renders the
>> postscript:
>>
>> #!/bin/bash
>>
>> BASE=”100″;
>> NR=$BASE
>>
>> for hor in 30 220 410
>> do
>> ver=740
>> while [ $ver -ge 40 ];
>> do
>> printf -v FNR “(%06dL3)” $NR
>> echo “$hor $ver moveto $FNR (includetext height=0.55) code39 barcode”
>> let ver=$ver-70
>> let NR=NR+1
>> done
>> done
>>
>>
>> I need to somehow create a PHP script that "executes" this shell script.
>> And after doing some research, it sounds like
>> I need to use the PHP exec command, so I do that with the following file:
>>
>> http://www.winecarepro.com/kiosk/fast/shell/printbarcodes.php
>>
>> Which has the following script:
>>
>> >
>> $command="http://www.winecarepro.com/kiosk/fast/shell/barcode_with_sample.ps";;
>> exec($command, $arr);
>>
>> echo $arr;
>>
>> ?>
>>
>>
>> And, as you can
Re: [PHP] Will PHP ever "grow up" and have threading?
throw more hardware at it? how about you not butt into my business and how i save costs eh.. On Wed, Mar 24, 2010 at 9:31 AM, Per Jessen wrote: > Tommy Pham wrote: > >> 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. > > Same answer - buy a bigger box (i.e. serverroom). I would certainly > also start a redesign from the ground up, but to solve the immediate > problem, get more 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? > > Rent space and maybe hardware. That's what most businesses do. > >> 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? > > If you believe threading is such a silver bullet, I really think you > need to reconsider. This business has already invested in more > hardware to satisfy demand, so the application has some scalability - > presumably achieved by running multiple processes. Threads have some > advantages over processes, but when your design doesn't take that into > account anyway, why do you need threads? > > [snip] >> In summary, you're saying that PHP can not grow/evolve with >> business right? > > Certainly not. PHP is just a language, like most other programming > languages, it doesn't grow nor does it evolve a lot. (the OOP paradigm > is an example of where PHP evolved). > I'm saying that a back-of-a-fag-packet design won't grow nor evolve very > well, and its inevitable shortcomings will not be solved by bolting > on "threading". > >> 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. > > Tommy, that's not about the language, that's a design issue. Run PHP in > multiple processes, and you've got the parallelism you seem to seek. > > /Per > > -- > Per Jessen, Zürich (6.8°C) > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
and btw, complexity of design can go up considerably when you have to deal with more than 1 php and 1 mysql server, because the language forces inefficient constructs _and_ is "stuck on 1 server" On Wed, Mar 24, 2010 at 9:36 AM, Rene Veerman wrote: > throw more hardware at it? > > how about you not butt into my business and how i save costs eh.. > > On Wed, Mar 24, 2010 at 9:31 AM, Per Jessen wrote: >> Tommy Pham wrote: >> >>> 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. >> >> Same answer - buy a bigger box (i.e. serverroom). I would certainly >> also start a redesign from the ground up, but to solve the immediate >> problem, get more 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? >> >> Rent space and maybe hardware. That's what most businesses do. >> >>> 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? >> >> If you believe threading is such a silver bullet, I really think you >> need to reconsider. This business has already invested in more >> hardware to satisfy demand, so the application has some scalability - >> presumably achieved by running multiple processes. Threads have some >> advantages over processes, but when your design doesn't take that into >> account anyway, why do you need threads? >> >> [snip] >>> In summary, you're saying that PHP can not grow/evolve with >>> business right? >> >> Certainly not. PHP is just a language, like most other programming >> languages, it doesn't grow nor does it evolve a lot. (the OOP paradigm >> is an example of where PHP evolved). >> I'm saying that a back-of-a-fag-packet design won't grow nor evolve very >> well, and its inevitable shortcomings will not be solved by bolting >> on "threading". >> >>> 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. >> >> Tommy, that's not about the language, that's a design issue. Run PHP in >> multiple processes, and you've got the parallelism you seem to seek. >> >> /Per >> >> -- >> Per Jessen, Zürich (6.8°C) >> >> >> -- >> PHP General Mailing List (http://www.php.net/) >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
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? No, not really. So you want to add five languages - if your application is just half-way prepared for multiple languages, that's no big deal (apart from pure translation effort), and a database with only 5 million rows is also no big deal. If that is causing you a performance problem, it is definitely solveable by 1) hardware and 2) database optimization. > * 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. Yes, 3 seconds used to be the maximum response time for an inter-active application. The web might have moved the goal posts a bit :-) > 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 :) Tommy, you neglected to say anything about the number of concurrent users, but if you have e.g. 10.000, you will need enough hardware to run the webserver and the database. A webserver for serving 10.000 concurrent clients I would run on multiple boxes with an LVS load distribution mechanism in front. The 5 million row database is storage-wise not a lot, but running 10.000 concurrent queries will be a significant challenge. MySql cluster comes to mind. Apart from that, apache and mysql will do all the threading you need. /Per -- Per Jessen, Zürich (7.8°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
Teus Benschop wrote: > On Tue, 2010-03-23 at 19:08 -0700, Tommy Pham wrote: >> The response time, max 5 seconds, will be tested on local gigabit LAN >> to ensure the adequate response (optimized DB & code & proper >> hardware) without worrying about users' connection limit and site's >> upload bandwidth limit (which can easily rectify). Then thereafter >> will be doing stress test of about 10 concurrent users. As for the >> major queries, that's where threads come in, IMO, because those >> queries depend on 1 primary parameter (category ID) and 1 secondary >> parameter (language ID). This particular site starts with 500 >> products about 15 categories, without many of those mentioned >> filters, later grew to its current state. >> > The bottle neck looking at speed in this example seems to be the > database backend, not PHP. What would be needed is a fast database, > and SQL queries optimized for speed. Teus. > +1. -- Per Jessen, Zürich (7.8°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
Robert Cummings wrote: > Yes, I do. There's nothing in your requirements above that sound > particularly difficult for PHP to handle with a good design and lots > of caching... and of course the right hardware. I think you're hung up > on the numbers a bit... those aren't very big numbers for a database. Yeah. Given a decent database machine, those 5 millions rows can be kept in-core all the time. -- Per Jessen, Zürich (7.8°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
look per, i for one build systems designed to scale to popular levels. that means that whatever i can squeeze out of a single machine will save me money. quite a lot, coz as you know dedicated hosting gets very expensive when you have to buy fast machines. threading features and persistent shared memory _would_ decrease cost, a lot, for any php app that wants to scale to popular levels. i'd like to keep coding in php, and not have to switch languages because my app got popular. On Wed, Mar 24, 2010 at 9:46 AM, Per Jessen wrote: > Robert Cummings wrote: > >> Yes, I do. There's nothing in your requirements above that sound >> particularly difficult for PHP to handle with a good design and lots >> of caching... and of course the right hardware. I think you're hung up >> on the numbers a bit... those aren't very big numbers for a database. > > Yeah. Given a decent database machine, those 5 millions rows can be > kept in-core all the time. > > > > -- > Per Jessen, Zürich (7.8°C) > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
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? Ah, you're worried that running multiple sql queries sequentially will cause the response time to be too long? Now we're getting to the crux of the matter. My immediate thought is - if you can't optimize the database any further, run multiple http requests, there are ways of doing that. at. -- Per Jessen, Zürich (7.9°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
Per Jessen wrote: Teus Benschop wrote: On Tue, 2010-03-23 at 19:08 -0700, Tommy Pham wrote: The response time, max 5 seconds, will be tested on local gigabit LAN to ensure the adequate response (optimized DB& code& proper hardware) without worrying about users' connection limit and site's upload bandwidth limit (which can easily rectify). Then thereafter will be doing stress test of about 10 concurrent users. As for the major queries, that's where threads come in, IMO, because those queries depend on 1 primary parameter (category ID) and 1 secondary parameter (language ID). This particular site starts with 500 products about 15 categories, without many of those mentioned filters, later grew to its current state. The bottle neck looking at speed in this example seems to be the database backend, not PHP. What would be needed is a fast database, and SQL queries optimized for speed. Teus. +1. Seconded ... My own servers spend 75% of the time in firebird and 25% in apache/php, and when I need some extra performance I just add a second machine for firebird with a lot more memory. PHP is not the bottleneck and while the computer is 99.5% idle anyway I don't see any need for threading any time soon. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
Rene Veerman wrote: and btw, complexity of design can go up considerably when you have to deal with more than 1 php and 1 mysql server, because the language forces inefficient constructs _and_ is "stuck on 1 server" Switch to a real database? MySQL still needs to grow up as well :) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
jeez dude, you're assuming that all software problems are best solved by a sql solution. imo, they're NOT. example? any realtime system with real work to do. please stop pretending you know the proper design of all software that is made or yet has to be made. both a ya. On Wed, Mar 24, 2010 at 9:55 AM, Lester Caine wrote: > Rene Veerman wrote: >> >> and btw, complexity of design can go up considerably when you have to >> deal with more than 1 php and 1 mysql server, because the language >> forces inefficient constructs _and_ is "stuck on 1 server" > > Switch to a real database? > MySQL still needs to grow up as well :) > > -- > Lester Caine - G8HFL > - > Contact - http://lsces.co.uk/wiki/?page=contact > L.S.Caine Electronic Services - http://lsces.co.uk > EnquirySolve - http://enquirysolve.com/ > Model Engineers Digital Workshop - http://medw.co.uk// > Firebird - http://www.firebirdsql.org/index.php > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
Rene Veerman wrote: > stop bashing the people who DO have a use for threading and other > advanced concepts eh. I'm not bashing anyone. > just because you don't have a use for it, it shouldn't be included?! > kinda arrogant. Feel free to think so - I never said I don't have a use for it (threading), I just said thread-support doesn't belong in PHP. > also kinda arrogant: how do you know the guy needing threading is not > working on projects many times as complex as your own projects?? I don't care what he is working on. It has absolutely no bearing on the conversation. Please stop top-posting, it's not good netiquette. -- Per Jessen, Zürich (8.4°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
yes you are bashing them (me included) imo you say threading support doesnt belong in php; with that you're determining what i may and may not do, even if i have given you good reasons for it, that you chose to ignore. i hope the php developers have more sense than you. i'm done discussing this with you. and i like top-posting. a lot. you may wanna stop trying to change the ways of others, especially if they don't interfere with what YOU may and may not do. On Wed, Mar 24, 2010 at 10:02 AM, Per Jessen wrote: > Rene Veerman wrote: > >> stop bashing the people who DO have a use for threading and other >> advanced concepts eh. > > I'm not bashing anyone. > >> just because you don't have a use for it, it shouldn't be included?! >> kinda arrogant. > > Feel free to think so - I never said I don't have a use for it > (threading), I just said thread-support doesn't belong in PHP. > >> also kinda arrogant: how do you know the guy needing threading is not >> working on projects many times as complex as your own projects?? > > I don't care what he is working on. It has absolutely no bearing on the > conversation. > > Please stop top-posting, it's not good netiquette. > > > -- > Per Jessen, Zürich (8.4°C) > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
Rene Veerman wrote: > look per, i for one build systems designed to scale to popular levels. > > that means that whatever i can squeeze out of a single machine will > save me money. quite a lot, coz as you know dedicated hosting gets > very expensive when you have to buy fast machines. Well, at Hetzner in Nuernberg you can rent an EQ8 for EUR89/month. It comes with bandwidth, 1.5Tb software RAID, 24Gb RAM and a EUR149 setup cost. That's an Intel Core i7, so 2.6GHz quad core plus hyper-threading, meaning 4 to 8 concurrent processes. I've got four of the slightly smaller EQ4 running as backend mailservers handling up to about 3000 concurrent SMTP connections per box. Is that what you call a popular level? -- Per Jessen, Zürich (8.9°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
Rene Veerman wrote: jeez dude, you're assuming that all software problems are best solved by a sql solution. imo, they're NOT. example? any realtime system with real work to do. please stop pretending you know the proper design of all software that is made or yet has to be made. both a ya. I run real time systems for offices that count serving time in seconds. I know currently where the bottlenecks are, and adding 'threading' to PHP is not a solution. I fact adding much of the dross that has been added to PHP5 is ACTUALLY slowing down performance. I have PHP5.3 and PHP5.2 running on similarly loaded sites, and PHP5.2 is faster! I am just pointing out that on *MY* REAL applications, the SQL element is a major part of the processing time, and yes moving some of the table lookups to be hard coded arrays in PHP would make a difference, but then complicates configurability, so keeping them in the database makes life easier. The proper design is the one that meets the customers requirements and gets the bills paid. Processing the raw statistics required for my own sites is best done away from PHP, so using the right tools for the job is the important thing? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
On Wed, 2010-03-24 at 10:00 +0200, Rene Veerman wrote: > jeez dude, you're assuming that all software problems are best solved > by a sql solution. > imo, they're NOT. example? any realtime system with real work to do. > > please stop pretending you know the proper design of all software that > is made or yet has to be made. > both a ya. > > On Wed, Mar 24, 2010 at 9:55 AM, Lester Caine wrote: > > Rene Veerman wrote: > >> > >> and btw, complexity of design can go up considerably when you have to > >> deal with more than 1 php and 1 mysql server, because the language > >> forces inefficient constructs _and_ is "stuck on 1 server" > > > > Switch to a real database? > > MySQL still needs to grow up as well :) > > > > -- > > Lester Caine - G8HFL > > - > > Contact - http://lsces.co.uk/wiki/?page=contact > > L.S.Caine Electronic Services - http://lsces.co.uk > > EnquirySolve - http://enquirysolve.com/ > > Model Engineers Digital Workshop - http://medw.co.uk// > > Firebird - http://www.firebirdsql.org/index.php > > > > -- > > PHP General Mailing List (http://www.php.net/) > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > But aren't you doing exactly that by saying that PHP needs threading and that threading is the only way to achieve certain goals. I've watched this thread go on quite a bit, and haven't seen a really good argument that proves PHP needs threading when it can't be solved without it. PHP is PHP. If it behaved exactly the same as all the other languages, what would make it distinct against those others. One of it's main strenghts is its simplicity I feel. If you added threading to the bag of tricks it already has, you're getting into areas that make it more difficult to pick up for beginners (and that's not to mention the technical elements involved in actually adding threading to PHP) Currently the only other 'easy' language I know for beginners is ColdFusion, and that's just horrible. You wouldn't want to be responsible for sending the newbies down that path would you?! :p Thanks, Ash http://www.ashleysheridan.co.uk
Re: [PHP] Will PHP ever "grow up" and have threading?
popular : facebook youtube etc and you're still trying to impose a toolset on me. i think it's not strange to ask a programming language support basic hardware architecture features as they evolve into mainstream. On Wed, Mar 24, 2010 at 10:19 AM, Per Jessen wrote: > Rene Veerman wrote: > >> look per, i for one build systems designed to scale to popular levels. >> >> that means that whatever i can squeeze out of a single machine will >> save me money. quite a lot, coz as you know dedicated hosting gets >> very expensive when you have to buy fast machines. > > Well, at Hetzner in Nuernberg you can rent an EQ8 for EUR89/month. It > comes with bandwidth, 1.5Tb software RAID, 24Gb RAM and a EUR149 setup > cost. That's an Intel Core i7, so 2.6GHz quad core plus > hyper-threading, meaning 4 to 8 concurrent processes. > > I've got four of the slightly smaller EQ4 running as backend mailservers > handling up to about 3000 concurrent SMTP connections per box. Is that > what you call a popular level? > > > > -- > Per Jessen, Zürich (8.9°C) > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
so your systems represent all the software problems out there in the world? or your experience does? hard to believe. On Wed, Mar 24, 2010 at 10:15 AM, Lester Caine wrote: > Rene Veerman wrote: >> >> jeez dude, you're assuming that all software problems are best solved >> by a sql solution. >> imo, they're NOT. example? any realtime system with real work to do. >> >> please stop pretending you know the proper design of all software that >> is made or yet has to be made. >> both a ya. > > I run real time systems for offices that count serving time in seconds. I > know currently where the bottlenecks are, and adding 'threading' to PHP is > not a solution. I fact adding much of the dross that has been added to PHP5 > is ACTUALLY slowing down performance. I have PHP5.3 and PHP5.2 running on > similarly loaded sites, and PHP5.2 is faster! I am just pointing out that on > *MY* REAL applications, the SQL element is a major part of the processing > time, and yes moving some of the table lookups to be hard coded arrays in > PHP would make a difference, but then complicates configurability, so > keeping them in the database makes life easier. > > The proper design is the one that meets the customers requirements and gets > the bills paid. Processing the raw statistics required for my own sites is > best done away from PHP, so using the right tools for the job is the > important thing? > > -- > Lester Caine - G8HFL > - > Contact - http://lsces.co.uk/wiki/?page=contact > L.S.Caine Electronic Services - http://lsces.co.uk > EnquirySolve - http://enquirysolve.com/ > Model Engineers Digital Workshop - http://medw.co.uk// > Firebird - http://www.firebirdsql.org/index.php > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
Rene Veerman wrote: > yes you are bashing them (me included) imo > > you say threading support doesnt belong in php; with that you're > determining what i may and may not do, even if i have given you good > reasons for it, that you chose to ignore. Well, call it what you like, I think I'm being perfectly civil. By advocating that thread support does not belong in PHP, I am in no way determining what you (or anyone else) may or may not do. You are a free individual and free to choose the programming language and paradigm that is best suited to your purposes. Using your argument, one could also say that Kernighan and Ritchie determined that "C should have no threading", just as the US DoD was incredibly foresighted and decided we all should go multi-threaded when they gave Ada its tasks and rendezvous. -- Per Jessen, Zürich (9.0°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
On Wed, 2010-03-24 at 10:28 +0200, Rene Veerman wrote: > funny how i've been topposting for over a year here and the complaints > start when i tell some people not to butt into my business and choice > of tools. > > > > On Wed, Mar 24, 2010 at 10:11 AM, Ashley Sheridan > wrote: > > On Wed, 2010-03-24 at 10:07 +0200, Rene Veerman wrote: > > > > and i like top-posting. a lot. > > > > > > Rene, please do stop posting. It is in the mailing list rules > that you should bottom post. > > There is a reason for it. It helps with readability if > everyone conforms to the same practice, and the mailing > archives online are easier to digest also. > > i find 'm easier to digest with topposting. > > > Thanks, > Ash > http://www.ashleysheridan.co.uk > > > > > What you're actually saying is you find them easier to digest with both top AND bottom posting, because the majority of the list bottom posts as according to the rules, and you flaunt it deliberately for some reason. You're asking people on the list to not make assumptions about your applications and your 'need' for threading, and then blatantly ignore the rules on posting assuming that because you find a mix of top and bottom posting 'easier' to read, then so too will others. I'm not suddenly bringing this into focus now because you've asked people not to 'butt in' but because of the rude way you responded to Per Jessen about top-posting. I'm just asking that please, for the sake of clarity and readability, you bottom post to the list. If everyone does the same thing, it makes it a lot easier. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [PHP] Will PHP ever "grow up" and have threading?
On Wed, 2010-03-24 at 10:07 +0200, Rene Veerman wrote: > > and i like top-posting. a lot. Rene, please do stop posting. It is in the mailing list rules that you should bottom post. There is a reason for it. It helps with readability if everyone conforms to the same practice, and the mailing archives online are easier to digest also. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [PHP] Will PHP ever "grow up" and have threading?
On Wed, Mar 24, 2010 at 1:09 AM, Ashley Sheridan wrote: > On Wed, 2010-03-24 at 10:00 +0200, Rene Veerman wrote: > >> jeez dude, you're assuming that all software problems are best solved >> by a sql solution. >> imo, they're NOT. example? any realtime system with real work to do. >> >> please stop pretending you know the proper design of all software that >> is made or yet has to be made. >> both a ya. >> >> On Wed, Mar 24, 2010 at 9:55 AM, Lester Caine wrote: >> > Rene Veerman wrote: >> >> >> >> and btw, complexity of design can go up considerably when you have to >> >> deal with more than 1 php and 1 mysql server, because the language >> >> forces inefficient constructs _and_ is "stuck on 1 server" >> > >> > Switch to a real database? >> > MySQL still needs to grow up as well :) >> > >> > -- >> > Lester Caine - G8HFL >> > - >> > Contact - http://lsces.co.uk/wiki/?page=contact >> > L.S.Caine Electronic Services - http://lsces.co.uk >> > EnquirySolve - http://enquirysolve.com/ >> > Model Engineers Digital Workshop - http://medw.co.uk// >> > Firebird - http://www.firebirdsql.org/index.php >> > >> > -- >> > PHP General Mailing List (http://www.php.net/) >> > To unsubscribe, visit: http://www.php.net/unsub.php >> > >> > >> > > > But aren't you doing exactly that by saying that PHP needs threading and > that threading is the only way to achieve certain goals. I've watched > this thread go on quite a bit, and haven't seen a really good argument > that proves PHP needs threading when it can't be solved without it. PHP > is PHP. If it behaved exactly the same as all the other languages, what > would make it distinct against those others. One of it's main strenghts > is its simplicity I feel. If you added threading to the bag of tricks it > already has, you're getting into areas that make it more difficult to > pick up for beginners (and that's not to mention the technical elements > involved in actually adding threading to PHP) Currently the only other > 'easy' language I know for beginners is ColdFusion, and that's just > horrible. You wouldn't want to be responsible for sending the newbies > down that path would you?! :p > > Thanks, > Ash > http://www.ashleysheridan.co.uk > That's why I gave an analogy of AJAX earlier. You use AJAX yourself. Do you use it for every project? Would you recommend AJAX to newbies? When you do use AJAX, there is a slight difference in your app design then when you don't use AJAX. That's the way I see threads. It's not for every body nor for every project. But it would be great if it's there when the need/requirement arises. And yes, coldfusion should be phased out long ago... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
On Wed, Mar 24, 2010 at 10:36 AM, Per Jessen wrote: > By advocating that thread support does not belong in PHP, I am in no way > determining what you (or anyone else) may or may not do. You are a > free individual and free to choose the programming language and > paradigm that is best suited to your purposes. right! that's saying "you're free to leave behind the tool you've chosen for another one, because really, that tool should not start to support things that i dont happen to have a use for." -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
funny how i've been topposting for over a year here and the complaints start when i tell some people not to butt into my business and choice of tools. On Wed, Mar 24, 2010 at 10:11 AM, Ashley Sheridan wrote: > On Wed, 2010-03-24 at 10:07 +0200, Rene Veerman wrote: > > and i like top-posting. a lot. > > > > Rene, please do stop posting. It is in the mailing list rules that you > should bottom post. > > There is a reason for it. It helps with readability if everyone conforms to > the same practice, and the mailing archives online are easier to digest > also. > i find 'm easier to digest with topposting. > > > Thanks, > Ash > http://www.ashleysheridan.co.uk > > >
Re: [PHP] Will PHP ever "grow up" and have threading?
Rene Veerman wrote: > popular : facebook youtube etc > Rene, I must be missing something here. That sort of size implies millions in advertising revenue, so why are we discussing how much performance we can squeeze out of a single box? I mean, I'm all for efficient use of system resources, but if I have a semi-scalable application, it's a lot easier just getting another box than trying to change the implementation language. OTOH, if my design is not scalable, it's probably also easier to redo it than trying to change the implementation language. > and you're still trying to impose a toolset on me. I didn't think I was - you're the one who seem to be fixed on PHP as the only solution, and advocating that it be enhanced to suit your purposes. -- Per Jessen, Zürich (9.2°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
talk to me about this some other time. atm i'm having an argument with per and his kind about their very very annoying behaviour of determining my toolset for me. keeping a thread on topic is also ettiquette from the mailinglist rules eh? you might wanna consider just how much it pisses me off to have strangers determining my toolset and/or lifestyle for me. that's why i got rude. no other reason. On Wed, Mar 24, 2010 at 10:30 AM, Ashley Sheridan wrote: > On Wed, 2010-03-24 at 10:28 +0200, Rene Veerman wrote: > > funny how i've been topposting for over a year here and the complaints > start when i tell some people not to butt into my business and choice of > tools. > > > > > On Wed, Mar 24, 2010 at 10:11 AM, Ashley Sheridan < > a...@ashleysheridan.co.uk> wrote: > > On Wed, 2010-03-24 at 10:07 +0200, Rene Veerman wrote: > > and i like top-posting. a lot. > > > > > Rene, please do stop posting. It is in the mailing list rules that you > should bottom post. > > There is a reason for it. It helps with readability if everyone conforms to > the same practice, and the mailing archives online are easier to digest > also. > > > > i find 'm easier to digest with topposting. > > > > Thanks, > Ash > http://www.ashleysheridan.co.uk > > > > > > What you're actually saying is you find them easier to digest with both top > AND bottom posting, because the majority of the list bottom posts as > according to the rules, and you flaunt it deliberately for some reason. > You're asking people on the list to not make assumptions about your > applications and your 'need' for threading, and then blatantly ignore the > rules on posting assuming that because you find a mix of top and bottom > posting 'easier' to read, then so too will others. > > I'm not suddenly bringing this into focus now because you've asked people > not to 'butt in' but because of the rude way you responded to Per Jessen > about top-posting. I'm just asking that please, for the sake of clarity and > readability, you bottom post to the list. If everyone does the same thing, > it makes it a lot easier. > > > Thanks, > Ash > http://www.ashleysheridan.co.uk > > >
Re: [PHP] Will PHP ever "grow up" and have threading?
Tommy Pham wrote: > When you do use AJAX, there is a slight difference in your app design > then when you don't use AJAX. That's the way I see threads. A threaded design makes for a lot more than a slight difference IMHO. Once you've said "threading", the next words in rapid succession are: mutexes, semaphores, locking, spin-locks, signals, race conditions, atomic updates, cache coherency, asynchronous IO etcetera. They are all perfectly well-known but complex concepts, and I would always choose C and/or assembler to work with those. -- Per Jessen, Zürich (9.5°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
Rene Veerman wrote: > funny how i've been topposting for over a year here and the complaints > start when i tell some people not to butt into my business and choice > of tools. Rene, the only reason I mentioned it was because your language was becoming abusive and annoying. If it hadn't, I wouldn't have mentioned your equally annoying top-posting. I've been around for long enough to know that most top-posters will eventually see the light. -- Per Jessen, Zürich (9.8°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
On Wed, Mar 24, 2010 at 10:47 AM, Per Jessen wrote: > Rene Veerman wrote: > >> popular : facebook youtube etc >> > > Rene, I must be missing something here. That sort of size implies > millions in advertising revenue, so why are we discussing how much > performance we can squeeze out of a single box? I mean, I'm all for > efficient use of system resources, but if I have a semi-scalable > application, it's a lot easier just getting another box than trying to > change the implementation language. OTOH, if my design is not > scalable, it's probably also easier to redo it than trying to change > the implementation language. again: a) you're determining the contents of my toolset, without it affecting you at all. the way you want it php will degrade into a toy language. b) i will aim for all possible decreases in development time and operating costs during, not only in the grow phase but also in hard economic times. any business person knows why. > >> and you're still trying to impose a toolset on me. > > I didn't think I was - you're the one who seem to be fixed on PHP as the > only solution, and advocating that it be enhanced to suit your > purposes. no, php is just my toolset of choice, and i think it should grow with the times and support threading and shared memory. maybe even a few cool features to enable use-as-a-cloud. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
exactly. the knock-on problems you mentioned are well solved and well documented. realtime programmers using threads have to get their heads around it on their first realtime project. i don't like doing my code in c(++), or worse; having to interface between c(++) and php. i chose php because my code can stay close to simple english that way. what you're suggesting is highly intrusive in my work-style, one that you're not affected by at all. in fact if you make things more difficult for me, i have less time to release opensource code of my own. On Wed, Mar 24, 2010 at 10:59 AM, Per Jessen wrote: > Tommy Pham wrote: > >> When you do use AJAX, there is a slight difference in your app design >> then when you don't use AJAX. That's the way I see threads. > > A threaded design makes for a lot more than a slight difference IMHO. > Once you've said "threading", the next words in rapid succession are: > mutexes, semaphores, locking, spin-locks, signals, race conditions, > atomic updates, cache coherency, asynchronous IO etcetera. They are > all perfectly well-known but complex concepts, and I would always > choose C and/or assembler to work with those. > > > > -- > Per Jessen, Zürich (9.5°C) > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
Rene Veerman wrote: > again: > a) you're determining the contents of my toolset, without it affecting > you at all. the way you want it php will degrade into a toy language. Rene, it seems to me that you and I are advocating two opposite positions on the topic of threading in PHP, so aren't we both trying to determine the contents of each others toolset? > b) i will aim for all possible decreases in development time and > operating costs during, not only in the grow phase but also in hard > economic times. any business person knows why. Given that the lifetime effort (=cost) of any software project is divided into 25% development and 75% maintenance, you really ought to focus on the latter. If you want more performance at a minimal cost, surely you should opt to write in a compiled language where you'll get far more bang for the buck. -- Per Jessen, Zürich (9.8°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
On Wed, Mar 24, 2010 at 11:13 AM, Per Jessen wrote: > Rene Veerman wrote: > >> again: >> a) you're determining the contents of my toolset, without it affecting >> you at all. the way you want it php will degrade into a toy language. > > Rene, it seems to me that you and I are advocating two opposite > positions on the topic of threading in PHP, so aren't we both trying to > determine the contents of each others toolset? > Per: that's EXACTLY the point. You are determining it for me, i'm not for you. Simply because you dont have to use the language features you atm think you don't need in php. >> b) i will aim for all possible decreases in development time and >> operating costs during, not only in the grow phase but also in hard >> economic times. any business person knows why. > > Given that the lifetime effort (=cost) of any software project is > divided into 25% development and 75% maintenance, you really ought to > focus on the latter. If you want more performance at a minimal cost, > surely you should opt to write in a compiled language where you'll get > far more bang for the buck. > zend? facebook compiler? i'm staying with php coz the trend is towards jit compiling bro. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
Heh, you guys are funny! On 24 Mar 2010, at 08:58, Rene Veerman wrote: > On Wed, Mar 24, 2010 at 10:47 AM, Per Jessen wrote: >> Rene Veerman wrote: >> >>> popular : facebook youtube etc >>> >> >> Rene, I must be missing something here. That sort of size implies >> millions in advertising revenue, so why are we discussing how much >> performance we can squeeze out of a single box? I mean, I'm all for >> efficient use of system resources, but if I have a semi-scalable >> application, it's a lot easier just getting another box than trying to >> change the implementation language. OTOH, if my design is not >> scalable, it's probably also easier to redo it than trying to change >> the implementation language. > > again: > a) you're determining the contents of my toolset, without it affecting > you at all. the way you want it php will degrade into a toy language. And how exactly are you defining a toy language? If you want features like threading, why not switch to a language that already supports it? > b) i will aim for all possible decreases in development time and > operating costs during, not only in the grow phase but also in hard > economic times. any business person knows why. Yup, this is very good practice, but deciding that one particular tool is the only option is a fatal business decision. Use the right tool for the job! What you're trying to do here is akin to taking a hammer and whittling a screwdriver in to the handle. It's ridiculously inefficient, and imo, pretty stupid. >>> and you're still trying to impose a toolset on me. >> >> I didn't think I was - you're the one who seem to be fixed on PHP as the >> only solution, and advocating that it be enhanced to suit your >> purposes. > > no, php is just my toolset of choice, and i think it should grow with > the times and support threading and shared memory. > maybe even a few cool features to enable use-as-a-cloud. PHP is a hammer, and a bloody good one at that, but you seem to want it to be a tool shed. Accept that it's a hammer, go visit a DIY store, find the right tool for the job and get on with your life! The fact is that even if we all agree that PHP needs threading, and one or more people start working on putting it into the core, it will likely be many months before you see any sight of a working version, and even longer before you see a stable release. -Stuart -- http://stut.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
Rene Veerman wrote: > what you're suggesting is highly intrusive in my work-style, one that > you're not affected by at all. Hmm, you're the one suggesting a change, I'm suggesting no change. How can "no change" be intrusive? > in fact if you make things more difficult for me, i have less time to > release opensource code of my own. Well, we can't have that, so how about we stick to "no change", thereby not making anything more difficult for you. It will remain exactly as difficult as it is today. -- Per Jessen, Zürich (10.4°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Will PHP ever "grow up" and have threading?
If you added threading to the bag of tricks it already has, you're getting into areas that make it more difficult to pick up for beginners (and that's not to mention the technical elements involved in actually adding threading to PHP) Currently the only other 'easy' language I know for beginners is ColdFusion, and that's just horrible. You wouldn't want to be responsible for sending the newbies down that path would you?! :p Thanks, Ash http://www.ashleysheridan.co.uk == That's not a good argument against implementing threading, regardless of the technical issues involved in making it work. There are plenty of more advanced areas of php that beginners stay clear of. Just because threading is available doesn't mean it will automatically be used or even considered in most projects. I wrote C code for years in a large fairly complex banking front-office system and only found a very few occasions where threading was required to get the job done. In the majority of C and C++ code you find very few examples of threading, either because it's not required (99.9% of the time) or the coder didn't feel comfortable using it and found another way to achieve the result. In the few occasions where I did use threading I would say that most the time there was no other way of achieving the required result. But the issues you need to solve with C are very different to the issues you need to solve with php. I've spent more than 8 years coding php and I haven't ever hit a brick wall because of the lack of threading, but of course every project is different and I'm sure there are situations out there where trying to work around the lack of threading can cause major hassles. But as others have pointed out you use the right tools for the job, and if php doesn't have what is required then use something else. Cheers Arno -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
Rene Veerman wrote: >>> b) i will aim for all possible decreases in development time and >>> operating costs during, not only in the grow phase but also in hard >>> economic times. any business person knows why. >> >> Given that the lifetime effort (=cost) of any software project is >> divided into 25% development and 75% maintenance, you really ought to >> focus on the latter. If you want more performance at a minimal cost, >> surely you should opt to write in a compiled language where you'll >> get far more bang for the buck. >> > zend? facebook compiler? C, then assembler. C for productivity, assembler for raw speed. PHP for prototyping and web frontends (to which it is very well suited IMHO). (assembler is usually bad for both productivity and maintenance, but if speed is paramount, well). -- Per Jessen, Zürich (10.4°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
php is not a hammer, its a programming language. one that i feel needs to stay ahead of the computing trend if it is to be considered a language for large scale applications. 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. On Wed, Mar 24, 2010 at 11:22 AM, Stuart Dallas wrote: > Heh, you guys are funny! > > On 24 Mar 2010, at 08:58, Rene Veerman wrote: > >> On Wed, Mar 24, 2010 at 10:47 AM, Per Jessen wrote: >>> Rene Veerman wrote: >>> popular : facebook youtube etc >>> >>> Rene, I must be missing something here. That sort of size implies >>> millions in advertising revenue, so why are we discussing how much >>> performance we can squeeze out of a single box? I mean, I'm all for >>> efficient use of system resources, but if I have a semi-scalable >>> application, it's a lot easier just getting another box than trying to >>> change the implementation language. OTOH, if my design is not >>> scalable, it's probably also easier to redo it than trying to change >>> the implementation language. >> >> again: >> a) you're determining the contents of my toolset, without it affecting >> you at all. the way you want it php will degrade into a toy language. > > And how exactly are you defining a toy language? If you want features like > threading, why not switch to a language that already supports it? > >> b) i will aim for all possible decreases in development time and >> operating costs during, not only in the grow phase but also in hard >> economic times. any business person knows why. > > Yup, this is very good practice, but deciding that one particular tool is the > only option is a fatal business decision. Use the right tool for the job! > > What you're trying to do here is akin to taking a hammer and whittling a > screwdriver in to the handle. It's ridiculously inefficient, and imo, pretty > stupid. > and you're still trying to impose a toolset on me. >>> >>> I didn't think I was - you're the one who seem to be fixed on PHP as the >>> only solution, and advocating that it be enhanced to suit your >>> purposes. >> >> no, php is just my toolset of choice, and i think it should grow with >> the times and support threading and shared memory. >> maybe even a few cool features to enable use-as-a-cloud. > > PHP is a hammer, and a bloody good one at that, but you seem to want it to be > a tool shed. Accept that it's a hammer, go visit a DIY store, find the right > tool for the job and get on with your life! > > The fact is that even if we all agree that PHP needs threading, and one or > more people start working on putting it into the core, it will likely be many > months before you see any sight of a working version, and even longer before > you see a stable release. > > -Stuart > > -- > http://stut.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
unless the actual php development team would like to weigh in on this matter of course. yes, i do consider it that important. these nay-sayers usually also lobby the dev-team to such extent that these features would actually not make it into php. On Wed, Mar 24, 2010 at 11:31 AM, Rene Veerman wrote: > php is not a hammer, its a programming language. > > one that i feel needs to stay ahead of the computing trend if it is to > be considered a language for large scale applications. > > 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. > > > On Wed, Mar 24, 2010 at 11:22 AM, Stuart Dallas wrote: >> Heh, you guys are funny! >> >> On 24 Mar 2010, at 08:58, Rene Veerman wrote: >> >>> On Wed, Mar 24, 2010 at 10:47 AM, Per Jessen wrote: Rene Veerman wrote: > popular : facebook youtube etc > Rene, I must be missing something here. That sort of size implies millions in advertising revenue, so why are we discussing how much performance we can squeeze out of a single box? I mean, I'm all for efficient use of system resources, but if I have a semi-scalable application, it's a lot easier just getting another box than trying to change the implementation language. OTOH, if my design is not scalable, it's probably also easier to redo it than trying to change the implementation language. >>> >>> again: >>> a) you're determining the contents of my toolset, without it affecting >>> you at all. the way you want it php will degrade into a toy language. >> >> And how exactly are you defining a toy language? If you want features like >> threading, why not switch to a language that already supports it? >> >>> b) i will aim for all possible decreases in development time and >>> operating costs during, not only in the grow phase but also in hard >>> economic times. any business person knows why. >> >> Yup, this is very good practice, but deciding that one particular tool is >> the only option is a fatal business decision. Use the right tool for the job! >> >> What you're trying to do here is akin to taking a hammer and whittling a >> screwdriver in to the handle. It's ridiculously inefficient, and imo, pretty >> stupid. >> > and you're still trying to impose a toolset on me. I didn't think I was - you're the one who seem to be fixed on PHP as the only solution, and advocating that it be enhanced to suit your purposes. >>> >>> no, php is just my toolset of choice, and i think it should grow with >>> the times and support threading and shared memory. >>> maybe even a few cool features to enable use-as-a-cloud. >> >> PHP is a hammer, and a bloody good one at that, but you seem to want it to >> be a tool shed. Accept that it's a hammer, go visit a DIY store, find the >> right tool for the job and get on with your life! >> >> The fact is that even if we all agree that PHP needs threading, and one or >> more people start working on putting it into the core, it will likely be >> many months before you see any sight of a working version, and even longer >> before you see a stable release. >> >> -Stuart >> >> -- >> http://stut.net/ > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
and if threading and shared memory aren't implemented, then hey, the php dev team can build something else in that these naysayers DO need eh... lol... On Wed, Mar 24, 2010 at 11:36 AM, Rene Veerman wrote: > unless the actual php development team would like to weigh in on this > matter of course. > > yes, i do consider it that important. > > these nay-sayers usually also lobby the dev-team to such extent that > these features would actually not make it into php. > > On Wed, Mar 24, 2010 at 11:31 AM, Rene Veerman wrote: >> php is not a hammer, its a programming language. >> >> one that i feel needs to stay ahead of the computing trend if it is to >> be considered a language for large scale applications. >> >> 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. >> >> >> On Wed, Mar 24, 2010 at 11:22 AM, Stuart Dallas wrote: >>> Heh, you guys are funny! >>> >>> On 24 Mar 2010, at 08:58, Rene Veerman wrote: >>> On Wed, Mar 24, 2010 at 10:47 AM, Per Jessen wrote: > Rene Veerman wrote: > >> popular : facebook youtube etc >> > > Rene, I must be missing something here. That sort of size implies > millions in advertising revenue, so why are we discussing how much > performance we can squeeze out of a single box? I mean, I'm all for > efficient use of system resources, but if I have a semi-scalable > application, it's a lot easier just getting another box than trying to > change the implementation language. OTOH, if my design is not > scalable, it's probably also easier to redo it than trying to change > the implementation language. again: a) you're determining the contents of my toolset, without it affecting you at all. the way you want it php will degrade into a toy language. >>> >>> And how exactly are you defining a toy language? If you want features like >>> threading, why not switch to a language that already supports it? >>> b) i will aim for all possible decreases in development time and operating costs during, not only in the grow phase but also in hard economic times. any business person knows why. >>> >>> Yup, this is very good practice, but deciding that one particular tool is >>> the only option is a fatal business decision. Use the right tool for the >>> job! >>> >>> What you're trying to do here is akin to taking a hammer and whittling a >>> screwdriver in to the handle. It's ridiculously inefficient, and imo, >>> pretty stupid. >>> >> and you're still trying to impose a toolset on me. > > I didn't think I was - you're the one who seem to be fixed on PHP as the > only solution, and advocating that it be enhanced to suit your > purposes. no, php is just my toolset of choice, and i think it should grow with the times and support threading and shared memory. maybe even a few cool features to enable use-as-a-cloud. >>> >>> PHP is a hammer, and a bloody good one at that, but you seem to want it to >>> be a tool shed. Accept that it's a hammer, go visit a DIY store, find the >>> right tool for the job and get on with your life! >>> >>> The fact is that even if we all agree that PHP needs threading, and one or >>> more people start working on putting it into the core, it will likely be >>> many months before you see any sight of a working version, and even longer >>> before you see a stable release. >>> >>> -Stuart >>> >>> -- >>> http://stut.net/ >> > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
On 24 March 2010 10:38, Rene Veerman wrote: > and if threading and shared memory aren't implemented, then hey, the > php dev team can build something else in that these naysayers DO need > eh... > > lol... Do you have any idea how sad and pathetic you come across? I'm very sorry to say this, but really, now's the time to stop posting and step back, take a deep breath, then focus on something else. > On Wed, Mar 24, 2010 at 11:36 AM, Rene Veerman wrote: >> unless the actual php development team would like to weigh in on this >> matter of course. >> >> yes, i do consider it that important. >> >> these nay-sayers usually also lobby the dev-team to such extent that >> these features would actually not make it into php. >> >> On Wed, Mar 24, 2010 at 11:31 AM, Rene Veerman wrote: >>> php is not a hammer, its a programming language. >>> >>> one that i feel needs to stay ahead of the computing trend if it is to >>> be considered a language for large scale applications. >>> >>> 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. >>> >>> >>> On Wed, Mar 24, 2010 at 11:22 AM, Stuart Dallas wrote: Heh, you guys are funny! On 24 Mar 2010, at 08:58, Rene Veerman wrote: > On Wed, Mar 24, 2010 at 10:47 AM, Per Jessen wrote: >> Rene Veerman wrote: >> >>> popular : facebook youtube etc >>> >> >> Rene, I must be missing something here. That sort of size implies >> millions in advertising revenue, so why are we discussing how much >> performance we can squeeze out of a single box? I mean, I'm all for >> efficient use of system resources, but if I have a semi-scalable >> application, it's a lot easier just getting another box than trying to >> change the implementation language. OTOH, if my design is not >> scalable, it's probably also easier to redo it than trying to change >> the implementation language. > > again: > a) you're determining the contents of my toolset, without it affecting > you at all. the way you want it php will degrade into a toy language. And how exactly are you defining a toy language? If you want features like threading, why not switch to a language that already supports it? > b) i will aim for all possible decreases in development time and > operating costs during, not only in the grow phase but also in hard > economic times. any business person knows why. Yup, this is very good practice, but deciding that one particular tool is the only option is a fatal business decision. Use the right tool for the job! What you're trying to do here is akin to taking a hammer and whittling a screwdriver in to the handle. It's ridiculously inefficient, and imo, pretty stupid. >>> and you're still trying to impose a toolset on me. >> >> I didn't think I was - you're the one who seem to be fixed on PHP as the >> only solution, and advocating that it be enhanced to suit your >> purposes. > > no, php is just my toolset of choice, and i think it should grow with > the times and support threading and shared memory. > maybe even a few cool features to enable use-as-a-cloud. PHP is a hammer, and a bloody good one at that, but you seem to want it to be a tool shed. Accept that it's a hammer, go visit a DIY store, find the right tool for the job and get on with your life! The fact is that even if we all agree that PHP needs threading, and one or more people start working on putting it into the core, it will likely be many months before you see any sight of a working version, and even longer before you see a stable release. -Stuart -- http://stut.net/ >>> >> > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- WWW: http://plphp.dk / http://plind.dk LinkedIn: http://www.linkedin.com/in/plind Flickr: http://www.flickr.com/photos/fake51 BeWelcome: Fake51 Couchsurfing: Fake51 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
On Wed, 2010-03-24 at 11:36 +0200, Rene Veerman wrote: > these nay-sayers usually also lobby the dev-team to such extent that > these features would actually not make it into php I assume you have some proof for that accusation? This thread has almost now turned into a platform for insulting each other. Why do those few feel it necessary to do this on what could otherwise be an intelligent discussion? There are clearly two sides for this, although it does seem that the majority of this list (or at least those that have participated in the thread) are in favour of not including threading support in PHP. Rene, clearly you feel strongly about this. Why don't you ask on the internals list, as that is where you'll get the best response about whether or not it is something that is feasible (although feasibility is no indicator of whether it will be included or not) Thanks, Ash http://www.ashleysheridan.co.uk
Re: [PHP] Will PHP ever "grow up" and have threading?
On 24 March 2010 10:38, Rene Veerman wrote: > and if threading and shared memory aren't implemented, then hey, the > php dev team can build something else in that these naysayers DO need > eh... > > lol... > take a look at this -> http://nanoserv.si.kz/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Will PHP ever "grow up" and have threading?
-Original Message- From: Rene Veerman [mailto:rene7...@gmail.com] Sent: 24 March 2010 11:31 AM Subject: Re: [PHP] Will PHP ever "grow up" and have threading? thanks for opening my eyes and telling to abandon ship in time. === Bye, enjoy the swim... Maybe by the time you get back to shore you'll realise how dumb it would be if a sailor complained that his yatch didn't behave like a hovercraft, or his passenger ship couldn't carry a million barrels of oil, or his tug boat was useless at pulling a skier... Just how much (or little) development experience do you have? Cheers Arno -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
sad and pathetic? how about "revealing". i can call your sad and pathetic for: - insisting on how others should do their work. - group-attacking your opposition, hoping to intimidate by outnumbering. - ignoring all valid explanations on why someone would like their fav tool to evolve with the market. - degrading into petty insults as a way to indicate i'm probably right about the claim that led you to petty insults. i can go on, but i just dont want another political battle on my hands. i'll find out what the php dev team thinks about this issue, and base my descision on whether or not to leave php behind, on that. but you people truly are worthy of some serious IRL larting for being such assholes who think they can determine the habits of others that don't affect them. i dont usually do this, have never done it to programmers; but you're lucky we're not in the same buiding. i'd get you to try and punch me, followed by a relatively nonviolent yet very public humiliation. THATS how strongly i feel about those who determine the lifestyle of others when it doesn't even affect them. Seriously, wars have erupted over this behaviour. The kind where axes and such are used to settle the issue. On Wed, Mar 24, 2010 at 11:43 AM, Peter Lind wrote: > On 24 March 2010 10:38, Rene Veerman wrote: >> and if threading and shared memory aren't implemented, then hey, the >> php dev team can build something else in that these naysayers DO need >> eh... >> >> lol... > > Do you have any idea how sad and pathetic you come across? I'm very > sorry to say this, but really, now's the time to stop posting and step > back, take a deep breath, then focus on something else. > >> On Wed, Mar 24, 2010 at 11:36 AM, Rene Veerman wrote: >>> unless the actual php development team would like to weigh in on this >>> matter of course. >>> >>> yes, i do consider it that important. >>> >>> these nay-sayers usually also lobby the dev-team to such extent that >>> these features would actually not make it into php. >>> >>> On Wed, Mar 24, 2010 at 11:31 AM, Rene Veerman wrote: php is not a hammer, its a programming language. one that i feel needs to stay ahead of the computing trend if it is to be considered a language for large scale applications. 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. On Wed, Mar 24, 2010 at 11:22 AM, Stuart Dallas wrote: > Heh, you guys are funny! > > On 24 Mar 2010, at 08:58, Rene Veerman wrote: > >> On Wed, Mar 24, 2010 at 10:47 AM, Per Jessen wrote: >>> Rene Veerman wrote: >>> popular : facebook youtube etc >>> >>> Rene, I must be missing something here. That sort of size implies >>> millions in advertising revenue, so why are we discussing how much >>> performance we can squeeze out of a single box? I mean, I'm all for >>> efficient use of system resources, but if I have a semi-scalable >>> application, it's a lot easier just getting another box than trying to >>> change the implementation language. OTOH, if my design is not >>> scalable, it's probably also easier to redo it than trying to change >>> the implementation language. >> >> again: >> a) you're determining the contents of my toolset, without it affecting >> you at all. the way you want it php will degrade into a toy language. > > And how exactly are you defining a toy language? If you want features > like threading, why not switch to a language that already supports it? > >> b) i will aim for all possible decreases in development time and >> operating costs during, not only in the grow phase but also in hard >> economic times. any business person knows why. > > Yup, this is very good practice, but deciding that one particular tool is > the only option is a fatal business decision. Use the right tool for the > job! > > What you're trying to do here is akin to taking a hammer and whittling a > screwdriver in to the handle. It's ridiculously inefficient, and imo, > pretty stupid. > and you're still trying to impose a toolset on me. >>> >>> I didn't think I was - you're the one who seem to be fixed on PHP as the >>> only solution, and advocating that it be enhanced to suit your >>> purposes. >> >> no, php is just my toolset of choice, and i think it should grow with >> the times and support threading and shared memory. >> maybe even a few cool features to enable use-as-a-cloud. > > PHP is a hammer, and a bloody good one at that, but you seem to want it > to be a tool shed. Accept that it's a hammer, go visit a DIY store, find > the right tool for the job and get on with your life! > > The f
Re: [PHP] Will PHP ever "grow up" and have threading?
On 24 Mar 2010, at 09:36, Rene Veerman wrote: > unless the actual php development team would like to weigh in on this > matter of course. > > yes, i do consider it that important. > > these nay-sayers usually also lobby the dev-team to such extent that > these features would actually not make it into php. Frankly I don't give a crap whether threading is supported in PHP, it does everything I need it to do. If I need threading I use a language that supports it, like Python or C++. I love the way you call us nay-sayers like it's supposed to be an insult. I follow the KISS principle to the nth, and as such threading in PHP doesn't make a lot of sense to me. I'm yet to come across a problem I couldn't solve with pure PHP, but when the need arises I have no issue mixing in a little C++, Python, Ruby, or whatever, to meet my performance and scalability goals. I go to the mountain, I don't sit there complaining that the mountain ain't moving in my direction! My opinion, and that of most others who've weighed in, is that you're almost certainly looking at the problem from the wrong angle. What you haven't done is explicitly explain why you want threading to be supported. Give us a real example of why you think it should be supported and I guarantee we can come up with a way to get you what you want without requiring massive changes to the core of your chosen tool. And if we can't then you may actually convince us that threading would be a valuable feature to have available. You mentioned Facebook as an example of a popular application. Are you aware that they only recently started using their compiler in production, and that prior to that they were happily running PHP to serve their front end without ever complaining that it didn't support threading? Even now, with hip-hop, individual requests are served in a single thread, so the language itself still doesn't support threading, and I don't hear them complaining that it's costing them a fortune. Why? Because it's not. And if it was they would have added it by now. One final thing... if threading is this important to you, then I'm sure there are a number of developers who would happily add it in a fork of the core for suitable compensation. Once implemented it's possible the internals team would accept it for addition to the official version. If you really believe it has the potential to save you a butt-load of cash, the economics of paying for it should stack up. Oh, and feel free to escalate this to anyone you please. Nobody cares. Threading has been discussed before, both on this list and on internals (Google can tell you all about it), and every time it's been dismissed because the cost-benefit calculations just don't add up. > On Wed, Mar 24, 2010 at 11:31 AM, Rene Veerman wrote: >> php is not a hammer, its a programming language. >> And bravo on the metaphor appreciation failure. Love it! -Stuart -- http://stut.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
On Wed, 2010-03-24 at 11:56 +0200, Rene Veerman wrote: > sad and pathetic? how about "revealing". > > i can call your sad and pathetic for: > - insisting on how others should do their work. > - group-attacking your opposition, hoping to intimidate by outnumbering. > - ignoring all valid explanations on why someone would like their fav > tool to evolve with the market. > - degrading into petty insults as a way to indicate i'm probably right > about the claim that led you to petty insults. > > i can go on, but i just dont want another political battle on my hands. > > i'll find out what the php dev team thinks about this issue, and base > my descision on whether or not to leave php behind, on that. > > but you people truly are worthy of some serious IRL larting for being > such assholes who think they can determine the habits of others that > don't affect them. > i dont usually do this, have never done it to programmers; but you're > lucky we're not in the same buiding. > i'd get you to try and punch me, followed by a relatively nonviolent > yet very public humiliation. > THATS how strongly i feel about those who determine the lifestyle of > others when it doesn't even affect them. > > Seriously, wars have erupted over this behaviour. The kind where axes > and such are used to settle the issue. Sorry Rene, but this has just made me lose all respect for you. I shan't be too sad if you do jump ship. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [PHP] Will PHP ever "grow up" and have threading?
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"... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
Rene Veerman wrote: > unless the actual php development team would like to weigh in on this > matter of course. > > yes, i do consider it that important. > > these nay-sayers usually also lobby the dev-team to such extent that > these features would actually not make it into php. I for one will not be lobbying anyone in that regard. I've stated my opinion and argued it, that's all. -- Per Jessen, Zürich (11.2°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
Stuart Dallas wrote: > I love the way you call us nay-sayers like it's supposed to be an > insult. I follow the KISS principle to the nth, and as such threading > in PHP doesn't make a lot of sense to me. I'm yet to come across a > problem I couldn't solve with pure PHP, but when the need arises I > have no issue mixing in a little C++, Python, Ruby, or whatever, to > meet my performance and scalability goals. I go to the mountain, I > don't sit there complaining that the mountain ain't moving in my > direction! +1. -- Per Jessen, Zürich (11.2°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] another question on setting include paths for a project
On 23 March 2010 16:39, Robert P. J. Day wrote: > On Tue, 23 Mar 2010, Richard Quadling wrote: > >> However you want to identify the location, the autoloading techniques >> will allow you to only need to identify the location once. As compared >> to every file meticulously maintaining relative links to files. >> >> So, for testing, would this not work? >> >> RunTests C:\Dev\Checkouts\PROJ\trunk\tests >> RunTests C:\Installed\PROJ\V1.1\Tests >> RunTests C:\Installed\PROJ\V2.2\Tests >> RunTests C:\Installed\PROJ\V3.3\Tests >> >> sort of thing? >> >> And in RunTests, you set the location based upon the $argv[1] (using >> the autoloader technique). >> >> No env_var. No include_path. > > sure, but deep down, you're still doing what i'm claiming has to be > done at some point -- *explicitly* identifying the target location. > you're just doing it in a different way, which is fine and might be > what i'm after. > > rday > -- > > > > Robert P. J. Day Waterloo, Ontario, CANADA > > Linux Consulting, Training and Kernel Pedantry. > > Web page: http://crashcourse.ca > Twitter: http://twitter.com/rpjday > > You could of course simply look in the entire file system for a key file, but ... well ... maybe not! The thing about an env_var is that it is pretty much no different to an INI setting in this regard. By having the setting "closer" to the code using it (i.e. I see the location in the batch file used to run the testing, I see the location in the require_once() line in the main script), it is easier to see the location. An env_var or an ini setting is quite some distance away from the code and may seem "magical". What I'm not sure is how you can ever get away without explicitly declaring the location unless you always put the files in the include path. -- - Richard Quadling "Standing on the shoulders of some very clever giants!" EE : http://www.experts-exchange.com/M_248814.html EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 ZOPA : http://uk.zopa.com/member/RQuadling -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
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. -- Per Jessen, Zürich (11.4°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
On Wed, Mar 24, 2010 at 2:58 AM, Stuart Dallas wrote: > On 24 Mar 2010, at 09:36, Rene Veerman wrote: > >> unless the actual php development team would like to weigh in on this >> matter of course. >> >> yes, i do consider it that important. >> >> these nay-sayers usually also lobby the dev-team to such extent that >> these features would actually not make it into php. > > Frankly I don't give a crap whether threading is supported in PHP, it does > everything I need it to do. If I need threading I use a language that > supports it, like Python or C++. > > I love the way you call us nay-sayers like it's supposed to be an insult. I > follow the KISS principle to the nth, and as such threading in PHP doesn't > make a lot of sense to me. I'm yet to come across a problem I couldn't solve > with pure PHP, but when the need arises I have no issue mixing in a little > C++, Python, Ruby, or whatever, to meet my performance and scalability goals. > I go to the mountain, I don't sit there complaining that the mountain ain't > moving in my direction! > > My opinion, and that of most others who've weighed in, is that you're almost > certainly looking at the problem from the wrong angle. What you haven't done > is explicitly explain why you want threading to be supported. Give us a real > example of why you think it should be supported and I guarantee we can come > up with a way to get you what you want without requiring massive changes to > the core of your chosen tool. And if we can't then you may actually convince > us that threading would be a valuable feature to have available. I did give a real life example, ie e-commerce site mentioned earlier. Amazon has the similar features of my example except they have about 30 million products without (i18n). Their I18n is different web server & db & site layout which is completely different from my example. Setting I18n aside, having the same features as my example with about 30 million products to response in about 3 seconds is very good. Even though my example only have about 750,000 products, the translations for the requested languages makes it into 750,000 * 6 = 4,500,000 rows of product descriptions. This is e-commerce site not a data warehouse/mining. What would happen then if the site has over 20,000,000 product skus with similar language translations for the descriptions? 20,000,000 * 6 = ... big number to me... > > You mentioned Facebook as an example of a popular application. Are you aware > that they only recently started using their compiler in production, and that > prior to that they were happily running PHP to serve their front end without > ever complaining that it didn't support threading? Even now, with hip-hop, > individual requests are served in a single thread, so the language itself > still doesn't support threading, and I don't hear them complaining that it's > costing them a fortune. Why? Because it's not. And if it was they would have > added it by now. > > One final thing... if threading is this important to you, then I'm sure there > are a number of developers who would happily add it in a fork of the core for > suitable compensation. Once implemented it's possible the internals team > would accept it for addition to the official version. If you really believe > it has the potential to save you a butt-load of cash, the economics of paying > for it should stack up. > > Oh, and feel free to escalate this to anyone you please. Nobody cares. > Threading has been discussed before, both on this list and on internals > (Google can tell you all about it), and every time it's been dismissed > because the cost-benefit calculations just don't add up. > >> On Wed, Mar 24, 2010 at 11:31 AM, Rene Veerman wrote: >>> php is not a hammer, its a programming language. >>> > > And bravo on the metaphor appreciation failure. Love it! > > -Stuart > > -- > http://stut.net/ > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
On Wed, Mar 24, 2010 at 3:20 AM, Per Jessen 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 > > > -- > Per Jessen, Zürich (11.4°C) > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
On 24 Mar 2010, at 10:24, Tommy Pham wrote: > On Wed, Mar 24, 2010 at 2:58 AM, Stuart Dallas wrote: >> On 24 Mar 2010, at 09:36, Rene Veerman wrote: >> >>> unless the actual php development team would like to weigh in on this >>> matter of course. >>> >>> yes, i do consider it that important. >>> >>> these nay-sayers usually also lobby the dev-team to such extent that >>> these features would actually not make it into php. >> >> Frankly I don't give a crap whether threading is supported in PHP, it does >> everything I need it to do. If I need threading I use a language that >> supports it, like Python or C++. >> >> I love the way you call us nay-sayers like it's supposed to be an insult. I >> follow the KISS principle to the nth, and as such threading in PHP doesn't >> make a lot of sense to me. I'm yet to come across a problem I couldn't solve >> with pure PHP, but when the need arises I have no issue mixing in a little >> C++, Python, Ruby, or whatever, to meet my performance and scalability >> goals. I go to the mountain, I don't sit there complaining that the mountain >> ain't moving in my direction! >> >> My opinion, and that of most others who've weighed in, is that you're almost >> certainly looking at the problem from the wrong angle. What you haven't done >> is explicitly explain why you want threading to be supported. Give us a real >> example of why you think it should be supported and I guarantee we can come >> up with a way to get you what you want without requiring massive changes to >> the core of your chosen tool. And if we can't then you may actually convince >> us that threading would be a valuable feature to have available. > > I did give a real life example, ie e-commerce site mentioned earlier. > Amazon has the similar features of my example except they have about > 30 million products without (i18n). Their I18n is different web > server & db & site layout which is completely different from my > example. Setting I18n aside, having the same features as my example > with about 30 million products to response in about 3 seconds is very > good. Even though my example only have about 750,000 products, the > translations for the requested languages makes it into 750,000 * 6 = > 4,500,000 rows of product descriptions. This is e-commerce site not a > data warehouse/mining. What would happen then if the site has over > 20,000,000 product skus with similar language translations for the > descriptions? 20,000,000 * 6 = ... big number to me... How exactly will threading in PHP help with the size of the database? That makes no sense to me, please help me understand how you think threading will help in this scenario. Database size issues are tackled with clustering, caching and DB optimisation. Threading in the language accessing the DB has no advantage here. -Stuart -- http://stut.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
On Wed, Mar 24, 2010 at 12:28 PM, Tommy Pham wrote: > > 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 > Thanks for posting this before i had to. +1, +1, +1... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
On Wed, Mar 24, 2010 at 3:31 AM, Stuart Dallas wrote: > On 24 Mar 2010, at 10:24, Tommy Pham wrote: >> On Wed, Mar 24, 2010 at 2:58 AM, Stuart Dallas wrote: >>> On 24 Mar 2010, at 09:36, Rene Veerman wrote: >>> unless the actual php development team would like to weigh in on this matter of course. yes, i do consider it that important. these nay-sayers usually also lobby the dev-team to such extent that these features would actually not make it into php. >>> >>> Frankly I don't give a crap whether threading is supported in PHP, it does >>> everything I need it to do. If I need threading I use a language that >>> supports it, like Python or C++. >>> >>> I love the way you call us nay-sayers like it's supposed to be an insult. I >>> follow the KISS principle to the nth, and as such threading in PHP doesn't >>> make a lot of sense to me. I'm yet to come across a problem I couldn't >>> solve with pure PHP, but when the need arises I have no issue mixing in a >>> little C++, Python, Ruby, or whatever, to meet my performance and >>> scalability goals. I go to the mountain, I don't sit there complaining that >>> the mountain ain't moving in my direction! >>> >>> My opinion, and that of most others who've weighed in, is that you're >>> almost certainly looking at the problem from the wrong angle. What you >>> haven't done is explicitly explain why you want threading to be supported. >>> Give us a real example of why you think it should be supported and I >>> guarantee we can come up with a way to get you what you want without >>> requiring massive changes to the core of your chosen tool. And if we can't >>> then you may actually convince us that threading would be a valuable >>> feature to have available. >> >> I did give a real life example, ie e-commerce site mentioned earlier. >> Amazon has the similar features of my example except they have about >> 30 million products without (i18n). Their I18n is different web >> server & db & site layout which is completely different from my >> example. Setting I18n aside, having the same features as my example >> with about 30 million products to response in about 3 seconds is very >> good. Even though my example only have about 750,000 products, the >> translations for the requested languages makes it into 750,000 * 6 = >> 4,500,000 rows of product descriptions. This is e-commerce site not a >> data warehouse/mining. What would happen then if the site has over >> 20,000,000 product skus with similar language translations for the >> descriptions? 20,000,000 * 6 = ... big number to me... > > How exactly will threading in PHP help with the size of the database? That > makes no sense to me, please help me understand how you think threading will > help in this scenario. Looking at my example, not just the rows There are other features that require queries to a DB for simple request of a category by a shopper, instead of running those queries in series, running them in parallel would yield better response time. > Database size issues are tackled with clustering, caching and DB > optimisation. Threading in the language accessing the DB has no advantage > here. Yes, it does. As mentioned several times, instead of running the queries in series, run them in parallel. If each of the queries takes about .05 to .15 seconds. How long would it take to run them in serial? How long do you it take to run them in parallel? > > -Stuart > > -- > http://stut.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
Per Jessen wrote: Rene Veerman wrote: what you're suggesting is highly intrusive in my work-style, one that you're not affected by at all. Hmm, you're the one suggesting a change, I'm suggesting no change. How can "no change" be intrusive? in fact if you make things more difficult for me, i have less time to release opensource code of my own. Well, we can't have that, so how about we stick to "no change", thereby not making anything more difficult for you. It will remain exactly as difficult as it is today. That sounds very good to me! I'm STILL working through the warnings PHP5.3 introduced. It it improve anything. No . 5.2 still works just as well! Ican well understand why people stayed with PHP4 for so long - but I never used that myself. Perhaps we need PHPforDummies and PHPforPros ... I'll stick with the Dummies version, if I want the pro version I can go back to C++. ;) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
On 24 Mar 2010, at 10:34, Rene Veerman wrote: > On Wed, Mar 24, 2010 at 12:28 PM, Tommy Pham wrote: >> >> 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 >> > Thanks for posting this before i had to. > > +1, +1, +1... You realise, of course, that the same argument applies to using advanced features of PHP, such as threading should it ever be supported. -Stuart -- http://stut.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
I subscribe to this list to share tips on software designs. Getting and keeping your respect i'm not even interested in. I'm interested in the quality of your tips on problems i post, as tips can lead faster to products, leads to money, leads to my personal freedom and options in life. Respect cannot be used to buy bread and butter. On Wed, Mar 24, 2010 at 11:55 AM, Ashley Sheridan wrote: > On Wed, 2010-03-24 at 11:56 +0200, Rene Veerman wrote: > > sad and pathetic? how about "revealing". > > i can call your sad and pathetic for: > - insisting on how others should do their work. > - group-attacking your opposition, hoping to intimidate by outnumbering. > - ignoring all valid explanations on why someone would like their fav > tool to evolve with the market. > - degrading into petty insults as a way to indicate i'm probably right > about the claim that led you to petty insults. > > i can go on, but i just dont want another political battle on my hands. > > i'll find out what the php dev team thinks about this issue, and base > my descision on whether or not to leave php behind, on that. > > but you people truly are worthy of some serious IRL larting for being > such assholes who think they can determine the habits of others that > don't affect them. > i dont usually do this, have never done it to programmers; but you're > lucky we're not in the same buiding. > i'd get you to try and punch me, followed by a relatively nonviolent > yet very public humiliation. > THATS how strongly i feel about those who determine the lifestyle of > others when it doesn't even affect them. > > Seriously, wars have erupted over this behaviour. The kind where axes > and such are used to settle the issue. > > > > Sorry Rene, but this has just made me lose all respect for you. I shan't be > too sad if you do jump ship. > > > Thanks, > Ash > http://www.ashleysheridan.co.uk > > >
Re: [PHP] Will PHP ever "grow up" and have threading?
Tommy Pham wrote: > On Wed, Mar 24, 2010 at 2:58 AM, Stuart Dallas > wrote: >> Give us a real example of why you think it should be >> supported and I guarantee we can come up with a way to get you what >> you want without requiring massive changes to the core of your chosen >> tool. And if we can't then you may actually convince us that >> threading would be a valuable feature to have available. > > I did give a real life example, ie e-commerce site mentioned earlier. How many _concurrent_ users do you expect - which order of magnitude: 10,100,1000,1? > Amazon has the similar features of my example except they have about > 30 million products without (i18n). Their I18n is different web > server & db & site layout which is completely different from my > example. Understood. > Setting I18n aside, having the same features as my example > with about 30 million products to response in about 3 seconds is very > good. Even though my example only have about 750,000 products, the > translations for the requested languages makes it into 750,000 * 6 = > 4,500,000 rows of product descriptions. This is e-commerce site not a > data warehouse/mining. What would happen then if the site has over > 20,000,000 product skus with similar language translations for the > descriptions? 20,000,000 * 6 = ... big number to me... Thinking out loud - maybe it would make sense to have a separate database instance/machine per language? That would enable to you to start them all on one machine, but shift to another once the load increases. (not dynamically, but with time). If that's not a feasible option, maybe a mysql cluster or a very large database server? -- Per Jessen, Zürich (12.2°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
Tommy Pham wrote: > On Wed, Mar 24, 2010 at 3:20 AM, Per Jessen 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) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
On Wed, Mar 24, 2010 at 11:58 AM, Stuart Dallas wrote: > On 24 Mar 2010, at 09:36, Rene Veerman wrote: > >> unless the actual php development team would like to weigh in on this >> matter of course. >> >> yes, i do consider it that important. >> >> these nay-sayers usually also lobby the dev-team to such extent that >> these features would actually not make it into php. > > Frankly I don't give a crap whether threading is supported in PHP, it does > everything I need it to do. If I need threading I use a language that > supports it, like Python or C++. good, so we'll put you down as a "neutral"... despite what follows; > > I love the way you call us nay-sayers like it's supposed to be an insult. I > follow the KISS principle to the nth, and as such threading in PHP doesn't > make a lot of sense to me. I'm yet to come across a problem I couldn't solve > with pure PHP, but when the need arises I have no issue mixing in a little > C++, Python, Ruby, or whatever, to meet my performance and scalability goals. > I go to the mountain, I don't sit there complaining that the mountain ain't > moving in my direction! your metaphor is funny but inaccurate. therefore invalid. > > My opinion, and that of most others who've weighed in, is that you're almost > certainly looking at the problem from the wrong angle. What you haven't done > is explicitly explain why you want threading to be supported. Give us a real > example of why you think it should be supported and I guarantee we can come > up with a way to get you what you want without requiring massive changes to > the core of your chosen tool. And if we can't then you may actually convince > us that threading would be a valuable feature to have available. no sorry i don't have to. all i'll say is: realtime systems with real work to do, are often better implemented with a non-sql solution that can use threading and shared memory support. period. it's so blatantly obvious that i don't feel like i have to spell out a complete example, which YOU can then say: "ah, but there's different ways of doing that!". STOP TRYING TO DETERMINE MY HABITS AND CHOICE OF TOOLS. > You mentioned Facebook as an example of a popular application. Are you aware > that they only recently started using their compiler in production, and that > prior to that they were happily running PHP to serve their front end without > ever complaining that it didn't support threading? Even now, with hip-hop, > individual requests are served in a single thread, so the language itself > still doesn't support threading, and I don't hear them complaining that it's > costing them a fortune. Why? Because it's not. And if it was they would have > added it by now. yea, they didn't complain, they had the cash income to build the hip-hop compiler. i thank 'm for it. > > One final thing... if threading is this important to you, then I'm sure there > are a number of developers who would happily add it in a fork of the core for > suitable compensation. Once implemented it's possible the internals team > would accept it for addition to the official version. If you really believe > it has the potential to save you a butt-load of cash, the economics of paying > for it should stack up. I dont feel i need to pay for a programming language keeping up with the times. Then i'll indeed find another language to use. > >> On Wed, Mar 24, 2010 at 11:31 AM, Rene Veerman wrote: >>> php is not a hammer, its a programming language. >>> > > And bravo on the metaphor appreciation failure. Love it! > > -Stuart > > -- > http://stut.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
On Wed, 2010-03-24 at 03:38 -0700, Tommy Pham wrote: > On Wed, Mar 24, 2010 at 3:31 AM, Stuart Dallas wrote: > > On 24 Mar 2010, at 10:24, Tommy Pham wrote: > >> On Wed, Mar 24, 2010 at 2:58 AM, Stuart Dallas wrote: > >>> On 24 Mar 2010, at 09:36, Rene Veerman wrote: > >>> > unless the actual php development team would like to weigh in on this > matter of course. > > yes, i do consider it that important. > > these nay-sayers usually also lobby the dev-team to such extent that > these features would actually not make it into php. > >>> > >>> Frankly I don't give a crap whether threading is supported in PHP, it > >>> does everything I need it to do. If I need threading I use a language > >>> that supports it, like Python or C++. > >>> > >>> I love the way you call us nay-sayers like it's supposed to be an insult. > >>> I follow the KISS principle to the nth, and as such threading in PHP > >>> doesn't make a lot of sense to me. I'm yet to come across a problem I > >>> couldn't solve with pure PHP, but when the need arises I have no issue > >>> mixing in a little C++, Python, Ruby, or whatever, to meet my performance > >>> and scalability goals. I go to the mountain, I don't sit there > >>> complaining that the mountain ain't moving in my direction! > >>> > >>> My opinion, and that of most others who've weighed in, is that you're > >>> almost certainly looking at the problem from the wrong angle. What you > >>> haven't done is explicitly explain why you want threading to be > >>> supported. Give us a real example of why you think it should be supported > >>> and I guarantee we can come up with a way to get you what you want > >>> without requiring massive changes to the core of your chosen tool. And if > >>> we can't then you may actually convince us that threading would be a > >>> valuable feature to have available. > >> > >> I did give a real life example, ie e-commerce site mentioned earlier. > >> Amazon has the similar features of my example except they have about > >> 30 million products without (i18n). Their I18n is different web > >> server & db & site layout which is completely different from my > >> example. Setting I18n aside, having the same features as my example > >> with about 30 million products to response in about 3 seconds is very > >> good. Even though my example only have about 750,000 products, the > >> translations for the requested languages makes it into 750,000 * 6 = > >> 4,500,000 rows of product descriptions. This is e-commerce site not a > >> data warehouse/mining. What would happen then if the site has over > >> 20,000,000 product skus with similar language translations for the > >> descriptions? 20,000,000 * 6 = ... big number to me... > > > > How exactly will threading in PHP help with the size of the database? That > > makes no sense to me, please help me understand how you think threading > > will help in this scenario. > > Looking at my example, not just the rows There are other features > that require queries to a DB for simple request of a category by a > shopper, instead of running those queries in series, running them in > parallel would yield better response time. > > > > Database size issues are tackled with clustering, caching and DB > > optimisation. Threading in the language accessing the DB has no advantage > > here. > > Yes, it does. As mentioned several times, instead of running the > queries in series, run them in parallel. If each of the queries takes > about .05 to .15 seconds. How long would it take to run them in > serial? How long do you it take to run them in parallel? > > > > > -Stuart > > > > -- > > http://stut.net/ > The database is still a bottleneck. Now instead of processing one query at a time for a PHP script, it's processing 3 because you want them processed in parallel. Now the database is struggling with 3 times the work to complete in the same amount of time. Threading hasn't helped that much here, you've just moved the problem to an area which is already generally considered the bottleneck in most applications. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [PHP] Will PHP ever "grow up" and have threading?
On 24 Mar 2010, at 10:38, Tommy Pham wrote: > On Wed, Mar 24, 2010 at 3:31 AM, Stuart Dallas wrote: >> On 24 Mar 2010, at 10:24, Tommy Pham wrote: >>> I did give a real life example, ie e-commerce site mentioned earlier. >>> Amazon has the similar features of my example except they have about >>> 30 million products without (i18n). Their I18n is different web >>> server & db & site layout which is completely different from my >>> example. Setting I18n aside, having the same features as my example >>> with about 30 million products to response in about 3 seconds is very >>> good. Even though my example only have about 750,000 products, the >>> translations for the requested languages makes it into 750,000 * 6 = >>> 4,500,000 rows of product descriptions. This is e-commerce site not a >>> data warehouse/mining. What would happen then if the site has over >>> 20,000,000 product skus with similar language translations for the >>> descriptions? 20,000,000 * 6 = ... big number to me... >> >> How exactly will threading in PHP help with the size of the database? That >> makes no sense to me, please help me understand how you think threading will >> help in this scenario. > > Looking at my example, not just the rows There are other features > that require queries to a DB for simple request of a category by a > shopper, instead of running those queries in series, running them in > parallel would yield better response time. I can see that argument, but your comment above only stated issues of database size, and said nothing about running queries in parallel, hence my confusion. Threading would indeed allow you to run the queries in parallel, but at what cost? Personally I would focus on modifying the database structure and introducing caching to minimise the number of queries being executed. Threading would be my last resort if this was my major bottleneck. -Stuart -- http://stut.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
On Wed, Mar 24, 2010 at 3:39 AM, Stuart Dallas wrote: > > On 24 Mar 2010, at 10:34, Rene Veerman wrote: > >> On Wed, Mar 24, 2010 at 12:28 PM, Tommy Pham wrote: >>> >>> 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 >>> >> Thanks for posting this before i had to. >> >> +1, +1, +1... > > You realise, of course, that the same argument applies to using advanced > features of PHP, such as threading should it ever be supported. > > -Stuart > Thanks for supporting PHP thread. Thus, it would be a lot easier for any PHP guru to scale, make it portable, or integrate into other PHP apps without having to juggle C, Ruby, Python... and whatever else is out there... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
Tommy Pham wrote: How exactly will threading in PHP help with the size of the database? That makes no sense to me, please help me understand how you think threading will help in this scenario. Looking at my example, not just the rows There are other features that require queries to a DB for simple request of a category by a shopper, instead of running those queries in series, running them in parallel would yield better response time. Database size issues are tackled with clustering, caching and DB optimisation. Threading in the language accessing the DB has no advantage here. Yes, it does. As mentioned several times, instead of running the queries in series, run them in parallel. If each of the queries takes about .05 to .15 seconds. How long would it take to run them in serial? How long do you it take to run them in parallel? Any you have a database that can actually handle that? If the database is taking 0.1 seconds per query, and you have 10 queries, then getting the data is going to take 1 second to generate. If you want some slow query to be started, and come back for the data later, then I thought we already had that? But again this is part of the database driver anyway. No need to add threading to PHP to get the database connection to pull data in the most efficient way. And one does not write the driver in PHP? We are using C there already? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
On Wed, Mar 24, 2010 at 3:44 AM, Per Jessen wrote: > Tommy Pham wrote: > >> On Wed, Mar 24, 2010 at 3:20 AM, Per Jessen 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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
On Wed, Mar 24, 2010 at 3:40 AM, Ashley Sheridan wrote: > > On Wed, 2010-03-24 at 03:38 -0700, Tommy Pham wrote: > > On Wed, Mar 24, 2010 at 3:31 AM, Stuart Dallas wrote: > > On 24 Mar 2010, at 10:24, Tommy Pham wrote: > >> On Wed, Mar 24, 2010 at 2:58 AM, Stuart Dallas wrote: > >>> On 24 Mar 2010, at 09:36, Rene Veerman wrote: > >>> > unless the actual php development team would like to weigh in on this > matter of course. > > yes, i do consider it that important. > > these nay-sayers usually also lobby the dev-team to such extent that > these features would actually not make it into php. > >>> > >>> Frankly I don't give a crap whether threading is supported in PHP, it > >>> does everything I need it to do. If I need threading I use a language > >>> that supports it, like Python or C++. > >>> > >>> I love the way you call us nay-sayers like it's supposed to be an insult. > >>> I follow the KISS principle to the nth, and as such threading in PHP > >>> doesn't make a lot of sense to me. I'm yet to come across a problem I > >>> couldn't solve with pure PHP, but when the need arises I have no issue > >>> mixing in a little C++, Python, Ruby, or whatever, to meet my performance > >>> and scalability goals. I go to the mountain, I don't sit there > >>> complaining that the mountain ain't moving in my direction! > >>> > >>> My opinion, and that of most others who've weighed in, is that you're > >>> almost certainly looking at the problem from the wrong angle. What you > >>> haven't done is explicitly explain why you want threading to be > >>> supported. Give us a real example of why you think it should be supported > >>> and I guarantee we can come up with a way to get you what you want > >>> without requiring massive changes to the core of your chosen tool. And if > >>> we can't then you may actually convince us that threading would be a > >>> valuable feature to have available. > >> > >> I did give a real life example, ie e-commerce site mentioned earlier. > >> Amazon has the similar features of my example except they have about > >> 30 million products without (i18n). Their I18n is different web > >> server & db & site layout which is completely different from my > >> example. Setting I18n aside, having the same features as my example > >> with about 30 million products to response in about 3 seconds is very > >> good. Even though my example only have about 750,000 products, the > >> translations for the requested languages makes it into 750,000 * 6 = > >> 4,500,000 rows of product descriptions. This is e-commerce site not a > >> data warehouse/mining. What would happen then if the site has over > >> 20,000,000 product skus with similar language translations for the > >> descriptions? 20,000,000 * 6 = ... big number to me... > > > > How exactly will threading in PHP help with the size of the database? That > > makes no sense to me, please help me understand how you think threading > > will help in this scenario. > > Looking at my example, not just the rows There are other features > that require queries to a DB for simple request of a category by a > shopper, instead of running those queries in series, running them in > parallel would yield better response time. > > > > Database size issues are tackled with clustering, caching and DB > > optimisation. Threading in the language accessing the DB has no advantage > > here. > > Yes, it does. As mentioned several times, instead of running the > queries in series, run them in parallel. If each of the queries takes > about .05 to .15 seconds. How long would it take to run them in > serial? How long do you it take to run them in parallel? > > > > > -Stuart > > > > -- > > http://stut.net/ > > > The database is still a bottleneck. Now instead of processing one query at a > time for a PHP script, it's processing 3 because you want them processed in > parallel. Now the database is struggling with 3 times the work to complete in > the same amount of time. > > Threading hasn't helped that much here, you've just moved the problem to an > area which is already generally considered the bottleneck in most > applications. > > Thanks, > Ash > http://www.ashleysheridan.co.uk > > Take your current project. Look at the page where the most queries are executed. Time how long it would take to run each of those queries in your SQL GUI Tool. Add the numbers together. Now think how long it would take to run those same queries under the same conditions in parallel. ... :) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
On Wed, Mar 24, 2010 at 3:52 AM, Lester Caine wrote: > Tommy Pham wrote: >>> >>> How exactly will threading in PHP help with the size of the database? >>> That makes no sense to me, please help me understand how you think threading >>> will help in this scenario. >> >> Looking at my example, not just the rows There are other features >> that require queries to a DB for simple request of a category by a >> shopper, instead of running those queries in series, running them in >> parallel would yield better response time. >> >>> Database size issues are tackled with clustering, caching and DB >>> optimisation. Threading in the language accessing the DB has no advantage >>> here. >> >> Yes, it does. As mentioned several times, instead of running the >> queries in series, run them in parallel. If each of the queries takes >> about .05 to .15 seconds. How long would it take to run them in >> serial? How long do you it take to run them in parallel? > > Any you have a database that can actually handle that? > If the database is taking 0.1 seconds per query, and you have 10 queries, > then getting the data is going to take 1 second to generate. If you want > some slow query to be started, and come back for the data later, then I > thought we already had that? But again this is part of the database driver > anyway. No need to add threading to PHP to get the database connection to > pull data in the most efficient way. And one does not write the driver in > PHP? We are using C there already? > > -- > Lester Caine - G8HFL > - > Contact - http://lsces.co.uk/wiki/?page=contact > L.S.Caine Electronic Services - http://lsces.co.uk > EnquirySolve - http://enquirysolve.com/ > Model Engineers Digital Workshop - http://medw.co.uk// > Firebird - http://www.firebirdsql.org/index.php > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > Exactly my point. 10 queries taking .1 second each running in serial is 1 second total. How long would it take to run all those same queries simultaneously??? What's so difficult about the concept of serial vs parallel? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
On 24 March 2010 11:53, Tommy Pham wrote: > On Wed, Mar 24, 2010 at 3:44 AM, Per Jessen wrote: >> Tommy Pham wrote: >> >>> On Wed, Mar 24, 2010 at 3:20 AM, Per Jessen 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 Except, you already introduced complexity into the problem. You see, working with threads is another requirement, whether it be done in PHP or not. Hence, hiring the right guy is independent of whether you have threads in PHP or not - your problem is no less nor no more complex whether you do threading inside or outside PHP. You just assume that adding thread support to PHP will solve the problem, but there's no actual basis to believe this. > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- WWW: http://plphp.dk / http://plind.dk LinkedIn: http://www.linkedin.com/in/plind Flickr: http://www.flickr.com/photos/fake51 BeWelcome: Fake51 Couchsurfing: Fake51 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
On 24 March 2010 12:04, Tommy Pham wrote: > On Wed, Mar 24, 2010 at 3:52 AM, Lester Caine wrote: >> Tommy Pham wrote: How exactly will threading in PHP help with the size of the database? That makes no sense to me, please help me understand how you think threading will help in this scenario. >>> >>> Looking at my example, not just the rows There are other features >>> that require queries to a DB for simple request of a category by a >>> shopper, instead of running those queries in series, running them in >>> parallel would yield better response time. >>> Database size issues are tackled with clustering, caching and DB optimisation. Threading in the language accessing the DB has no advantage here. >>> >>> Yes, it does. As mentioned several times, instead of running the >>> queries in series, run them in parallel. If each of the queries takes >>> about .05 to .15 seconds. How long would it take to run them in >>> serial? How long do you it take to run them in parallel? >> >> Any you have a database that can actually handle that? >> If the database is taking 0.1 seconds per query, and you have 10 queries, >> then getting the data is going to take 1 second to generate. If you want >> some slow query to be started, and come back for the data later, then I >> thought we already had that? But again this is part of the database driver >> anyway. No need to add threading to PHP to get the database connection to >> pull data in the most efficient way. And one does not write the driver in >> PHP? We are using C there already? >> >> -- >> Lester Caine - G8HFL >> - >> Contact - http://lsces.co.uk/wiki/?page=contact >> L.S.Caine Electronic Services - http://lsces.co.uk >> EnquirySolve - http://enquirysolve.com/ >> Model Engineers Digital Workshop - http://medw.co.uk// >> Firebird - http://www.firebirdsql.org/index.php >> >> -- >> PHP General Mailing List (http://www.php.net/) >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> > > Exactly my point. 10 queries taking .1 second each running in serial > is 1 second total. How long would it take to run all those same > queries simultaneously??? What's so difficult about the concept of > serial vs parallel? Hmm, just wondering, but how long do you think it will take your high-traffic site to buckle under the load of the database queries you want to execute when now you want all of them to execute at the same time? Going with the "10 queries of .1 second each" ... how far do you think you can scale that before you overload your database server? I'm just wondering here, I could be completely off the bat. > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- WWW: http://plphp.dk / http://plind.dk LinkedIn: http://www.linkedin.com/in/plind Flickr: http://www.flickr.com/photos/fake51 BeWelcome: Fake51 Couchsurfing: Fake51 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
On 24 Mar 2010, at 10:46, Rene Veerman wrote: > On Wed, Mar 24, 2010 at 11:58 AM, Stuart Dallas wrote: >> On 24 Mar 2010, at 09:36, Rene Veerman wrote: >> >>> unless the actual php development team would like to weigh in on this >>> matter of course. >>> >>> yes, i do consider it that important. >>> >>> these nay-sayers usually also lobby the dev-team to such extent that >>> these features would actually not make it into php. >> >> Frankly I don't give a crap whether threading is supported in PHP, it does >> everything I need it to do. If I need threading I use a language that >> supports it, like Python or C++. > > good, so we'll put you down as a "neutral"... despite what follows; I'm not neutral, I just ultimately don't care either way. I'll deal with whatever happens rather than trying to control everything. >> I love the way you call us nay-sayers like it's supposed to be an insult. I >> follow the KISS principle to the nth, and as such threading in PHP doesn't >> make a lot of sense to me. I'm yet to come across a problem I couldn't solve >> with pure PHP, but when the need arises I have no issue mixing in a little >> C++, Python, Ruby, or whatever, to meet my performance and scalability >> goals. I go to the mountain, I don't sit there complaining that the mountain >> ain't moving in my direction! > > your metaphor is funny but inaccurate. therefore invalid. You say it's inaccurate, therefore invalid, but offer no argument as to why. You want the tools to change to fit the way you want to work, rather than adapting to the tools you have available. I stand by my metaphor, both the humour and the message. >> My opinion, and that of most others who've weighed in, is that you're almost >> certainly looking at the problem from the wrong angle. What you haven't done >> is explicitly explain why you want threading to be supported. Give us a real >> example of why you think it should be supported and I guarantee we can come >> up with a way to get you what you want without requiring massive changes to >> the core of your chosen tool. And if we can't then you may actually convince >> us that threading would be a valuable feature to have available. > > > no sorry i don't have to. all i'll say is: realtime systems with real Indeed you don't have to, I never said you did. > work to do, are often better implemented with a non-sql solution that > can use threading and shared memory support. period. I completely agree, but I wouldn't go near PHP for a realtime system in a million years. It's the wrong tool for the job. > it's so blatantly obvious that i don't feel like i have to spell out a > complete example, which YOU can then say: "ah, but there's different > ways of doing that!". > STOP TRYING TO DETERMINE MY HABITS AND CHOICE OF TOOLS. I'm not. You seem to think we all care whether you use PHP or not. I don't, and I'm pretty sure nobody else does either. I'm not trying to tell you what to use, I'm simply pointing out that you appear to be fixed on PHP for some reason and I don't understand why. It makes no sense to me, but frankly I don't care. >> You mentioned Facebook as an example of a popular application. Are you aware >> that they only recently started using their compiler in production, and that >> prior to that they were happily running PHP to serve their front end without >> ever complaining that it didn't support threading? Even now, with hip-hop, >> individual requests are served in a single thread, so the language itself >> still doesn't support threading, and I don't hear them complaining that it's >> costing them a fortune. Why? Because it's not. And if it was they would have >> added it by now. > > yea, they didn't complain, they had the cash income to build the > hip-hop compiler. > i thank 'm for it. Way to skip over my point. Facebook is pretty much guaranteed to be a bigger site in terms of data size and concurrent users than anything you or I are ever going to be involved in, and yet they don't think threading in PHP is important. That was my point. >> One final thing... if threading is this important to you, then I'm sure >> there are a number of developers who would happily add it in a fork of the >> core for suitable compensation. Once implemented it's possible the internals >> team would accept it for addition to the official version. If you really >> believe it has the potential to save you a butt-load of cash, the economics >> of paying for it should stack up. > > I dont feel i need to pay for a programming language keeping up with the > times. > Then i'll indeed find another language to use. I find it curious and amusing that you think the lack of threading support means PHP is somehow living in the dark ages. But yeah, complaining that the FREE tool you've CHOSEN to use doesn't support the feature YOU want... yeah, that's the way to go. -Stuart -- http://stut.net/ -- PHP General Mailing List (http://www.php.net/)
Re: [PHP] Will PHP ever "grow up" and have threading?
yea right.. i really want to keep my code base in 1 language, because that simplifies everything later on imo. you people, who are against the evolotion of php towards cloud computing, would force me to do mixed-languages projects or even rewrite large sections of my codebase if as i want, i keep my codebase in 1 language. maybe now you understand why i'm so pissed off with you know-it-alls. On Wed, Mar 24, 2010 at 1:04 PM, Peter Lind wrote: > On 24 March 2010 11:53, Tommy Pham wrote: >> On Wed, Mar 24, 2010 at 3:44 AM, Per Jessen wrote: >>> Tommy Pham wrote: >>> On Wed, Mar 24, 2010 at 3:20 AM, Per Jessen 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 > > Except, you already introduced complexity into the problem. You see, > working with threads is another requirement, whether it be done in PHP > or not. Hence, hiring the right guy is independent of whether you have > threads in PHP or not - your problem is no less nor no more complex > whether you do threading inside or outside PHP. You just assume that > adding thread support to PHP will solve the problem, but there's no > actual basis to believe this. > > >> -- >> PHP General Mailing List (http://www.php.net/) >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> > > > > -- > > WWW: http://plphp.dk / http://plind.dk > LinkedIn: http://www.linkedin.com/in/plind > Flickr: http://www.flickr.com/photos/fake51 > BeWelcome: Fake51 > Couchsurfing: Fake51 > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
On Wed, Mar 24, 2010 at 4:09 AM, Peter Lind wrote: > On 24 March 2010 12:04, Tommy Pham wrote: >> On Wed, Mar 24, 2010 at 3:52 AM, Lester Caine wrote: >>> Tommy Pham wrote: > > How exactly will threading in PHP help with the size of the database? > That makes no sense to me, please help me understand how you think > threading > will help in this scenario. Looking at my example, not just the rows There are other features that require queries to a DB for simple request of a category by a shopper, instead of running those queries in series, running them in parallel would yield better response time. > Database size issues are tackled with clustering, caching and DB > optimisation. Threading in the language accessing the DB has no advantage > here. Yes, it does. As mentioned several times, instead of running the queries in series, run them in parallel. If each of the queries takes about .05 to .15 seconds. How long would it take to run them in serial? How long do you it take to run them in parallel? >>> >>> Any you have a database that can actually handle that? >>> If the database is taking 0.1 seconds per query, and you have 10 queries, >>> then getting the data is going to take 1 second to generate. If you want >>> some slow query to be started, and come back for the data later, then I >>> thought we already had that? But again this is part of the database driver >>> anyway. No need to add threading to PHP to get the database connection to >>> pull data in the most efficient way. And one does not write the driver in >>> PHP? We are using C there already? >>> >>> -- >>> Lester Caine - G8HFL >>> - >>> Contact - http://lsces.co.uk/wiki/?page=contact >>> L.S.Caine Electronic Services - http://lsces.co.uk >>> EnquirySolve - http://enquirysolve.com/ >>> Model Engineers Digital Workshop - http://medw.co.uk// >>> Firebird - http://www.firebirdsql.org/index.php >>> >>> -- >>> PHP General Mailing List (http://www.php.net/) >>> To unsubscribe, visit: http://www.php.net/unsub.php >>> >>> >> >> Exactly my point. 10 queries taking .1 second each running in serial >> is 1 second total. How long would it take to run all those same >> queries simultaneously??? What's so difficult about the concept of >> serial vs parallel? > > Hmm, just wondering, but how long do you think it will take your > high-traffic site to buckle under the load of the database queries you > want to execute when now you want all of them to execute at the same > time? Going with the "10 queries of .1 second each" ... how far do you > think you can scale that before you overload your database server? I'm > just wondering here, I could be completely off the bat. IIRC, one of opponents of PHP thread mention load balancer/cluster or another opponent mention 'throw money into the hardware problem' > >> -- >> PHP General Mailing List (http://www.php.net/) >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> > > > > -- > > WWW: http://plphp.dk / http://plind.dk > LinkedIn: http://www.linkedin.com/in/plind > Flickr: http://www.flickr.com/photos/fake51 > BeWelcome: Fake51 > Couchsurfing: Fake51 > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
On 24 Mar 2010, at 10:48, Tommy Pham wrote: > On Wed, Mar 24, 2010 at 3:39 AM, Stuart Dallas wrote: >> >> On 24 Mar 2010, at 10:34, Rene Veerman wrote: >> >>> On Wed, Mar 24, 2010 at 12:28 PM, Tommy Pham wrote: 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 >>> Thanks for posting this before i had to. >>> >>> +1, +1, +1... >> >> You realise, of course, that the same argument applies to using advanced >> features of PHP, such as threading should it ever be supported. >> >> -Stuart >> > > Thanks for supporting PHP thread. Thus, it would be a lot easier for > any PHP guru to scale, make it portable, or integrate into other PHP > apps without having to juggle C, Ruby, Python... and whatever else is > out there... I don't believe I did support PHP threading. My point was that using advanced features like threading will limit your employee choices in exactly the same way as having a multi-language environment. -Stuart -- http://stut.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
Stuart Dallas wrote: >>> I love the way you call us nay-sayers like it's supposed to be an >>> insult. I follow the KISS principle to the nth, and as such >>> threading in PHP doesn't make a lot of sense to me. I'm yet to come >>> across a problem I couldn't solve with pure PHP, but when the need >>> arises I have no issue mixing in a little C++, Python, Ruby, or >>> whatever, to meet my performance and scalability goals. I go to the >>> mountain, I don't sit there complaining that the mountain ain't >>> moving in my direction! >> >> your metaphor is funny but inaccurate. therefore invalid. > > You say it's inaccurate, therefore invalid, but offer no argument as > to why. You want the tools to change to fit the way you want to work, > rather than adapting to the tools you have available. I stand by my > metaphor, both the humour and the message. FWIW, I thought your metaphor was spot on. Programming is a craft, craftsmen use tools, whether hammers or PHP. >> work to do, are often better implemented with a non-sql solution that >> can use threading and shared memory support. period. > > I completely agree, but I wouldn't go near PHP for a realtime system > in a million years. It's the wrong tool for the job. +1. -- Per Jessen, Zürich (13.2°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
Peter Lind wrote: Any you have a database that can actually handle that? If the database is taking 0.1 seconds per query, and you have 10 queries, then getting the data is going to take 1 second to generate. If you want some slow query to be started, and come back for the data later, then I thought we already had that? But again this is part of the database driver anyway. No need to add threading to PHP to get the database connection to pull data in the most efficient way. And one does not write the driver in PHP? We are using C there already? Exactly my point. 10 queries taking .1 second each running in serial is 1 second total. How long would it take to run all those same queries simultaneously??? What's so difficult about the concept of serial vs parallel? Hmm, just wondering, but how long do you think it will take your high-traffic site to buckle under the load of the database queries you want to execute when now you want all of them to execute at the same time? Going with the "10 queries of .1 second each" ... how far do you think you can scale that before you overload your database server? I'm just wondering here, I could be completely off the bat. No you are not off bat. That was the point I was trying to make but not very well. A database connection will normally handle one query at a time, so they have to be serial anyway unles you can create multiple connections. What I was asking Tommy was how he expected the database to handle 10 queries in parallel. Yes ten cores could possibly parallel up the work, but on the whole, the database end is going to serialise a lot of that work, so what is the real gain? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
On Wed, Mar 24, 2010 at 1:13 PM, Stuart Dallas > I find it curious and amusing that you think the lack of threading support > means PHP is somehow living in the dark ages. But yeah, complaining that the > FREE tool you've CHOSEN to use doesn't support the feature YOU want... yeah, > that's the way to go. > a) i'm not the only 1 who wants that feature, or would appreciate it when it's made available. b) to me it's a matter of keeping php attuned with the market trends. this thread forces me to reconsider my choice of language, because i do code to maybe get as big as facebook one day. it really really helps to have my codebase in a simple language like php, and yet be able to build blackboxes in that language that do threading and use shared memory.. imo, it saves significant time (money) and headaches (risk) when growing from 1 server to thousands of servers. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
Tommy Pham wrote: > On Wed, Mar 24, 2010 at 3:44 AM, Per Jessen wrote: >> Tommy Pham wrote: >> >>> On Wed, Mar 24, 2010 at 3:20 AM, Per Jessen >>> 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) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
how about having a threaded php server query 10 mysql servers at the same time? 10 results in .1 seconds! and dont start with 'apache will handle that', there are cases where you're best off doing it in php, so you can gather/calculate relations from the data off 10 different servers. On Wed, Mar 24, 2010 at 1:09 PM, Peter Lind wrote: > On 24 March 2010 12:04, Tommy Pham wrote: >> On Wed, Mar 24, 2010 at 3:52 AM, Lester Caine wrote: >>> Tommy Pham wrote: > > How exactly will threading in PHP help with the size of the database? > That makes no sense to me, please help me understand how you think > threading > will help in this scenario. Looking at my example, not just the rows There are other features that require queries to a DB for simple request of a category by a shopper, instead of running those queries in series, running them in parallel would yield better response time. > Database size issues are tackled with clustering, caching and DB > optimisation. Threading in the language accessing the DB has no advantage > here. Yes, it does. As mentioned several times, instead of running the queries in series, run them in parallel. If each of the queries takes about .05 to .15 seconds. How long would it take to run them in serial? How long do you it take to run them in parallel? >>> >>> Any you have a database that can actually handle that? >>> If the database is taking 0.1 seconds per query, and you have 10 queries, >>> then getting the data is going to take 1 second to generate. If you want >>> some slow query to be started, and come back for the data later, then I >>> thought we already had that? But again this is part of the database driver >>> anyway. No need to add threading to PHP to get the database connection to >>> pull data in the most efficient way. And one does not write the driver in >>> PHP? We are using C there already? >>> >>> -- >>> Lester Caine - G8HFL >>> - >>> Contact - http://lsces.co.uk/wiki/?page=contact >>> L.S.Caine Electronic Services - http://lsces.co.uk >>> EnquirySolve - http://enquirysolve.com/ >>> Model Engineers Digital Workshop - http://medw.co.uk// >>> Firebird - http://www.firebirdsql.org/index.php >>> >>> -- >>> PHP General Mailing List (http://www.php.net/) >>> To unsubscribe, visit: http://www.php.net/unsub.php >>> >>> >> >> Exactly my point. 10 queries taking .1 second each running in serial >> is 1 second total. How long would it take to run all those same >> queries simultaneously??? What's so difficult about the concept of >> serial vs parallel? > > Hmm, just wondering, but how long do you think it will take your > high-traffic site to buckle under the load of the database queries you > want to execute when now you want all of them to execute at the same > time? Going with the "10 queries of .1 second each" ... how far do you > think you can scale that before you overload your database server? I'm > just wondering here, I could be completely off the bat. > >> -- >> PHP General Mailing List (http://www.php.net/) >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> > > > > -- > > WWW: http://plphp.dk / http://plind.dk > LinkedIn: http://www.linkedin.com/in/plind > Flickr: http://www.flickr.com/photos/fake51 > BeWelcome: Fake51 > Couchsurfing: Fake51 > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
Rene Veerman wrote: > i really want to keep my code base in 1 language, because that > simplifies everything later on imo. Yes, generally speaking that's a good idea. Not always the optimal choice when you weigh up the requirements and the available skillsets, but nonetheless. -- Per Jessen, Zürich (13.4°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
Rene Veerman wrote: > b) to me it's a matter of keeping php attuned with the market trends. > this thread forces me to reconsider my choice of language, because i > do code to maybe get as big as facebook one day. Nothing wrong with that, nothing at all. The keyword is scalability, and that is measured by how much performance you gain by adding another box. You appear to be far more concerned with how much you can get out of a single, small box, and that's the wrong focus, IMHO. -- Per Jessen, Zürich (13.7°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
On Wed, Mar 24, 2010 at 12:27, Rene Veerman wrote: > On Wed, Mar 24, 2010 at 1:13 PM, Stuart Dallas >> I find it curious and amusing that you think the lack of threading support >> means PHP is somehow living in the dark ages. But yeah, complaining that the >> FREE tool you've CHOSEN to use doesn't support the feature YOU want... yeah, >> that's the way to go. >> > > a) i'm not the only 1 who wants that feature, or would appreciate it > when it's made available. > > b) to me it's a matter of keeping php attuned with the market trends. > this thread forces me to reconsider my choice of language, because i > do code to maybe get as big as facebook one day. > it really really helps to have my codebase in a simple language like > php, and yet be able to build blackboxes in that language that do > threading and use shared memory.. > imo, it saves significant time (money) and headaches (risk) when > growing from 1 server to thousands of servers. If you believe you have the chance of becoming as big as Facebook and that you would save loads of money by having PHP support multi-threading, what's preventing you from hiring people to add that to PHP? You can complain all you want, but even with the most compelling reasons in the world it will not be done if there is not enough manpower to do it. I'm not even sure why you are complaining about this on the general list. Why don't you write an RFC and send it to internals for discussion? I'm sure someone would be happy to give you write access to the rfc namespace on the wiki if you sign up for an account there. Seeing as it's apparently so crucial to the operation of your business, I don't think it's unreasonable that you commit some resources to it. I don't think anyone is *against* that PHP supports multi-threading. I think people are against having multi-threading if it will stall other development in the PHP core. It's not like you can implement it just like that. There is just a limit on how much that can be done with the resources that are available. -- Daniel Egeberg -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
well i have this very strong gut feeling that at least some php apps stand to gain so much efficiency per box with threading and shared memory that they'll save not only their operators a lot of headaches, but also significant money and energy. that in turn benefits those outside the company using php. On Wed, Mar 24, 2010 at 1:42 PM, Per Jessen wrote: > Rene Veerman wrote: > >> b) to me it's a matter of keeping php attuned with the market trends. >> this thread forces me to reconsider my choice of language, because i >> do code to maybe get as big as facebook one day. > > Nothing wrong with that, nothing at all. The keyword is scalability, > and that is measured by how much performance you gain by adding another > box. You appear to be far more concerned with how much you can get out > of a single, small box, and that's the wrong focus, IMHO. > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
Rene Veerman wrote: > how about having a threaded php server query 10 mysql servers at the > same time? 10 results in .1 seconds! > How about using mysqlnd? AFAIK, it has support for asynchronous queries. -- Per Jessen, Zürich (14.2°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
again; i have neither the expertise ready, nor the time nor the money atm, to implement it myself. i'm hoping the php-dev team will agree with me that scalability of php driven apps should be put on the agenda. threading and shared memory are only a part of that discussion.. i'm opening a new thread to discuss this wider issue. On Wed, Mar 24, 2010 at 1:44 PM, Daniel Egeberg wrote: > On Wed, Mar 24, 2010 at 12:27, Rene Veerman wrote: >> On Wed, Mar 24, 2010 at 1:13 PM, Stuart Dallas >>> I find it curious and amusing that you think the lack of threading support >>> means PHP is somehow living in the dark ages. But yeah, complaining that >>> the FREE tool you've CHOSEN to use doesn't support the feature YOU want... >>> yeah, that's the way to go. >>> >> >> a) i'm not the only 1 who wants that feature, or would appreciate it >> when it's made available. >> >> b) to me it's a matter of keeping php attuned with the market trends. >> this thread forces me to reconsider my choice of language, because i >> do code to maybe get as big as facebook one day. >> it really really helps to have my codebase in a simple language like >> php, and yet be able to build blackboxes in that language that do >> threading and use shared memory.. >> imo, it saves significant time (money) and headaches (risk) when >> growing from 1 server to thousands of servers. > > If you believe you have the chance of becoming as big as Facebook and > that you would save loads of money by having PHP support > multi-threading, what's preventing you from hiring people to add that > to PHP? You can complain all you want, but even with the most > compelling reasons in the world it will not be done if there is not > enough manpower to do it. > > I'm not even sure why you are complaining about this on the general > list. Why don't you write an RFC and send it to internals for > discussion? I'm sure someone would be happy to give you write access > to the rfc namespace on the wiki if you sign up for an account there. > > Seeing as it's apparently so crucial to the operation of your > business, I don't think it's unreasonable that you commit some > resources to it. I don't think anyone is *against* that PHP supports > multi-threading. I think people are against having multi-threading if > it will stall other development in the PHP core. It's not like you can > implement it just like that. There is just a limit on how much that > can be done with the resources that are available. > > -- > Daniel Egeberg > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] how to do cloud computing with php
Hi.. As a way to take a few steps back from the kinda heated "when will php grow up and support threading" thread, i'm requesting you people list how you scale from 1 server to many servers; what's called cloud computing. In particular, i'm interested in how to set up an application that deals with great amounts of input from many 3rd-party servers, and say a million concurrent viewers who need html calculated from those input streams. So this goes beyond 1 mysql server, and beyond 1 php server. Let's hear it, coz quite frankly i have my doubts about php's ability to scale to cloud computing. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] how to do cloud computing with php
On 03/24/2010 05:25 PM, Rene Veerman wrote: Hi.. As a way to take a few steps back from the kinda heated "when will php grow up and support threading" thread, i'm requesting you people list how you scale from 1 server to many servers; what's called cloud computing. In particular, i'm interested in how to set up an application that deals with great amounts of input from many 3rd-party servers, and say a million concurrent viewers who need html calculated from those input streams. So this goes beyond 1 mysql server, and beyond 1 php server. Let's hear it, coz quite frankly i have my doubts about php's ability to scale to cloud computing. Isn't multiple php processing servers possible using FastCGI protocol ? -- Nilesh Govindarajan Site & Server Administrator www.itech7.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] how to do cloud computing with php
I have already answer that on the other thread, but anyway http://nanoserv.si.kz/ , or use the web webserver made with it http://nanoweb.si.kz/. And thinking about your 'requirements', avoid mysql from that equation. There are other faster alternatives in the SQL world. Or even better think about an alternative like mongodb that scale really well. 2010/3/24 Rene Veerman : > Hi.. > > As a way to take a few steps back from the kinda heated "when will php > grow up and support threading" thread, i'm requesting you people list > how you scale from 1 server to many servers; what's called cloud > computing. > > In particular, i'm interested in how to set up an application that > deals with great amounts of input from many 3rd-party servers, and say > a million concurrent viewers who need html calculated from those input > streams. > > So this goes beyond 1 mysql server, and beyond 1 php server. > > Let's hear it, coz quite frankly i have my doubts about php's ability > to scale to cloud computing. > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Properly handling multiple constructors.
Hi. I have a scenario where I would _like_ to have multiple constructors for a class. Each constructor has a greater number of parameters than the previous one. e.g. http://www.experts-exchange.com/M_248814.html EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 ZOPA : http://uk.zopa.com/member/RQuadling -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
On 24 March 2010 12:14, Tommy Pham wrote: > On Wed, Mar 24, 2010 at 4:09 AM, Peter Lind wrote: >> On 24 March 2010 12:04, Tommy Pham wrote: >>> On Wed, Mar 24, 2010 at 3:52 AM, Lester Caine wrote: Tommy Pham wrote: >> >> How exactly will threading in PHP help with the size of the database? >> That makes no sense to me, please help me understand how you think >> threading >> will help in this scenario. > > Looking at my example, not just the rows There are other features > that require queries to a DB for simple request of a category by a > shopper, instead of running those queries in series, running them in > parallel would yield better response time. > >> Database size issues are tackled with clustering, caching and DB >> optimisation. Threading in the language accessing the DB has no advantage >> here. > > Yes, it does. As mentioned several times, instead of running the > queries in series, run them in parallel. If each of the queries takes > about .05 to .15 seconds. How long would it take to run them in > serial? How long do you it take to run them in parallel? Any you have a database that can actually handle that? If the database is taking 0.1 seconds per query, and you have 10 queries, then getting the data is going to take 1 second to generate. If you want some slow query to be started, and come back for the data later, then I thought we already had that? But again this is part of the database driver anyway. No need to add threading to PHP to get the database connection to pull data in the most efficient way. And one does not write the driver in PHP? We are using C there already? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php >>> >>> Exactly my point. 10 queries taking .1 second each running in serial >>> is 1 second total. How long would it take to run all those same >>> queries simultaneously??? What's so difficult about the concept of >>> serial vs parallel? >> >> Hmm, just wondering, but how long do you think it will take your >> high-traffic site to buckle under the load of the database queries you >> want to execute when now you want all of them to execute at the same >> time? Going with the "10 queries of .1 second each" ... how far do you >> think you can scale that before you overload your database server? I'm >> just wondering here, I could be completely off the bat. > > IIRC, one of opponents of PHP thread mention load balancer/cluster or > another opponent mention 'throw money into the hardware problem' Yes. If you can accept that solution for this problem, why not for the other problem? Please keep in mind that I'm not for or against threads in PHP. I think they can solve some problems and I think they'll create a host of others - currently I have no idea if the benefits would outweigh the costs. I just have a huge problem understanding why alternative solutions to problems are thrown out with "No! That won't work" when they haven't been shown to be problematic. So far, we've seen no examples of situations where PHP would be the best choice of language and would need threads to solve the problem at hand. Assuming that you have a right to use a threaded version of PHP amounts to walking into your favourite tool-store and demanding that you get a hammer that doubles as a phone. And when none are available, you start yelling at other customers for suggesting the use of a phone and hammer in combination. >> >>> -- >>> PHP General Mailing List (http://www.php.net/) >>> To unsubscribe, visit: http://www.php.net/unsub.php >>> >>> >> >> >> >> -- >> >> WWW: http://plphp.dk / http://plind.dk >> LinkedIn: http://www.linkedin.com/in/plind >> Flickr: http://www.flickr.com/photos/fake51 >> BeWelcome: Fake51 >> Couchsurfing: Fake51 >> >> > -- WWW: http://plphp.dk / http://plind.dk LinkedIn: http://www.linkedin.com/in/plind Flickr: http://www.flickr.com/photos/fake51 BeWelcome: Fake51 Couchsurfing: Fake51 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] how to do cloud computing with php
Rene Veerman wrote: > Hi.. > > As a way to take a few steps back from the kinda heated "when will php > grow up and support threading" thread, i'm requesting you people list > how you scale from 1 server to many servers; what's called cloud > computing. Scaling to N boxes is first a matter of distributing the load. Personally I like to use LVS for that - if you're aiming really high, maybe supersparrow. Second you will have to look at how to distribute the data - usually the answer is segmentation or replication, with a few different twists. To reduce network traffic and response times, cacheing comes into it in many places. -- Per Jessen, Zürich (14.1°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] how to do cloud computing with php
On 03/24/2010 05:31 PM, jose javier parra sanchez wrote: I have already answer that on the other thread, but anyway http://nanoserv.si.kz/ , or use the web webserver made with it http://nanoweb.si.kz/. And thinking about your 'requirements', avoid mysql from that equation. There are other faster alternatives in the SQL world. Or even better think about an alternative like mongodb that scale really well. 2010/3/24 Rene Veerman: Hi.. As a way to take a few steps back from the kinda heated "when will php grow up and support threading" thread, i'm requesting you people list how you scale from 1 server to many servers; what's called cloud computing. In particular, i'm interested in how to set up an application that deals with great amounts of input from many 3rd-party servers, and say a million concurrent viewers who need html calculated from those input streams. So this goes beyond 1 mysql server, and beyond 1 php server. Let's hear it, coz quite frankly i have my doubts about php's ability to scale to cloud computing. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php Even recent PostgreSQL offer much more better speed and performance as compared to MySQL. No I'm not joking about it or telling this just by reading articles on the web. Its my experience. I moved my drupal site from MySQL to PostgreSQL (all latest) to see a huge performance boost. :) -- Nilesh Govindarajan Site & Server Administrator www.itech7.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Properly handling multiple constructors.
Hmmm, that looks to me like you're trying to solve a problem in PHP
with a c/c++c/# overloading solution. I'd give the builder pattern a
try instead: http://en.wikipedia.org/wiki/Builder_pattern
On 24 March 2010 13:01, Richard Quadling wrote:
> Hi.
>
> I have a scenario where I would _like_ to have multiple constructors
> for a class.
>
> Each constructor has a greater number of parameters than the previous one.
>
> e.g.
>
> class myClass {
> __construct(string $Key) // use key to get the complex details.
> __construct(string $Part1, string $Part2, string $Part3) //
> Alternative route to the complex details.
> __construct(array $Complex) // All the details
> }
>
> Essentially, SimpleKey is a key to a set of predefined rules. Part1, 2
> and 3 are the main details and well documented defaults for the rest
> of the rules. Complex is all the rules.
>
> Each constructor will end up with all the parts being known ($Key,
> $Part1, $Part2, $Part3, $Complex).
>
> But, PHP doesn't support multiple constructors.
>
> Initially I thought about this ...
>
> __construct($Key_Part1_Complex, $Part2=Null, $Part3=Null)
>
> But then documenting the first param as being 1 of three different
> meanings is pretty much a no go.
>
> So I'm looking for a clean and easily understood way to provide this.
>
> I won't be the only user of the code and not everyone has the same
> knowledge level, hence a mechanism that is easily documentable.
>
> I think I may need a factory with multiple methods (FactoryKey,
> FactoryPart1To3, FactoryComplex). Make the factory a static/singleton.
> All these methods eventually call the real class with the complex
> rule.
>
> Is that obvious enough?
>
> Regards,
>
> Richard.
>
>
> --
> -
> Richard Quadling
> "Standing on the shoulders of some very clever giants!"
> EE : http://www.experts-exchange.com/M_248814.html
> EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp
> Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
> ZOPA : http://uk.zopa.com/member/RQuadling
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
WWW: http://plphp.dk / http://plind.dk
LinkedIn: http://www.linkedin.com/in/plind
Flickr: http://www.flickr.com/photos/fake51
BeWelcome: Fake51
Couchsurfing: Fake51
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Properly handling multiple constructors.
On 03/24/2010 05:31 PM, Richard Quadling wrote:
Hi.
I have a scenario where I would _like_ to have multiple constructors
for a class.
Each constructor has a greater number of parameters than the previous one.
e.g.
Don't give specify any parameters in the function declaration.
Use helper functions inside the class, and decide at the constructor
which helper to call using func_get_arg() and func_get_args()
You can get the no. of arguments using count(func_get_args())
and then using swtich statement call the relevant helper function using
call_user_func_array with parameters.
A sample:
public function __construct() {
switch(count(func_get_args())) {
case 1:
call_user_func_array(array($this, '_helper1'), func_get_args());
break;
// and so on
}
}
--
Nilesh Govindarajan
Site & Server Administrator
www.itech7.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Properly handling multiple constructors.
On 03/24/2010 05:38 PM, Nilesh Govindarajan wrote:
On 03/24/2010 05:31 PM, Richard Quadling wrote:
Hi.
I have a scenario where I would _like_ to have multiple constructors
for a class.
Each constructor has a greater number of parameters than the previous
one.
e.g.
Don't give specify any parameters in the function declaration.
Use helper functions inside the class, and decide at the constructor
which helper to call using func_get_arg() and func_get_args()
You can get the no. of arguments using count(func_get_args())
and then using swtich statement call the relevant helper function using
call_user_func_array with parameters.
A sample:
public function __construct() {
switch(count(func_get_args())) {
case 1:
call_user_func_array(array($this, '_helper1'), func_get_args());
break;
// and so on
}
}
Oops, I missed func_num_args().
Use func_num_args() instead of that count expression.
--
Nilesh Govindarajan
Site & Server Administrator
www.itech7.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
