Re: [PHP] Will PHP ever grow up and have threading?
Peter Lind wrote: Anyway, I don't think either of us will change point of view much at this point - so we should probably just give the mailing list a rest by now. Thanks for the posts, it's been interesting to read :) Most of it. +1 -- Per Jessen, Zürich (11.6°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:42 PM, Stuart Dallas stut...@gmail.com wrote: On 24 Mar 2010, at 20:34, Rene Veerman wrote: On Wed, Mar 24, 2010 at 10:19 PM, Ashley Sheridan a...@ashleysheridan.co.uk wrote: On Wed, 2010-03-24 at 22:15 +0200, Rene Veerman wrote: Do you have any proof of this 'market trend'? I suggested a vote, but you 'nay-sayed' it on the basis that you'd lose to people who couldn't possibly know as much as you do. yes, twitter. facebook. the fact that a graphics upgrade would likely increase business for the first ones on that popularity level to implement it. that's the proof i have for the market trend. Again, improving the graphical content of a website has absolutely no effect on the performance of PHP. The additional time the page takes to load is all about network latency and how well you've arranged your static file serving. right now my cms is 2D, and indeed most of the graphics are static then. but i have plans to lift it into 3D, with rooms interacting via avatars, and then the graphics-selection and avatar-behavior (animations) selections alone i suspect will put much extra stress on the servers. especially if i have to use sql servers to handle the datastreams. oh, and the fact cloud computing is becoming more and more of a buzzword in the industry. Cloud computing really doesn't mean what you think it means. its a flexible term eh.. others' definitions are clearly not always aligned with yours. I wouldn't say I belonged to any particular camp at the start of this thread, but now, having read what my betters have said, I'm inclined to agree that threading isn't the magic wand that you seem to think it is. I personally see one of the largest sites in the world running on PHP without needing threading and without insulting half the list to attempt to get it. you haven't offered me any description at all of how i'd solve the large-scale realtime-web-app with existing techniques. By realtime-web-app you mean something like Facebook? They use a combination of PHP, Memcached (and lots of it), MySQL and lots of other layers in-between to do what they do, and threaded PHP is not one of them. i suppose facebook and twitter are the earliest examples of a near-realtime-web. i think the dataflows of the future realtimewebs (in the next 3 to 10 years) will increase quite a bit in size and speed of updates. and if i explain why i'd need the features we've discussed, you dismiss it by accepting a generalized that can be solved with more sql servers answer that is admitted to increase costs in every department, including energy consumption. on a non-linear scale btw. What I'm getting here is that you want everything without paying for it. When it comes to scalability it's cheaper to achieve it by adding servers than it is to squeeze every last drop of performance out of a single box. The cost in development time alone to implement effective threading strategies would far outstrip the cost of adding a couple of servers and ensuring that your app is scalable. i have this strong gut-feeling that adding more hardware when it's not needed leads to waste on a non-linear scale. in particular using sql servers to handle datastreams seems not wise to me. i'd like to use sql only for permanent storage. What you seem to be ignoring is the fact that these issues have been solved already, and the techniques that exist are more than adequate to build systems that scale as well as Facebook. What will it take to get you to accept that the way you want to skin the cat is exceedingly messy? yea, the current facebook and twitter. but i'm thinking 3 to 10 years ahead, and want threading and shared mem support in php to save on all my costs, energy consumption, and risks. i also think the wastefulness of letting the 'alternative' paradigm of 'more sql servers' is on a non-linear scale. -- 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? - vote.
Daevid Vincent wrote: Why don't you set up a vote to see how many developers actually *want* threading. That would be a good indication of whether or not it is actually worth the PHP development team spending a lot of time on it at the loss of other features which people want more. I already did that with the initial post! http://www.rapidpoll.net/show.aspx?id=awp1ocy And so far, as I expected, the majority is for threading. The majority have not voted yet ;) Although I don not classify 'thread safe' as the same thing as 'provide threading' so the poll is already skewed. -- 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?
Daevid Vincent wrote: Well, since I was the one that started this shit-storm, I'll chime in for a minute... ;-) 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 I'm sorry. I didn't realize PHP was designed for beginers. There is something about the entire environment that makes coding PHP for a webpage attractive to beginners. The runtime is your web-browser, you don't need to compile anything, you just edit, and hit F5. Combine that with weak typing and an easy syntax, and you've got something that is easy to pick up. Contrast that with perhaps Java and j2ee, a language and a framework often used in large, long term projects with long life expectancies - not really a beginners sandbox. You all think to shallow and narrow minded. You keep thinking in terms of using PHP as simply a web language. You need to think in terms of using it like Perl, Python, Ruby, Java, C/++, etc. Computers do a lot more than just spit out web pages these days. I know most of you seem to only think in terms of the cloud and other stupid technologies like that, but there's a great big world of computing that doesn't. There's no reason that PHP shouldn't be a viable language to use in those arenas either. PHP is perfectly viable for those areas today. I wouldn't personally use it for anything non-web unless it is less than 1000 lines. My experience has taught me not to (not just PHP, any script language). Spot on again. I have maybe 12 YEARS of PHP expertise, knowledge, libraries, tools, code snippets, etc that are battle tested and hardened and improved constantly. Now I'd have to toss all that out just to write some things in a language that has threading -- something that is a given in most EVERY other language. Actually, most don't have it built-in, it usually comes in separate libraries and is an operating-system feature, not a language feature. Two notable exceptions I can think of are Ada and PL/1. -- 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?
Tommy Pham wrote: As such, let's dissect what you mentioned: 1) PHP with internal thread support 2) PHP with external C/C++ thread support That's not quite what I mentioned, but I'll accept it for the sake of argument. * Performance - having external thread support, now you have to call an extension (more memory usage and CPU cycles). Tommy, you are already using millions of more cycles by running PHP instead of C. It's a reasonable trade-off of course, but using more cycles is not a valid counter-argument. If you happen to have a C/C++ guru who can then code that thread support into PHP extension, wouldn't it still perform better at the core vs as an extension because it's not talking to a 'middle man'? It's another trade-off Tommy - you run two separate processes, talking to each other over TCP (for instance) to gain 1) performance and 2) flexibility/scalability. You gain performance by having processes that can be independently scheduled by the OS, and you gain flexibility by being able to move a process to another box (for scalability). You pay for that with a few thousand cycles. When you decide to use a database (e.g. mysql) you also make a trade-off - well-managed data, a structured query-language and some overhead vs. doing it all in your own code. * Portability - if you're currently running PHP on Windows, but manage to convince management to switch to *BSD/Linux, then you'd have to rewrite that external thread support. If portability is a concern, I'd make sure my threaded backend would run on all the platforms I could envision. Portability is merely one of many factors that affect choice of programming language. * Managability - should your need to upgrade PHP for either bug fix, new features you'd want to implement to add more functionality to your site, will that then break your custom external solution? How much more manageable is it if it's done under 1 language versus 2+? I said it yesterday already - having a single implementation language IS a positive, but it may not always be possible due to requirements. -- Per Jessen, Zürich (12.3°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: I don't use Linux nor an expert in it but implementing custom thread solution like that means understanding about SELinux vs AppArmor vs Grsecurity or am I wrong? Yes, you are wrong. The Posix thread model implemented in the pthread library in Linux is easy to pick up for anyone who has studied computer science - where he or she will already have been introduced to mutexes, semaphores, the Dining Philosophers, race conditions, deadlocks and such. -- Per Jessen, Zürich (12.6°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: As some of you mention that implementing threads will make the DB work harder than the standard serial operations queries, let me ask you these then: * How often does your DB server(s)/cluster utilizes 100% CPU (SMP/MC), memory, and disk IO? Assuming we're talking under heavy load - my database server is an old(ish) HP Proliant ML570 - 4 x 3GHz Xeons with HT, dual U320 SCSI busses, 48GB RAM : CPU 100% - rarely, but it happens. Memory 100% - all the time. Disk IO 100% - less than all the time, but it's very busy. * If you could implement threads and run those same queries in 2+ threads, the total time saved from queries execution is 1/2 sec or more, which is pass along as the total response time reduced. Is it worth it for you implement threads if you're a speed freak? Use mysqlnd - asynchronous mysql queries. (I remember a list member, not mentioning his name, does optimization of PHP coding for just microseconds. Do you think how much more he'd benefit from this?) Anyone who optimizes PHP for microseconds has lost touch with reality - or at least forgotten that he or she is using an interpreted language. * If the requests are executed in parallel, the sooner the request fulfillment completes, the faster it is to move to the next request and complete it right? Correct. -- Per Jessen, Zürich (12.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?
Per Jessen wrote: CPU 100% - rarely, but it happens. Memory 100% - all the time. Disk IO 100% - less than all the time, but it's very busy. FYI, it's actually quite difficult to drive a disk subsystem to consistent 100% utilization over a period of time. Oracle uses asynchronous I/O and could probably drive a disk subsystem quite hard, but AFAIK, mysql doesn't. -- Per Jessen, Zürich (13.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?
On Thu, Mar 25, 2010 at 1:46 AM, Per Jessen p...@computer.org wrote: * If you could implement threads and run those same queries in 2+ threads, the total time saved from queries execution is 1/2 sec or more, which is pass along as the total response time reduced. Is it worth it for you implement threads if you're a speed freak? Use mysqlnd - asynchronous mysql queries. You're assuming that everyone in the PHP world uses MySQL 4.1 or newer. What about those who don't? Which goes back to being portability. -- 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 Thu, Mar 25, 2010 at 1:46 AM, Per Jessen p...@computer.org wrote: * If you could implement threads and run those same queries in 2+ threads, the total time saved from queries execution is 1/2 sec or more, which is pass along as the total response time reduced. Is it worth it for you implement threads if you're a speed freak? Use mysqlnd - asynchronous mysql queries. You're assuming that everyone in the PHP world uses MySQL 4.1 or newer. What about those who don't? They don't get to use threading, nor asynchronous mysql queries. Come on, you're asking about a future feature in PHP 7.x , but would like to support someone who is seriously backlevel on mysql?? -- Per Jessen, Zürich (16.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?
On Thu, 2010-03-25 at 08:11 +0200, Rene Veerman wrote: right now my cms is 2D, and indeed most of the graphics are static then. but i have plans to lift it into 3D, with rooms interacting via avatars, and then the graphics-selection and avatar-behavior (animations) selections alone i suspect will put much extra stress on the servers. especially if i have to use sql servers to handle the datastreams. Have you had a look at Papervision? It's about the best thing for 3D on the web right now, and has even garnered some official Adobe support. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [PHP] Will PHP ever grow up and have threading?
On Thu, Mar 25, 2010 at 12:02 PM, Ashley Sheridan a...@ashleysheridan.co.ukwrote: On Thu, 2010-03-25 at 08:11 +0200, Rene Veerman wrote: right now my cms is 2D, and indeed most of the graphics are static then. but i have plans to lift it into 3D, with rooms interacting via avatars, and then the graphics-selection and avatar-behavior (animations) selections alone i suspect will put much extra stress on the servers. especially if i have to use sql servers to handle the datastreams. Have you had a look at Papervision? It's about the best thing for 3D on the web right now, and has even garnered some official Adobe support. yup. papervision, away3d, i've had a look at them. my current thinking is to build an abstraction layer for 3D in flashdevelop.org that interfaces with either papervision or away3d.. no telling which'll be the victor in the end of that race. but the real reason for me to invest in an extra abstraction layer is those unlimited detail guys (http://www.youtube.com/watch?v=Q-ATtrImCx4ttl=1) who are likely to change the entire 3D stack (from graphicscard up).
Re: [PHP] Will PHP ever grow up and have threading?
Per Jessen wrote: Tommy Pham wrote: (I remember a list member, not mentioning his name, does optimization of PHP coding for just microseconds. Do you think how much more he'd benefit from this?) Anyone who optimizes PHP for microseconds has lost touch with reality - or at least forgotten that he or she is using an interpreted language. But sometimes it's just plain fun to do it here on the list with everyone further optimizing the last optimized snippet :) Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for 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 Thu, Mar 25, 2010 at 3:55 AM, Per Jessen p...@computer.org wrote: Tommy Pham wrote: On Thu, Mar 25, 2010 at 1:46 AM, Per Jessen p...@computer.org wrote: * If you could implement threads and run those same queries in 2+ threads, the total time saved from queries execution is 1/2 sec or more, which is pass along as the total response time reduced. Is it worth it for you implement threads if you're a speed freak? Use mysqlnd - asynchronous mysql queries. You're assuming that everyone in the PHP world uses MySQL 4.1 or newer. What about those who don't? They don't get to use threading, nor asynchronous mysql queries. Come on, you're asking about a future feature in PHP 7.x , but would like to support someone who is seriously backlevel on mysql?? -- Per Jessen, Zürich (16.9°C) I'm not talking about MySQL 4.0 or older. I'm talking about other RDBMS. I think you should open your eyes a bit wider and take a look at the bigger picture (Firebird, MSSQL, Oracle, PostgreSQL, etc). -- 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 25 March 2010 19:37, Tommy Pham tommy...@gmail.com wrote: On Thu, Mar 25, 2010 at 3:55 AM, Per Jessen p...@computer.org wrote: Tommy Pham wrote: On Thu, Mar 25, 2010 at 1:46 AM, Per Jessen p...@computer.org wrote: * If you could implement threads and run those same queries in 2+ threads, the total time saved from queries execution is 1/2 sec or more, which is pass along as the total response time reduced. Is it worth it for you implement threads if you're a speed freak? Use mysqlnd - asynchronous mysql queries. You're assuming that everyone in the PHP world uses MySQL 4.1 or newer. What about those who don't? They don't get to use threading, nor asynchronous mysql queries. Come on, you're asking about a future feature in PHP 7.x , but would like to support someone who is seriously backlevel on mysql?? -- Per Jessen, Zürich (16.9°C) I'm not talking about MySQL 4.0 or older. I'm talking about other RDBMS. I think you should open your eyes a bit wider and take a look at the bigger picture (Firebird, MSSQL, Oracle, PostgreSQL, etc). http://www.php.net/manual/en/function.pg-send-query.php Looks to me like the PHP postgresql library already handles that. Not to mention: you're not presenting an argument for threads, you're presenting an argument for implementing asynchronous queries in the other DBMS libraries. Of course, the problem could also be solved by introducing threads in PHP. I'd personally guess modifying DBMS libraries would be less costly, but as I haven't been involved in writing the PHP code my guess isn't worth much. Regards Peter -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- hype 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 /hype -- 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 Thu, Mar 25, 2010 at 12:02 PM, Peter Lind peter.e.l...@gmail.com wrote: On 25 March 2010 19:37, Tommy Pham tommy...@gmail.com wrote: On Thu, Mar 25, 2010 at 3:55 AM, Per Jessen p...@computer.org wrote: Tommy Pham wrote: On Thu, Mar 25, 2010 at 1:46 AM, Per Jessen p...@computer.org wrote: * If you could implement threads and run those same queries in 2+ threads, the total time saved from queries execution is 1/2 sec or more, which is pass along as the total response time reduced. Is it worth it for you implement threads if you're a speed freak? Use mysqlnd - asynchronous mysql queries. You're assuming that everyone in the PHP world uses MySQL 4.1 or newer. What about those who don't? They don't get to use threading, nor asynchronous mysql queries. Come on, you're asking about a future feature in PHP 7.x , but would like to support someone who is seriously backlevel on mysql?? -- Per Jessen, Zürich (16.9°C) I'm not talking about MySQL 4.0 or older. I'm talking about other RDBMS. I think you should open your eyes a bit wider and take a look at the bigger picture (Firebird, MSSQL, Oracle, PostgreSQL, etc). http://www.php.net/manual/en/function.pg-send-query.php Looks to me like the PHP postgresql library already handles that. Not to mention: you're not presenting an argument for threads, you're presenting an argument for implementing asynchronous queries in the other DBMS libraries. Of course, the problem could also be solved by introducing threads in PHP. I'd personally guess modifying DBMS libraries would be less costly, but as I haven't been involved in writing the PHP code my guess isn't worth much. Regards Peter I'm presenting the argument for threading. Per is presenting the work around using asynchronous queries via mysqlnd. I did read that link a few days ago, Although the user can send multiple queries at once, multiple queries cannot be sent over a busy connection. If a query is sent while the connection is busy, it waits until the last query is finished and discards all its results. Which sounds like threads - multiple connections to not run into that problem. -- 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 25 March 2010 20:09, Tommy Pham tommy...@gmail.com wrote: On Thu, Mar 25, 2010 at 12:02 PM, Peter Lind peter.e.l...@gmail.com wrote: On 25 March 2010 19:37, Tommy Pham tommy...@gmail.com wrote: On Thu, Mar 25, 2010 at 3:55 AM, Per Jessen p...@computer.org wrote: Tommy Pham wrote: On Thu, Mar 25, 2010 at 1:46 AM, Per Jessen p...@computer.org wrote: * If you could implement threads and run those same queries in 2+ threads, the total time saved from queries execution is 1/2 sec or more, which is pass along as the total response time reduced. Is it worth it for you implement threads if you're a speed freak? Use mysqlnd - asynchronous mysql queries. You're assuming that everyone in the PHP world uses MySQL 4.1 or newer. What about those who don't? They don't get to use threading, nor asynchronous mysql queries. Come on, you're asking about a future feature in PHP 7.x , but would like to support someone who is seriously backlevel on mysql?? -- Per Jessen, Zürich (16.9°C) I'm not talking about MySQL 4.0 or older. I'm talking about other RDBMS. I think you should open your eyes a bit wider and take a look at the bigger picture (Firebird, MSSQL, Oracle, PostgreSQL, etc). http://www.php.net/manual/en/function.pg-send-query.php Looks to me like the PHP postgresql library already handles that. Not to mention: you're not presenting an argument for threads, you're presenting an argument for implementing asynchronous queries in the other DBMS libraries. Of course, the problem could also be solved by introducing threads in PHP. I'd personally guess modifying DBMS libraries would be less costly, but as I haven't been involved in writing the PHP code my guess isn't worth much. Regards Peter I'm presenting the argument for threading. Per is presenting the work around using asynchronous queries via mysqlnd. I did read that link a few days ago, Although the user can send multiple queries at once, multiple queries cannot be sent over a busy connection. If a query is sent while the connection is busy, it waits until the last query is finished and discards all its results. Which sounds like threads - multiple connections to not run into that problem. Have you looked into what it would cost in development to improve the library? Have you compared that to the cost in development to introduce threads into PHP? No, I don't think you're presenting the argument for threading - but I don't expect you to see it that way. -- hype 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 /hype -- 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 Thu, 2010-03-25 at 12:09 -0700, Tommy Pham wrote: On Thu, Mar 25, 2010 at 12:02 PM, Peter Lind peter.e.l...@gmail.com wrote: On 25 March 2010 19:37, Tommy Pham tommy...@gmail.com wrote: On Thu, Mar 25, 2010 at 3:55 AM, Per Jessen p...@computer.org wrote: Tommy Pham wrote: On Thu, Mar 25, 2010 at 1:46 AM, Per Jessen p...@computer.org wrote: * If you could implement threads and run those same queries in 2+ threads, the total time saved from queries execution is 1/2 sec or more, which is pass along as the total response time reduced. Is it worth it for you implement threads if you're a speed freak? Use mysqlnd - asynchronous mysql queries. You're assuming that everyone in the PHP world uses MySQL 4.1 or newer. What about those who don't? They don't get to use threading, nor asynchronous mysql queries. Come on, you're asking about a future feature in PHP 7.x , but would like to support someone who is seriously backlevel on mysql?? -- Per Jessen, Zürich (16.9°C) I'm not talking about MySQL 4.0 or older. I'm talking about other RDBMS. I think you should open your eyes a bit wider and take a look at the bigger picture (Firebird, MSSQL, Oracle, PostgreSQL, etc). http://www.php.net/manual/en/function.pg-send-query.php Looks to me like the PHP postgresql library already handles that. Not to mention: you're not presenting an argument for threads, you're presenting an argument for implementing asynchronous queries in the other DBMS libraries. Of course, the problem could also be solved by introducing threads in PHP. I'd personally guess modifying DBMS libraries would be less costly, but as I haven't been involved in writing the PHP code my guess isn't worth much. Regards Peter I'm presenting the argument for threading. Per is presenting the work around using asynchronous queries via mysqlnd. I did read that link a few days ago, Although the user can send multiple queries at once, multiple queries cannot be sent over a busy connection. If a query is sent while the connection is busy, it waits until the last query is finished and discards all its results. Which sounds like threads - multiple connections to not run into that problem. Wouldn't there still be the same issue though? If several threads of PHP are all trying to connect to to a database that can only handle a finite number of connections, the database must still wait until a query has been pushed off of it's queue before it can process another. As far as I can see, this isn't an issue that can be solved by threading in PHP, but by allowing more concurrent connections in the database. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [PHP] Will PHP ever grow up and have threading?
On Thu, Mar 25, 2010 at 12:13 PM, Peter Lind peter.e.l...@gmail.com wrote: On 25 March 2010 20:09, Tommy Pham tommy...@gmail.com wrote: On Thu, Mar 25, 2010 at 12:02 PM, Peter Lind peter.e.l...@gmail.com wrote: On 25 March 2010 19:37, Tommy Pham tommy...@gmail.com wrote: On Thu, Mar 25, 2010 at 3:55 AM, Per Jessen p...@computer.org wrote: Tommy Pham wrote: On Thu, Mar 25, 2010 at 1:46 AM, Per Jessen p...@computer.org wrote: * If you could implement threads and run those same queries in 2+ threads, the total time saved from queries execution is 1/2 sec or more, which is pass along as the total response time reduced. Is it worth it for you implement threads if you're a speed freak? Use mysqlnd - asynchronous mysql queries. You're assuming that everyone in the PHP world uses MySQL 4.1 or newer. What about those who don't? They don't get to use threading, nor asynchronous mysql queries. Come on, you're asking about a future feature in PHP 7.x , but would like to support someone who is seriously backlevel on mysql?? -- Per Jessen, Zürich (16.9°C) I'm not talking about MySQL 4.0 or older. I'm talking about other RDBMS. I think you should open your eyes a bit wider and take a look at the bigger picture (Firebird, MSSQL, Oracle, PostgreSQL, etc). http://www.php.net/manual/en/function.pg-send-query.php Looks to me like the PHP postgresql library already handles that. Not to mention: you're not presenting an argument for threads, you're presenting an argument for implementing asynchronous queries in the other DBMS libraries. Of course, the problem could also be solved by introducing threads in PHP. I'd personally guess modifying DBMS libraries would be less costly, but as I haven't been involved in writing the PHP code my guess isn't worth much. Regards Peter I'm presenting the argument for threading. Per is presenting the work around using asynchronous queries via mysqlnd. I did read that link a few days ago, Although the user can send multiple queries at once, multiple queries cannot be sent over a busy connection. If a query is sent while the connection is busy, it waits until the last query is finished and discards all its results. Which sounds like threads - multiple connections to not run into that problem. Have you looked into what it would cost in development to improve the library? Have you compared that to the cost in development to introduce threads into PHP? No, I don't think you're presenting the argument for threading - but I don't expect you to see it that way. Aren't all feature requests must be analyzed the same way? Example, namespace, how many of us actually uses it now when there is an alternative solution- subfolders - that we've been using since who knows how long. I don't know if threads was asked a feature prior namespace was implemented. -- 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 Thu, Mar 25, 2010 at 12:11 PM, Ashley Sheridan a...@ashleysheridan.co.uk wrote: On Thu, 2010-03-25 at 12:09 -0700, Tommy Pham wrote: On Thu, Mar 25, 2010 at 12:02 PM, Peter Lind peter.e.l...@gmail.com wrote: On 25 March 2010 19:37, Tommy Pham tommy...@gmail.com wrote: On Thu, Mar 25, 2010 at 3:55 AM, Per Jessen p...@computer.org wrote: Tommy Pham wrote: On Thu, Mar 25, 2010 at 1:46 AM, Per Jessen p...@computer.org wrote: * If you could implement threads and run those same queries in 2+ threads, the total time saved from queries execution is 1/2 sec or more, which is pass along as the total response time reduced. Is it worth it for you implement threads if you're a speed freak? Use mysqlnd - asynchronous mysql queries. You're assuming that everyone in the PHP world uses MySQL 4.1 or newer. What about those who don't? They don't get to use threading, nor asynchronous mysql queries. Come on, you're asking about a future feature in PHP 7.x , but would like to support someone who is seriously backlevel on mysql?? -- Per Jessen, Zürich (16.9°C) I'm not talking about MySQL 4.0 or older. I'm talking about other RDBMS. I think you should open your eyes a bit wider and take a look at the bigger picture (Firebird, MSSQL, Oracle, PostgreSQL, etc). http://www.php.net/manual/en/function.pg-send-query.php Looks to me like the PHP postgresql library already handles that. Not to mention: you're not presenting an argument for threads, you're presenting an argument for implementing asynchronous queries in the other DBMS libraries. Of course, the problem could also be solved by introducing threads in PHP. I'd personally guess modifying DBMS libraries would be less costly, but as I haven't been involved in writing the PHP code my guess isn't worth much. Regards Peter I'm presenting the argument for threading. Per is presenting the work around using asynchronous queries via mysqlnd. I did read that link a few days ago, Although the user can send multiple queries at once, multiple queries cannot be sent over a busy connection. If a query is sent while the connection is busy, it waits until the last query is finished and discards all its results. Which sounds like threads - multiple connections to not run into that problem. Wouldn't there still be the same issue though? If several threads of PHP are all trying to connect to to a database that can only handle a finite number of connections, the database must still wait until a query has been pushed off of it's queue before it can process another. As far as I can see, this isn't an issue that can be solved by threading in PHP, but by allowing more concurrent connections in the database. Thanks, Ash http://www.ashleysheridan.co.uk That's why I asked about the DB utilization earlier. Since the having the threads can open multiple connections and finish the request sooner, it can move on to the next request. Since Java ASP.NET have connection pooling, this adds to benefit of threads even more. I don't know if PHP has connection pooling now. I haven't code in PHP a some years. Regards, Tommy -- 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 25 March 2010 20:19, Tommy Pham tommy...@gmail.com wrote: Aren't all feature requests must be analyzed the same way? Example, namespace, how many of us actually uses it now when there is an alternative solution- subfolders - that we've been using since who knows how long. I don't know if threads was asked a feature prior namespace was implemented. Yes, you're right. But feature requests are not equal: some present a bigger payoff than others, and some will be more problematic to implement than others. If a given language can solve the problems it meets based on it's current structure, should you necessarily implement new shiny features, that may present problems? I'm not against threads in PHP per se ... I just haven't seen a very convincing reason for them yet, which is why I'm not very positive about the thing. The DB scenario could be handled without threads and current libraries could be improved ... and as long as that's cheaper than implementing threads, then - personally - I'd need to see more powerful reasons for threads. Luckily, I have no say in the development of PHP, so I won't get in anyone's way should they choose to implement threads :) -- hype 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 /hype -- 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 Thu, Mar 25, 2010 at 12:28 PM, Peter Lind peter.e.l...@gmail.com wrote: On 25 March 2010 20:19, Tommy Pham tommy...@gmail.com wrote: Aren't all feature requests must be analyzed the same way? Example, namespace, how many of us actually uses it now when there is an alternative solution- subfolders - that we've been using since who knows how long. I don't know if threads was asked a feature prior namespace was implemented. Yes, you're right. But feature requests are not equal: some present a bigger payoff than others, and some will be more problematic to implement than others. If a given language can solve the problems it meets based on it's current structure, should you necessarily implement new shiny features, that may present problems? I'm not against threads in PHP per se ... I just haven't seen a very convincing reason for them yet, which is why I'm not very positive about the thing. The DB scenario could be handled without threads and current libraries could be improved ... and as long as that's cheaper than implementing threads, then - personally - I'd need to see more powerful reasons for threads. Luckily, I have no say in the development of PHP, so I won't get in anyone's way should they choose to implement threads :) Here's my analysis, let's say that you have 1000 requests / second on the web server. Each request has multiqueries which take a total of 1 second to complete. In that one second, how many of those 1000 arrive at the same time (that one instant of micro/nano second)? You see how threads come in? If you have threads that are able finish the requests that come in that instant and able to complete them before the next batch of requests in that same second, wouldn't you agree then that you're delivering faster response time to all your users? -- 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 25 March 2010 20:59, Tommy Pham tommy...@gmail.com wrote: On Thu, Mar 25, 2010 at 12:28 PM, Peter Lind peter.e.l...@gmail.com wrote: On 25 March 2010 20:19, Tommy Pham tommy...@gmail.com wrote: Aren't all feature requests must be analyzed the same way? Example, namespace, how many of us actually uses it now when there is an alternative solution- subfolders - that we've been using since who knows how long. I don't know if threads was asked a feature prior namespace was implemented. Yes, you're right. But feature requests are not equal: some present a bigger payoff than others, and some will be more problematic to implement than others. If a given language can solve the problems it meets based on it's current structure, should you necessarily implement new shiny features, that may present problems? I'm not against threads in PHP per se ... I just haven't seen a very convincing reason for them yet, which is why I'm not very positive about the thing. The DB scenario could be handled without threads and current libraries could be improved ... and as long as that's cheaper than implementing threads, then - personally - I'd need to see more powerful reasons for threads. Luckily, I have no say in the development of PHP, so I won't get in anyone's way should they choose to implement threads :) Here's my analysis, let's say that you have 1000 requests / second on the web server. Each request has multiqueries which take a total of 1 second to complete. In that one second, how many of those 1000 arrive at the same time (that one instant of micro/nano second)? You see how threads come in? If you have threads that are able finish the requests that come in that instant and able to complete them before the next batch of requests in that same second, wouldn't you agree then that you're delivering faster response time to all your users? That sounds like your webserver spawning new processes dealing with requests ... possibly combined with connection pooling and asynchronous queries and load balancing, etc, etc. So no, I'm not convinced that PHP with threads would actually deliver much faster than a properly built setup that makes good usage of technology you'll have to use anyway. -- hype 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 /hype -- 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: I'm presenting the argument for threading. Per is presenting the work around using asynchronous queries via mysqlnd. I did read that link a few days ago, Although the user can send multiple queries at once, multiple queries cannot be sent over a busy connection. If a query is sent while the connection is busy, it waits until the last query is finished and discards all its results. Which sounds like threads - multiple connections to not run into that problem. You must have read the wrong page. This is NOT about multiple queries, it's about _asynchronous_ queries. -- Per Jessen, Zürich (15.1°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: I'm not against threads in PHP per se ... I just haven't seen a very convincing reason for them yet, which is why I'm not very positive about the thing. Roughly the same here - I don't think threading belongs in PHP, but if someone decides it's a good idea, I won't be arguing against someone volunteering the effort. /Per -- Per Jessen, Zürich (15.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?
Tommy Pham wrote: Here's my analysis, let's say that you have 1000 requests / second on the web server. Each request has multiqueries which take a total of 1 second to complete. In that one second, how many of those 1000 arrive at the same time (that one instant of micro/nano second)? On average, exactly one per millisecond. /Per -- Per Jessen, Zürich (15.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?
Per Jessen wrote: Tommy Pham wrote: I'm presenting the argument for threading. Per is presenting the work around using asynchronous queries via mysqlnd. I did read that link a few days ago, Although the user can send multiple queries at once, multiple queries cannot be sent over a busy connection. If a query is sent while the connection is busy, it waits until the last query is finished and discards all its results. Which sounds like threads - multiple connections to not run into that problem. You must have read the wrong page. This is NOT about multiple queries, it's about _asynchronous_ queries. The only problem here is what the database client can handle. If it can only handle one active query, then that is all that can be used. It can be started asynchronously and then you come back to pick up the results later, and so you can be formating the page ready to insert the results. PDO requires that you start a different connection in a different transaction for each of these queries, but that is another hot potato. Running 10 asynchronous queries would require 10 connections as that is how the database end works. Adding threading to PHP is going to make no difference? -- 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 25 March 2010 22:51, Lester Caine les...@lsces.co.uk wrote: Per Jessen wrote: Tommy Pham wrote: I'm presenting the argument for threading. Per is presenting the work around using asynchronous queries via mysqlnd. I did read that link a few days ago, Although the user can send multiple queries at once, multiple queries cannot be sent over a busy connection. If a query is sent while the connection is busy, it waits until the last query is finished and discards all its results. Which sounds like threads - multiple connections to not run into that problem. You must have read the wrong page. This is NOT about multiple queries, it's about _asynchronous_ queries. The only problem here is what the database client can handle. If it can only handle one active query, then that is all that can be used. It can be started asynchronously and then you come back to pick up the results later, and so you can be formating the page ready to insert the results. PDO requires that you start a different connection in a different transaction for each of these queries, but that is another hot potato. Running 10 asynchronous queries would require 10 connections as that is how the database end works. Adding threading to PHP is going to make no difference? Actually, this sounds very close to having 10 threads each opening a connection to the database and running the query ... which was the solution to the scenario presented, if memory serves. -- 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 -- hype 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 /hype -- 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 Thu, Mar 25, 2010 at 1:50 PM, Per Jessen p...@computer.org wrote: Tommy Pham wrote: I'm presenting the argument for threading. Per is presenting the work around using asynchronous queries via mysqlnd. I did read that link a few days ago, Although the user can send multiple queries at once, multiple queries cannot be sent over a busy connection. If a query is sent while the connection is busy, it waits until the last query is finished and discards all its results. Which sounds like threads - multiple connections to not run into that problem. You must have read the wrong page. This is NOT about multiple queries, it's about _asynchronous_ queries. That quote is comming directly from that link Peter Lind gave, which I read a few days ago. Did you read it? -- 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 Thu, Mar 25, 2010 at 3:04 PM, Tommy Pham tommy...@gmail.com wrote: On Thu, Mar 25, 2010 at 1:50 PM, Per Jessen p...@computer.org wrote: Tommy Pham wrote: I'm presenting the argument for threading. Per is presenting the work around using asynchronous queries via mysqlnd. I did read that link a few days ago, Although the user can send multiple queries at once, multiple queries cannot be sent over a busy connection. If a query is sent while the connection is busy, it waits until the last query is finished and discards all its results. Which sounds like threads - multiple connections to not run into that problem. You must have read the wrong page. This is NOT about multiple queries, it's about _asynchronous_ queries. That quote is comming directly from that link Peter Lind gave, which I read a few days ago. Did you read it? Here's the entire description: pg_send_query() sends a query or queries asynchronously to the connection . Unlike pg_query(), it *can send multiple queries at once to PostgreSQL*and *get the results one by one using pg_get_result().* Script execution is not blocked while the queries are executing. Use pg_connection_busy() to check if the connection is busy (i.e. the query is executing). Queries may be cancelled using pg_cancel_query(). *Although the user can send multiple queries at once, multiple queries cannot be sent over a busy connection. If a query is sent while the connection is busy, it waits until the last query is finished and discards all its results.* Any case, that's only workaround for mysql (mysqlnd) postgresql. What about those that uses other RDBMS?
Re: [PHP] Will PHP ever grow up and have threading?
?php
$dbconn = pg_connect(dbname=publisher) or die(Could not connect);
if (!pg_connection_busy($dbconn)) {
pg_send_query($dbconn, select * from authors; select count(*)
from authors;);
}
$res1 = pg_get_result($dbconn);
echo First call to pg_get_result(): $res1\n;
$rows1 = pg_num_rows($res1);
echo $res1 has $rows1 records\n\n;
$res2 = pg_get_result($dbconn);
echo Second call to pg_get_result(): $res2\n;
$rows2 = pg_num_rows($res2);
echo $res2 has $rows2 records\n;
?
There's the code example from that same link. You may have executed
the queries asynchronously, but the process of the results are still
serial. Let's face it, all of our processing of queries are not a
simple echo. We iterate/loop through the results and display them in
the desired format. Having execute the query and the processing of
the result in threads/parallel, you get the real performance boost
which I've been trying to convey the concept of serial versus
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 25 March 2010 23:23, Tommy Pham tommy...@gmail.com wrote: There's the code example from that same link. You may have executed the queries asynchronously, but the process of the results are still serial. Let's face it, all of our processing of queries are not a simple echo. We iterate/loop through the results and display them in the desired format. Having execute the query and the processing of the result in threads/parallel, you get the real performance boost which I've been trying to convey the concept of serial versus parallel. Actually, you haven't mentioned the processing as part of what the threads do until now. I see your point though: if you split that part off, you might gain some performance, that would otherwise be hard to get at. I wonder though, if the performance is worth it in the tradeoff for the maintenance nightmare it is when you split out content processing between 10 different threads. I wouldn't personally touch it unless I had no other option, but that's just my opinion. Anyway, I don't think either of us will change point of view much at this point - so we should probably just give the mailing list a rest by now. Thanks for the posts, it's been interesting to read :) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- hype 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 /hype -- 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 Thu, Mar 25, 2010 at 3:35 PM, Peter Lind peter.e.l...@gmail.com wrote: On 25 March 2010 23:23, Tommy Pham tommy...@gmail.com wrote: There's the code example from that same link. You may have executed the queries asynchronously, but the process of the results are still serial. Let's face it, all of our processing of queries are not a simple echo. We iterate/loop through the results and display them in the desired format. Having execute the query and the processing of the result in threads/parallel, you get the real performance boost which I've been trying to convey the concept of serial versus parallel. Actually, you haven't mentioned the processing as part of what the threads do until now. I see your point though: if you split that part off, you might gain some performance, that would otherwise be hard to get at. Because in the past, when someone mention performance issues, the replies come in with: is DB structure optimized, are queries optimized, is the code optimized? For those in the field long enough and have all that optimized and want additional performance boost, what else are there? Thus, when I mentioned threads/parallel, I don't mean execution of queries, but of everything in the entire app/project where the gain is desired. I wonder though, if the performance is worth it in the tradeoff for the maintenance nightmare it is when you split out content processing between 10 different threads. I wouldn't personally touch it unless I had no other option, but that's just my opinion. Anyway, I don't think either of us will change point of view much at this point - so we should probably just give the mailing list a rest by now. Thanks for the posts, it's been interesting to read :) Agreed. :) -- 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:49 PM, Larry Garfield la...@garfieldtech.com wrote: On Tuesday 23 March 2010 11:32:10 pm Tommy Pham wrote: On Tue, Mar 23, 2010 at 9:06 PM, Teus Benschop teusjanne...@gmail.com wrote: When looking at PHP as used in enterprise class applications, we can see the following happening. Let imagine that we have a site that gets a 1000 requests per second. That seems to be a good candidate for threading so as to be able to handle the 1000 requests per second. The site runs PHP and Apache. Well, what happens? Each request coming in is handed of to a separate instance of Apache. Thus the site would be able to process many requests simultaneously. It looks as if parallel computing is taking place here, which looks much like threading. Even though PHP itself does not know about threads, and does not need to, I think, the whole process of handling the 1000 requests per second uses parallel computing. There are no performance bottle-necks here. Teus. # of requests / second can be solved by load balancers/clusters. What about the multiple answers for a simple request per user as in my example? How you would solve that if not by threading? Amazon has about 30 million products and they have filters similar to what I mentioned. But when clicking on one of the I18n site at the bottom, you're taken to another server, which looks like it uses a different DB back end (I could be wrong) and you don't get instant translation of the category you're looking at. Their response time is about 3 seconds on my 10mbs (not cable) download. As for what programming language they use... Honestly, how WOULD you solve that with threading? You describe a page that needs to be generated that has a half-dozen queries against the database ranging from simple to moderately complex, some of which are site-generic and some are user-specific. How does one solve that with threading? 1) Run the site-generic queries once and cache them in memory and let other threads just use that query result. You can do that without threads. Just render that part of the page and cache that string to disk, to the database, or to memcache. If the memecache server is on the same box then it should be identical to the threading version, performance-wise. (Give or take VM considerations.) 2) Push the user-specific DB queries to separate threads so they can run in parallel. All that does is push the hard work off onto the DB server, which is still running the same number of queries. And PHP can't respond until all of the queries finish anyway, and the DB server will respond no faster, so you're really gaining nothing. You keep saying how would you solve this without threads? as if they're some magical speed fairy dust. Given the scenario you describe, I don't even see how threads would buy you anything at all. Where threads would be useful is for lots of very small writes on rapidly changing data. I would never want to write, say, the World of Warcraft servers without threading and a persistent runtime, but then I wouldn't want to write them in PHP to begin with. Insert that old saying about hammers and nails here. --Larry Garfield The difference is doing all those queries in serial operations (one after another) versus parallel operations (threads). Instead of waiting, for example, about .05 to .25 sec for each of those queries, the total wait time would be diminishes since each thread would execute a query. Either way, the DB is still doing the required total work. Difference is serial parallel operations as I iterated several times. Being running in parallel, the web browser will be getting the required info faster since PHP is able to get all the info faster. -- 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 teusjanne...@gmail.com wrote: On Tue, 2010-03-23 at 21:32 -0700, Tommy Pham wrote: # of requests / second can be solved by load balancers/clusters. What about the multiple answers for a simple request per user as in my example? How you would solve that if not by threading? Amazon has about 30 million products and they have filters similar to what I mentioned. But when clicking on one of the I18n site at the bottom, you're taken to another server, which looks like it uses a different DB back end (I could be wrong) and you don't get instant translation of the category you're looking at. Their response time is about 3 seconds on my 10mbs (not cable) download. As for what programming language they use... Well, the multiple answers for a simple request per user as in your example, seem to be a lot of information to display all on one page, and present all that information to the user in one request. I would probably resolve it, IMHO, by using pagers. That is, only part of the Pagers are needed when there's a lot of products to display. But using the filters and show them is different. Look at Amazon (not endorsing it). Click any category. You'll see what I mean by the filters (manufacturers, price range, subcategories, etc) and the display requirements (specials, bestsellers) as I mentioned. They also have other things, like shoppers' discussions, on that page too. Think about how many queries they have to run for all that info to show based on a simple request of a 'category'. Then time the response time. information is shown to the user at one time, and the user can page through that information so as to get to other bits of information. If only part is shown, then the database query becomes so much faster (hopefully), and PHP still can do all of it in one thread. A PHP application, by the nature of PHP, consists of small page requests to be done at one time, rather than move a lot of information around per request. Thinking the PHP-way requires some study because, as said, the information is presented or moved about in small chunks. Desktop applications, and probably Java web applications (I have no experience with Java but have read up on it a little) work differently. A successful PHP application is redesigned from the ground up, rather than remorphing a Java or other desktop application in PHP without changing the design principles. The key to makign your eCommerce application snappy, is, I think, not threading, but optimization of database queries. And another key is that less information presented to the user is usually clearer to the user, and thus they feel better at the site, and would return sooner to buy something. The real head-ache here and the difficult part is: How to design a clear and clean interface for the user. It's not threading. Teus. -- 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 p...@computer.org wrote: Tommy Pham wrote: On Tue, Mar 23, 2010 at 2:04 AM, Per Jessen p...@computer.org wrote: Use the right tool for the right job - PHP is a scripting/interpreted language, it does not need threading (IMO of course). -- Per Jessen, Zürich (9.4°C) I couldn't agree more. But here's a real life example. Your client has a forum and is using phpbb for their in house use. They also have an in house custom PHP app, integrated with phpbb, built to suit their needs. Now they want to implement some kind of CMS. You come in and implemented a PHP based CMS to integrate into their existing applications. Then you realize something troublesome, you have a performance issue where it could be resolved by implementing thread. What are you going to do? The standard, mature, experienced answer is - buy a bigger box. [snip] What do you think the client's response is when their need for the solution requires a short time frame of, if not immediate, implementation? There are no immediate solutions to immediate performance problems. If you have a poor design that restricts your throughput, you can 1) throw hardware at it or 2) change the design. At some point you'll hit yet another limit with 1), and you are forced back to 2). Somewhere along the line the original designer has presumably left or been made to. /Per -- Per Jessen, Zürich (7.5°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- 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?
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 p...@computer.org 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 rene7...@gmail.com 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 p...@computer.org 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?
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 les...@lsces.co.uk 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 p...@computer.org 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 les...@lsces.co.uk 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 p...@computer.org 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 les...@lsces.co.uk 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 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?
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 a...@ashleysheridan.co.uk 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 les...@lsces.co.uk 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 p...@computer.org 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 a...@ashleysheridan.co.ukwrote: 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 a...@ashleysheridan.co.ukwrote: 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 p...@computer.org 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 p...@computer.org 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 p...@computer.org 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 p...@computer.org 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 stut...@gmail.com 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 p...@computer.org 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 rene7...@gmail.com 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 stut...@gmail.com 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 p...@computer.org 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 rene7...@gmail.com 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 rene7...@gmail.com 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 stut...@gmail.com 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 p...@computer.org 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 rene7...@gmail.com 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 rene7...@gmail.com 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 rene7...@gmail.com 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 stut...@gmail.com 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 p...@computer.org 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 -- hype 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 /hype -- 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 rene7...@gmail.com 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 peter.e.l...@gmail.com wrote: On 24 March 2010 10:38, Rene Veerman rene7...@gmail.com 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 rene7...@gmail.com 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 rene7...@gmail.com 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 stut...@gmail.com 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 p...@computer.org 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
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 rene7...@gmail.com 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] 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 stut...@gmail.com 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 rene7...@gmail.com 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 p...@computer.org wrote: Tommy Pham wrote: What I find funny is that one of opponents of PHP threads earlier mentioned that how silly it would be to be using C in a web app. Now I hear people mentioning C when they need productivity or speed... I think I was the one to mention the latter, but as I started out saying, and as others have said too, it's about the right tool for the right job. When choosing a tool, there are a number of factors to consider - developer productivity, available skills, future maintenance, performance, scalability, portability, parallelism, performance etcetera. Funny you should mention all that. Let's say that you're longer with that company, either by direct employment or contract consultant. You've implemented C because you need 'thread'. Now your replacement comes in and has no clue about C even though your replacement is a PHP guru. How much headache is maintenance gonna be? Scalability? Portability? wow -- 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 stut...@gmail.com 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 tommy...@gmail.com 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 stut...@gmail.com wrote: On 24 Mar 2010, at 10:24, Tommy Pham wrote: On Wed, Mar 24, 2010 at 2:58 AM, Stuart Dallas stut...@gmail.com 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 tommy...@gmail.com 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 a...@ashleysheridan.co.ukwrote: 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 stut...@gmail.com 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 p...@computer.org wrote: Tommy Pham wrote: What I find funny is that one of opponents of PHP threads earlier mentioned that how silly it would be to be using C in a web app. Now I hear people mentioning C when they need productivity or speed... I think I was the one to mention the latter, but as I started out saying, and as others have said too, it's about the right tool for the right job. When choosing a tool, there are a number of factors to consider - developer productivity, available skills, future maintenance, performance, scalability, portability, parallelism, performance etcetera. Funny you should mention all that. Let's say that you're longer with that company, either by direct employment or contract consultant. You've implemented C because you need 'thread'. Now your replacement comes in and has no clue about C even though your replacement is a PHP guru. How much headache is maintenance gonna be? Scalability? Portability? wow Who was the idi... who hired someone who wasn't suited for the job? Tommy, that's a moot argument. You can't fit a square peg in a round hole. -- Per Jessen, Zürich (12.5°C) -- 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 stut...@gmail.com 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 rene7...@gmail.com 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 stut...@gmail.com wrote: On 24 Mar 2010, at 10:24, Tommy Pham wrote: On Wed, Mar 24, 2010 at 2:58 AM, Stuart Dallas stut...@gmail.com 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 stut...@gmail.com 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 stut...@gmail.com wrote: On 24 Mar 2010, at 10:34, Rene Veerman wrote: On Wed, Mar 24, 2010 at 12:28 PM, Tommy Pham tommy...@gmail.com 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 p...@computer.org wrote: Tommy Pham wrote: On Wed, Mar 24, 2010 at 3:20 AM, Per Jessen p...@computer.org wrote: Tommy Pham wrote: What I find funny is that one of opponents of PHP threads earlier mentioned that how silly it would be to be using C in a web app. Now I hear people mentioning C when they need productivity or speed... I think I was the one to mention the latter, but as I started out saying, and as others have said too, it's about the right tool for the right job. When choosing a tool, there are a number of factors to consider - developer productivity, available skills, future maintenance, performance, scalability, portability, parallelism, performance etcetera. Funny you should mention all that. Let's say that you're longer with that company, either by direct employment or contract consultant. You've implemented C because you need 'thread'. Now your replacement comes in and has no clue about C even though your replacement is a PHP guru. How much headache is maintenance gonna be? Scalability? Portability? wow Who was the idi... who hired someone who wasn't suited for the job? Tommy, that's a moot argument. You can't fit a square peg in a round hole. -- Per Jessen, Zürich (12.5°C) Suited for the job? You mean introduce more complexity to a problem that what could be avoided to begin with if PHP has thread support? hmmm -- 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 a...@ashleysheridan.co.uk wrote: On Wed, 2010-03-24 at 03:38 -0700, Tommy Pham wrote: On Wed, Mar 24, 2010 at 3:31 AM, Stuart Dallas stut...@gmail.com wrote: On 24 Mar 2010, at 10:24, Tommy Pham wrote: On Wed, Mar 24, 2010 at 2:58 AM, Stuart Dallas stut...@gmail.com 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 les...@lsces.co.uk 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 tommy...@gmail.com wrote: On Wed, Mar 24, 2010 at 3:44 AM, Per Jessen p...@computer.org wrote: Tommy Pham wrote: On Wed, Mar 24, 2010 at 3:20 AM, Per Jessen p...@computer.org wrote: Tommy Pham wrote: What I find funny is that one of opponents of PHP threads earlier mentioned that how silly it would be to be using C in a web app. Now I hear people mentioning C when they need productivity or speed... I think I was the one to mention the latter, but as I started out saying, and as others have said too, it's about the right tool for the right job. When choosing a tool, there are a number of factors to consider - developer productivity, available skills, future maintenance, performance, scalability, portability, parallelism, performance etcetera. Funny you should mention all that. Let's say that you're longer with that company, either by direct employment or contract consultant. You've implemented C because you need 'thread'. Now your replacement comes in and has no clue about C even though your replacement is a PHP guru. How much headache is maintenance gonna be? Scalability? Portability? wow Who was the idi... who hired someone who wasn't suited for the job? Tommy, that's a moot argument. You can't fit a square peg in a round hole. -- Per Jessen, Zürich (12.5°C) Suited for the job? You mean introduce more complexity to a problem that what could be avoided to begin with if PHP has thread support? hmmm 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 -- hype 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 /hype -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
