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 Thu, Mar 25, 2010 at 3:35 PM, Peter Lind wrote: > On 25 March 2010 23:23, Tommy Pham 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 25 March 2010 23:23, Tommy Pham 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 > > -- WWW: http://plphp.dk / http://plind.dk LinkedIn: http://www.linkedin.com/in/plind Flickr: http://www.flickr.com/photos/fake51 BeWelcome: Fake51 Couchsurfing: Fake51 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
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 Thu, Mar 25, 2010 at 3:04 PM, Tommy Pham wrote: > On Thu, Mar 25, 2010 at 1:50 PM, 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. >> >> > 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?
On Thu, Mar 25, 2010 at 1:50 PM, 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. > > 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 25 March 2010 22:51, Lester Caine 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 > > -- WWW: http://plphp.dk / http://plind.dk LinkedIn: http://www.linkedin.com/in/plind Flickr: http://www.flickr.com/photos/fake51 BeWelcome: Fake51 Couchsurfing: Fake51 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
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?
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?
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: > 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?
On 25 March 2010 20:59, Tommy Pham wrote: > On Thu, Mar 25, 2010 at 12:28 PM, Peter Lind wrote: >> On 25 March 2010 20:19, Tommy Pham 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. -- WWW: http://plphp.dk / http://plind.dk LinkedIn: http://www.linkedin.com/in/plind Flickr: http://www.flickr.com/photos/fake51 BeWelcome: Fake51 Couchsurfing: Fake51 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
On Thu, Mar 25, 2010 at 12:28 PM, Peter Lind wrote: > On 25 March 2010 20:19, Tommy Pham 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:19, Tommy Pham 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 :) -- WWW: http://plphp.dk / http://plind.dk LinkedIn: http://www.linkedin.com/in/plind Flickr: http://www.flickr.com/photos/fake51 BeWelcome: Fake51 Couchsurfing: Fake51 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
On Thu, Mar 25, 2010 at 12:11 PM, Ashley Sheridan wrote: > > On Thu, 2010-03-25 at 12:09 -0700, Tommy Pham wrote: > > On Thu, Mar 25, 2010 at 12:02 PM, Peter Lind wrote: > > On 25 March 2010 19:37, Tommy Pham wrote: > >> On Thu, Mar 25, 2010 at 3:55 AM, Per Jessen wrote: > >>> Tommy Pham wrote: > >>> > On Thu, Mar 25, 2010 at 1:46 AM, Per Jessen 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 Thu, Mar 25, 2010 at 12:13 PM, Peter Lind wrote: > On 25 March 2010 20:09, Tommy Pham wrote: >> On Thu, Mar 25, 2010 at 12:02 PM, Peter Lind wrote: >>> On 25 March 2010 19:37, Tommy Pham wrote: On Thu, Mar 25, 2010 at 3:55 AM, Per Jessen wrote: > Tommy Pham wrote: > >> On Thu, Mar 25, 2010 at 1:46 AM, Per Jessen 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, 2010-03-25 at 12:09 -0700, Tommy Pham wrote: > On Thu, Mar 25, 2010 at 12:02 PM, Peter Lind wrote: > > On 25 March 2010 19:37, Tommy Pham wrote: > >> On Thu, Mar 25, 2010 at 3:55 AM, Per Jessen wrote: > >>> Tommy Pham wrote: > >>> > On Thu, Mar 25, 2010 at 1:46 AM, Per Jessen 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 25 March 2010 20:09, Tommy Pham wrote: > On Thu, Mar 25, 2010 at 12:02 PM, Peter Lind wrote: >> On 25 March 2010 19:37, Tommy Pham wrote: >>> On Thu, Mar 25, 2010 at 3:55 AM, Per Jessen wrote: Tommy Pham wrote: > On Thu, Mar 25, 2010 at 1:46 AM, Per Jessen 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. -- WWW: http://plphp.dk / http://plind.dk LinkedIn: http://www.linkedin.com/in/plind Flickr: http://www.flickr.com/photos/fake51 BeWelcome: Fake51 Couchsurfing: Fake51 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
On Thu, Mar 25, 2010 at 12:02 PM, Peter Lind wrote: > On 25 March 2010 19:37, Tommy Pham wrote: >> On Thu, Mar 25, 2010 at 3:55 AM, Per Jessen wrote: >>> Tommy Pham wrote: >>> On Thu, Mar 25, 2010 at 1:46 AM, Per Jessen 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 19:37, Tommy Pham wrote: > On Thu, Mar 25, 2010 at 3:55 AM, Per Jessen wrote: >> Tommy Pham wrote: >> >>> On Thu, Mar 25, 2010 at 1:46 AM, Per Jessen 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 > > -- WWW: http://plphp.dk / http://plind.dk LinkedIn: http://www.linkedin.com/in/plind Flickr: http://www.flickr.com/photos/fake51 BeWelcome: Fake51 Couchsurfing: Fake51 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
On Thu, Mar 25, 2010 at 3:55 AM, Per Jessen wrote: > Tommy Pham wrote: > >> On Thu, Mar 25, 2010 at 1:46 AM, Per Jessen 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?
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 12:02 PM, Ashley Sheridan wrote: > 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-ATtrImCx4&ttl=1) who are likely to change the entire 3D stack (from graphicscard up).
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?
Tommy Pham wrote: > On Thu, Mar 25, 2010 at 1:46 AM, Per Jessen 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, Mar 25, 2010 at 1:46 AM, Per Jessen 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?
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?
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?
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 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?
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? - 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?
On Wed, Mar 24, 2010 at 11:42 PM, Stuart Dallas wrote: > On 24 Mar 2010, at 20:34, Rene Veerman wrote: >> >> On Wed, Mar 24, 2010 at 10:19 PM, Ashley Sheridan >> 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?
On Wed, 2010-03-24 at 21:21 -0400, Matt Giddings wrote: > ok, how do I get off this list? you either follow the instructions on the page that you used to sign up to the list, or send an email to the email address listed in header of all emails from the list. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [PHP] Will PHP ever "grow up" and have threading?
> > P.S. I HATE bottom posting. WTF do I have to scroll all the way down past > hundreds of useless lines just to read a "me too" or some other comment. If > it's at the top, I can simply just keep moving from header to header in > Outlook (or your email GUI of choice). DELETE as I go. Easy. Simple. > Efficient. > http://www.netmeister.org/news/learn2quote.html
RE: [PHP] Will PHP ever "grow up" and have threading?
You don't. It's like hotel california. You can check out any time you like, but you can never leave. ;-) > -Original Message- > From: Matt Giddings [mailto:mcgid...@svsu.edu] > Sent: Wednesday, March 24, 2010 6:22 PM > To: Matt Giddings > Cc: php-general@lists.php.net > Subject: Re: [PHP] Will PHP ever "grow up" and have threading? > > ok, how do I get off this list? > -- 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?
Matt Giddings wrote: unsubscribe *lol* -- 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?
ok, how do I get off this list?
Re: [PHP] Will PHP ever "grow up" and have threading?
unsubscribe
RE: [PHP] Will PHP ever "grow up" and have threading?
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". You do realize that just b/c PHP would have threading in it, doesn't mean you actually have to use it right? My PHP has all sorts of other libraries in it that I don't use. > 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 [And related] > 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... Amen. Case in point. I had a developer who wrote our back end in Ruby. It's nearly impossible to find an expert ruby developer. You can't swing a dead cat without hitting a Rails guy these days, but they don't know the nuts and bolts Ruby (we don't use Rails. We use PHP for the front end). > 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. Uh. Learning the concept of threads is TRIVIAL compared to learning an ENTIRE NEW LANGUAGE! Are you serious? Come on now guy. This argument is just contrived. > i really want to keep my code base in 1 language, because that > simplifies everything later on imo. > you people, who are against the evolotion of php towards cloud > computing, would force me to do mixed-languages projects or even > rewrite large sections of my codebase if as i want, i keep my codebase > in 1 language. Absolutely spot on. My company is standing still right now because we can't find a damn Ruby guy that can code to this level! Had PHP had threading, then we could have just used that for the back-end and front end. ...right tool for the job my ass. At a previous company I watched nearly the same thing happen. We were supposed to be sold for $25MM and when the due diligence came along and they saw we had written things in two languages (Ruby and PHP again actually, they declined on the last day and the company folded). They said it was too difficult to integrate into their software which used a third language. > 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. 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. > for some reason, which is still not clear to me, you nay-sayers refuse > to let a PROGRAMMING LANGUAGE (not a "hammer", not a "fishing boat") > evolve to stay useful, relevant even, in a changing market. > > and you're blatantly telling me to use a different kind of "hammer", > one that would force me to rewrite large sections of my existing > code-base, and one that i have told you i would find for many other > _valid_ reasons not optimal. 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. > The
RE: [PHP] Will PHP ever "grow up" and have threading? - vote.
> 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. -- 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- > And what you seem to be missing is that making PHP userspace > threaded is > such a major change to the underlying code base and > architecture that it > would essentially be a total and complete rewrite, and would require > people to rewrite large portions of their existing PHP userspace code. > > So it's either you adjust your code to fit the paradigm that PHP is > built for from the ground up, or the entire rest of the world adjusts > its code to fit the paradigm that you think you want to have. Very well said. Isn't this only a factor for code that actually USES the threads though? Wouldn't all code just keep working the same as always if no threads are introduced in any part of it (which by default would be all existing code to date? -Daevid. -- 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?
As some of you mention that implementing threads will make the DB work harder than the standard serial operations queries, let me ask you these then: * How often does your DB server(s)/cluster utilizes 100% CPU (SMP/MC), memory, and disk IO? * How long is the duration when 100% utilization occurs? * If you could implement threads and run those same queries in 2+ threads, the total time saved from queries execution is 1/2 sec or more, which is pass along as the total response time reduced. Is it worth it for you implement threads if you're a speed freak? (I remember a list member, not mentioning his name, does optimization of PHP coding for just microseconds. Do you think how much more he'd benefit from this?) * If the requests are executed in parallel, the sooner the request fulfillment completes, the faster it is to move to the next request and complete it right? -- 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:34 PM, Robert Cummings wrote: Tommy Pham wrote: On Wed, Mar 24, 2010 at 1:24 PM, Robert Cummings wrote: Tommy Pham wrote: On Wed, Mar 24, 2010 at 4:28 AM, Per Jessen wrote: Tommy Pham wrote: On Wed, Mar 24, 2010 at 3:44 AM, Per Jessen wrote: Tommy Pham wrote: On Wed, Mar 24, 2010 at 3:20 AM, Per Jessen wrote: Tommy Pham wrote: What I find funny is that one of opponents of PHP threads earlier mentioned that how silly it would be to be using C in a web app. Now I hear people mentioning C when they need "productivity" or "speed"... I think I was the one to mention the latter, but as I started out saying, and as others have said too, it's about the right tool for the right job. When choosing a tool, there are a number of factors to consider - developer productivity, available skills, future maintenance, performance, scalability, portability, parallelism, performance etcetera. Funny you should mention all that. Let's say that you're longer with that company, either by direct employment or contract consultant. You've implemented C because you need 'thread'. Now your replacement comes in and has no clue about C even though your replacement is a PHP guru. How much headache is maintenance gonna be? Scalability? Portability? wow Who was the idi... who hired someone who wasn't suited for the job? Tommy, that's a moot argument. You can't fit a square peg in a round hole. -- Per Jessen, Zürich (12.5°C) Suited for the job? You mean introduce more complexity to a problem that what could be avoided to begin with if PHP has thread support? hmmm Tommy, it's perfectly simple: in my company we hire people with C skills for C programming jobs. We hire people with database skills to be database administrators. We hire people with Linux skills to work on Linux systems. We explicitly do _not_ hire PHP web-programmers to maintain our C code. And vice versa for that matter. No problem, no complexity. -- Per Jessen, Zürich (13.4°C) That may just work out fine if you work directly for the company with all the proper staffing. But some of us work as consultants or for companies without the proper staffing. As such, let's dissect what you mentioned: 1) PHP with internal thread support 2) PHP with external C/C++ thread support * Performance - having external thread support, now you have to call an extension (more memory usage and CPU cycles). If you happen to have a C/C++ guru who can then code that thread support into PHP extension, wouldn't it still perform better at the core vs as an extension because it's not talking to a 'middle man'? Having said that, not everyone has access to a C/C++ guru. Thus not mass availability. Are you suggesting that you need to be a guru in C to write threaded C code? I think the word you're looking for is competent. * Portability - if you're currently running PHP on Windows, but manage to convince management to switch to *BSD/Linux, then you'd have to rewrite that external thread support. But for us consultants, we may have 1 project the runs on Windows, the next may be *BSD/Linux. PHP code snippets goes a lot further versus your custom work around. * Managability - should your need to upgrade PHP for either bug fix, new features you'd want to implement to add more functionality to your site, will that then break your custom external solution? How much more manageable is it if it's done under 1 language versus 2+? Are you suggesting cross platform thread libraries don't exist? I wonder how Apache does it... or MySQL... or any number of open source cross-platform systems. If they implement their own, then by the virtue of the source being open, you can feel free to incorporate. Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP Suppose I have an idea and make it a project. I'd then want to make it open source and offer it to the world. With your custom thread solution, how much acceptance is it going to be for a decent PHP programmer to implement versus something that's already in pure PHP. Unzip/rar/tar > minor config for DB > Live. How does that sound for portability? Now that you mention cross platform threading, do you think you can take the MySQL compiled for linux and make it work under BSD withouth BSD's linux binaries compatibility, nevermind Windows? Have you looked at the source of PHP? For whatever OS PHP compiles for, it uses the header library pertaining to that OS. So if I want to implement thread solution similar to Per's solution, I'd have to be an expert at Windows, Linux, and *BSD just to make my PHP open source project to be readily acceptable to the world. I'll pass on that. Many open source projects are itches being scratched. More often than not you will not be alone in your desire to scratch. When that happens, and if you're a good sort of chap or gal, then others will come along and help you scratch. Soon, with the right kin
Re: [PHP] Will PHP ever "grow up" and have threading?
On Wed, Mar 24, 2010 at 3:49 PM, Tommy Pham wrote: > On Wed, Mar 24, 2010 at 3:34 PM, Robert Cummings wrote: >> Tommy Pham wrote: >>> >>> On Wed, Mar 24, 2010 at 1:24 PM, Robert Cummings >>> wrote: Tommy Pham wrote: > > On Wed, Mar 24, 2010 at 4:28 AM, Per Jessen wrote: >> >> Tommy Pham wrote: >> >>> On Wed, Mar 24, 2010 at 3:44 AM, Per Jessen wrote: Tommy Pham wrote: > On Wed, Mar 24, 2010 at 3:20 AM, Per Jessen > wrote: >> >> Tommy Pham wrote: >> >>> What I find funny is that one of opponents of PHP threads earlier >>> mentioned that how silly it would be to be using C in a web app. >>> Now I hear people mentioning C when they need "productivity" or >>> "speed"... >>> >> I think I was the one to mention the latter, but as I started out >> saying, and as others have said too, it's about the right tool for >> the right job. When choosing a tool, there are a number of factors >> to consider - developer productivity, available skills, future >> maintenance, performance, scalability, portability, parallelism, >> performance etcetera. >> > Funny you should mention all that. Let's say that you're longer > with that company, either by direct employment or contract > consultant. You've implemented C because you need 'thread'. Now > your replacement comes in and has no clue about C even though your > replacement is a PHP guru. How much headache is maintenance gonna > be? Scalability? Portability? wow Who was the idi... who hired someone who wasn't suited for the job? Tommy, that's a moot argument. You can't fit a square peg in a round hole. -- Per Jessen, Zürich (12.5°C) >>> Suited for the job? You mean introduce more complexity to a problem >>> that what could be avoided to begin with if PHP has thread support? >>> hmmm >> >> Tommy, it's perfectly simple: in my company we hire people with C >> skills for C programming jobs. We hire people with database skills to >> be database administrators. We hire people with Linux skills to work >> on Linux systems. We explicitly do _not_ hire PHP web-programmers to >> maintain our C code. And vice versa for that matter. No problem, no >> complexity. >> >> >> -- >> Per Jessen, Zürich (13.4°C) >> >> > That may just work out fine if you work directly for the company with > all the proper staffing. But some of us work as consultants or for > companies without the proper staffing. As such, let's dissect what > you mentioned: > > 1) PHP with internal thread support > 2) PHP with external C/C++ thread support > > * Performance - having external thread support, now you have to call > an extension (more memory usage and CPU cycles). If you happen to > have a C/C++ guru who can then code that thread support into PHP > extension, wouldn't it still perform better at the core vs as an > extension because it's not talking to a 'middle man'? Having said > that, not everyone has access to a C/C++ guru. Thus not mass > availability. Are you suggesting that you need to be a guru in C to write threaded C code? I think the word you're looking for is competent. > * Portability - if you're currently running PHP on Windows, but manage > to convince management to switch to *BSD/Linux, then you'd have to > rewrite that external thread support. But for us consultants, we may > have 1 project the runs on Windows, the next may be *BSD/Linux. PHP > code snippets goes a lot further versus your custom work around. > * Managability - should your need to upgrade PHP for either bug fix, > new features you'd want to implement to add more functionality to your > site, will that then break your custom external solution? How much > more manageable is it if it's done under 1 language versus 2+? Are you suggesting cross platform thread libraries don't exist? I wonder how Apache does it... or MySQL... or any number of open source cross-platform systems. If they implement their own, then by the virtue of the source being open, you can feel free to incorporate. Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP >>> >>> Suppose I have an idea and make it a project. I'd then want to make >>> it open source and offer it to the world. With your custom thread >>> solution, how much acceptance is it going to be for a decent PHP >>> programmer to implement versus something that's already in pure PHP. >>> Unzip/rar/tar > minor config for DB > Live. How does that sound for >>> portability? Now
Re: [PHP] Will PHP ever "grow up" and have threading?
On Wed, Mar 24, 2010 at 3:34 PM, Robert Cummings wrote: > Tommy Pham wrote: >> >> On Wed, Mar 24, 2010 at 1:24 PM, Robert Cummings >> wrote: >>> >>> Tommy Pham wrote: On Wed, Mar 24, 2010 at 4:28 AM, Per Jessen wrote: > > Tommy Pham wrote: > >> On Wed, Mar 24, 2010 at 3:44 AM, Per Jessen wrote: >>> >>> Tommy Pham wrote: >>> On Wed, Mar 24, 2010 at 3:20 AM, Per Jessen wrote: > > Tommy Pham wrote: > >> What I find funny is that one of opponents of PHP threads earlier >> mentioned that how silly it would be to be using C in a web app. >> Now I hear people mentioning C when they need "productivity" or >> "speed"... >> > I think I was the one to mention the latter, but as I started out > saying, and as others have said too, it's about the right tool for > the right job. When choosing a tool, there are a number of factors > to consider - developer productivity, available skills, future > maintenance, performance, scalability, portability, parallelism, > performance etcetera. > Funny you should mention all that. Let's say that you're longer with that company, either by direct employment or contract consultant. You've implemented C because you need 'thread'. Now your replacement comes in and has no clue about C even though your replacement is a PHP guru. How much headache is maintenance gonna be? Scalability? Portability? wow >>> >>> Who was the idi... who hired someone who wasn't suited for the job? >>> Tommy, that's a moot argument. You can't fit a square peg in a round >>> hole. >>> >>> -- >>> Per Jessen, Zürich (12.5°C) >>> >> Suited for the job? You mean introduce more complexity to a problem >> that what could be avoided to begin with if PHP has thread support? >> hmmm > > Tommy, it's perfectly simple: in my company we hire people with C > skills for C programming jobs. We hire people with database skills to > be database administrators. We hire people with Linux skills to work > on Linux systems. We explicitly do _not_ hire PHP web-programmers to > maintain our C code. And vice versa for that matter. No problem, no > complexity. > > > -- > Per Jessen, Zürich (13.4°C) > > That may just work out fine if you work directly for the company with all the proper staffing. But some of us work as consultants or for companies without the proper staffing. As such, let's dissect what you mentioned: 1) PHP with internal thread support 2) PHP with external C/C++ thread support * Performance - having external thread support, now you have to call an extension (more memory usage and CPU cycles). If you happen to have a C/C++ guru who can then code that thread support into PHP extension, wouldn't it still perform better at the core vs as an extension because it's not talking to a 'middle man'? Having said that, not everyone has access to a C/C++ guru. Thus not mass availability. >>> >>> Are you suggesting that you need to be a guru in C to write threaded C >>> code? >>> I think the word you're looking for is competent. >>> * Portability - if you're currently running PHP on Windows, but manage to convince management to switch to *BSD/Linux, then you'd have to rewrite that external thread support. But for us consultants, we may have 1 project the runs on Windows, the next may be *BSD/Linux. PHP code snippets goes a lot further versus your custom work around. * Managability - should your need to upgrade PHP for either bug fix, new features you'd want to implement to add more functionality to your site, will that then break your custom external solution? How much more manageable is it if it's done under 1 language versus 2+? >>> >>> Are you suggesting cross platform thread libraries don't exist? I wonder >>> how >>> Apache does it... or MySQL... or any number of open source cross-platform >>> systems. If they implement their own, then by the virtue of the source >>> being >>> open, you can feel free to incorporate. >>> >>> Cheers, >>> Rob. >>> -- >>> http://www.interjinn.com >>> Application and Templating Framework for PHP >>> >> >> Suppose I have an idea and make it a project. I'd then want to make >> it open source and offer it to the world. With your custom thread >> solution, how much acceptance is it going to be for a decent PHP >> programmer to implement versus something that's already in pure PHP. >> Unzip/rar/tar > minor config for DB > Live. How does that sound for >> portability? Now that you mention cross platform threading, do you >> think you can take the MySQL compiled for linux and make it work under >> BSD withouth BSD's linux binaries comp
Re: [PHP] Will PHP ever "grow up" and have threading?
Tommy Pham wrote: On Wed, Mar 24, 2010 at 1:24 PM, Robert Cummings wrote: Tommy Pham wrote: On Wed, Mar 24, 2010 at 4:28 AM, Per Jessen wrote: Tommy Pham wrote: On Wed, Mar 24, 2010 at 3:44 AM, Per Jessen wrote: Tommy Pham wrote: On Wed, Mar 24, 2010 at 3:20 AM, Per Jessen wrote: Tommy Pham wrote: What I find funny is that one of opponents of PHP threads earlier mentioned that how silly it would be to be using C in a web app. Now I hear people mentioning C when they need "productivity" or "speed"... I think I was the one to mention the latter, but as I started out saying, and as others have said too, it's about the right tool for the right job. When choosing a tool, there are a number of factors to consider - developer productivity, available skills, future maintenance, performance, scalability, portability, parallelism, performance etcetera. Funny you should mention all that. Let's say that you're longer with that company, either by direct employment or contract consultant. You've implemented C because you need 'thread'. Now your replacement comes in and has no clue about C even though your replacement is a PHP guru. How much headache is maintenance gonna be? Scalability? Portability? wow Who was the idi... who hired someone who wasn't suited for the job? Tommy, that's a moot argument. You can't fit a square peg in a round hole. -- Per Jessen, Zürich (12.5°C) Suited for the job? You mean introduce more complexity to a problem that what could be avoided to begin with if PHP has thread support? hmmm Tommy, it's perfectly simple: in my company we hire people with C skills for C programming jobs. We hire people with database skills to be database administrators. We hire people with Linux skills to work on Linux systems. We explicitly do _not_ hire PHP web-programmers to maintain our C code. And vice versa for that matter. No problem, no complexity. -- Per Jessen, Zürich (13.4°C) That may just work out fine if you work directly for the company with all the proper staffing. But some of us work as consultants or for companies without the proper staffing. As such, let's dissect what you mentioned: 1) PHP with internal thread support 2) PHP with external C/C++ thread support * Performance - having external thread support, now you have to call an extension (more memory usage and CPU cycles). If you happen to have a C/C++ guru who can then code that thread support into PHP extension, wouldn't it still perform better at the core vs as an extension because it's not talking to a 'middle man'? Having said that, not everyone has access to a C/C++ guru. Thus not mass availability. Are you suggesting that you need to be a guru in C to write threaded C code? I think the word you're looking for is competent. * Portability - if you're currently running PHP on Windows, but manage to convince management to switch to *BSD/Linux, then you'd have to rewrite that external thread support. But for us consultants, we may have 1 project the runs on Windows, the next may be *BSD/Linux. PHP code snippets goes a lot further versus your custom work around. * Managability - should your need to upgrade PHP for either bug fix, new features you'd want to implement to add more functionality to your site, will that then break your custom external solution? How much more manageable is it if it's done under 1 language versus 2+? Are you suggesting cross platform thread libraries don't exist? I wonder how Apache does it... or MySQL... or any number of open source cross-platform systems. If they implement their own, then by the virtue of the source being open, you can feel free to incorporate. Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP Suppose I have an idea and make it a project. I'd then want to make it open source and offer it to the world. With your custom thread solution, how much acceptance is it going to be for a decent PHP programmer to implement versus something that's already in pure PHP. Unzip/rar/tar > minor config for DB > Live. How does that sound for portability? Now that you mention cross platform threading, do you think you can take the MySQL compiled for linux and make it work under BSD withouth BSD's linux binaries compatibility, nevermind Windows? Have you looked at the source of PHP? For whatever OS PHP compiles for, it uses the header library pertaining to that OS. So if I want to implement thread solution similar to Per's solution, I'd have to be an expert at Windows, Linux, and *BSD just to make my PHP open source project to be readily acceptable to the world. I'll pass on that. Many open source projects are itches being scratched. More often than not you will not be alone in your desire to scratch. When that happens, and if you're a good sort of chap or gal, then others will come along and help you scratch. Soon, with the right kind of leadership and gameplan, you'll be fully embroiled in a scratching
Re: [PHP] Will PHP ever "grow up" and have threading?
On Wed, Mar 24, 2010 at 1:24 PM, Robert Cummings wrote: > > > Tommy Pham wrote: >> >> On Wed, Mar 24, 2010 at 4:28 AM, Per Jessen wrote: >>> >>> Tommy Pham wrote: >>> On Wed, Mar 24, 2010 at 3:44 AM, Per Jessen wrote: > > Tommy Pham wrote: > >> On Wed, Mar 24, 2010 at 3:20 AM, Per Jessen >> wrote: >>> >>> Tommy Pham wrote: >>> What I find funny is that one of opponents of PHP threads earlier mentioned that how silly it would be to be using C in a web app. Now I hear people mentioning C when they need "productivity" or "speed"... >>> I think I was the one to mention the latter, but as I started out >>> saying, and as others have said too, it's about the right tool for >>> the right job. When choosing a tool, there are a number of factors >>> to consider - developer productivity, available skills, future >>> maintenance, performance, scalability, portability, parallelism, >>> performance etcetera. >>> >> Funny you should mention all that. Let's say that you're longer >> with that company, either by direct employment or contract >> consultant. You've implemented C because you need 'thread'. Now >> your replacement comes in and has no clue about C even though your >> replacement is a PHP guru. How much headache is maintenance gonna >> be? Scalability? Portability? wow > > Who was the idi... who hired someone who wasn't suited for the job? > Tommy, that's a moot argument. You can't fit a square peg in a round > hole. > > -- > Per Jessen, Zürich (12.5°C) > Suited for the job? You mean introduce more complexity to a problem that what could be avoided to begin with if PHP has thread support? hmmm >>> >>> Tommy, it's perfectly simple: in my company we hire people with C >>> skills for C programming jobs. We hire people with database skills to >>> be database administrators. We hire people with Linux skills to work >>> on Linux systems. We explicitly do _not_ hire PHP web-programmers to >>> maintain our C code. And vice versa for that matter. No problem, no >>> complexity. >>> >>> >>> -- >>> Per Jessen, Zürich (13.4°C) >>> >>> >> >> That may just work out fine if you work directly for the company with >> all the proper staffing. But some of us work as consultants or for >> companies without the proper staffing. As such, let's dissect what >> you mentioned: >> >> 1) PHP with internal thread support >> 2) PHP with external C/C++ thread support >> >> * Performance - having external thread support, now you have to call >> an extension (more memory usage and CPU cycles). If you happen to >> have a C/C++ guru who can then code that thread support into PHP >> extension, wouldn't it still perform better at the core vs as an >> extension because it's not talking to a 'middle man'? Having said >> that, not everyone has access to a C/C++ guru. Thus not mass >> availability. > > Are you suggesting that you need to be a guru in C to write threaded C code? > I think the word you're looking for is competent. > >> * Portability - if you're currently running PHP on Windows, but manage >> to convince management to switch to *BSD/Linux, then you'd have to >> rewrite that external thread support. But for us consultants, we may >> have 1 project the runs on Windows, the next may be *BSD/Linux. PHP >> code snippets goes a lot further versus your custom work around. >> * Managability - should your need to upgrade PHP for either bug fix, >> new features you'd want to implement to add more functionality to your >> site, will that then break your custom external solution? How much >> more manageable is it if it's done under 1 language versus 2+? > > Are you suggesting cross platform thread libraries don't exist? I wonder how > Apache does it... or MySQL... or any number of open source cross-platform > systems. If they implement their own, then by the virtue of the source being > open, you can feel free to incorporate. > > Cheers, > Rob. > -- > http://www.interjinn.com > Application and Templating Framework for PHP > Suppose I have an idea and make it a project. I'd then want to make it open source and offer it to the world. With your custom thread solution, how much acceptance is it going to be for a decent PHP programmer to implement versus something that's already in pure PHP. Unzip/rar/tar > minor config for DB > Live. How does that sound for portability? Now that you mention cross platform threading, do you think you can take the MySQL compiled for linux and make it work under BSD withouth BSD's linux binaries compatibility, nevermind Windows? Have you looked at the source of PHP? For whatever OS PHP compiles for, it uses the header library pertaining to that OS. So if I want to implement thread solution similar to Per's solution, I'd have to be an expert at Windows, Linux, and *BSD just to make my PHP open source project
Re: [PHP] Will PHP ever "grow up" and have threading?
On 24 Mar 2010, at 20:42, Rene Veerman wrote: > > if you ppl just stop barracading, you'll see that with relatively > minimal effort php can evolve with the times and make such things > possible for us mere mortals. Minimal effort? You clearly have no understanding of what would be involved to get threading into the PHP core. It's not a minimal amount of effort, it means severe upheaval, not only for the core itself but also for every extension in existence, and potentially a fair amount of userland code that's out there. Oh, and I absolutely love the fact you think it's we who are barricading. Love it! -Stuart -- http://stut.net/ -- 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 20:34, Rene Veerman wrote: > > On Wed, Mar 24, 2010 at 10:19 PM, Ashley Sheridan > wrote: > On Wed, 2010-03-24 at 22:15 +0200, Rene Veerman wrote: > Do you have any proof of this 'market trend'? I suggested a vote, but you > 'nay-sayed' it on the basis that you'd lose to people who couldn't possibly > know as much as you do. > > > yes, twitter. facebook. the fact that a graphics upgrade would likely > increase business for the first ones on that popularity level to implement it. > that's the proof i have for the market trend. Again, improving the graphical content of a website has absolutely no effect on the performance of PHP. The additional time the page takes to load is all about network latency and how well you've arranged your static file serving. > oh, and the fact "cloud computing" is becoming more and more of a buzzword in > the industry. Cloud computing really doesn't mean what you think it means. >> I wouldn't say I belonged to any particular camp at the start of this >> thread, but now, having read what my betters have said, I'm inclined to >> agree that threading isn't the magic wand that you seem to think it is. I >> personally see one of the largest sites in the world running on PHP without >> needing threading and without insulting half the list to attempt to get it. > > you haven't offered me any description at all of how i'd solve the > large-scale realtime-web-app with existing techniques. By "realtime-web-app" you mean something like Facebook? They use a combination of PHP, Memcached (and lots of it), MySQL and lots of other layers in-between to do what they do, and threaded PHP is not one of them. > and if i explain why i'd need the features we've discussed, you dismiss it by > accepting a generalized "that can be solved with more sql servers" answer > that is admitted to increase costs in every department, including energy > consumption. on a non-linear scale btw. What I'm getting here is that you want everything without paying for it. When it comes to scalability it's cheaper to achieve it by adding servers than it is to squeeze every last drop of performance out of a single box. The cost in development time alone to implement effective threading strategies would far outstrip the cost of adding a couple of servers and ensuring that your app is scalable. What you seem to be ignoring is the fact that these issues have been solved already, and the techniques that exist are more than adequate to build systems that scale as well as Facebook. What will it take to get you to accept that the way you want to skin the cat is exceedingly messy? -Stuart -- http://stut.net/ -- 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 19:42, Tommy Pham wrote: > On Wed, Mar 24, 2010 at 10:18 AM, Sancar Saran > wrote: >> On Wednesday 24 March 2010 03:17:56 Tommy Pham wrote: >>> Let's go back to my 1st e-commerce example. The manufacturers list is >>> about 3,700. The categories is about about 2,400. The products list >>> is right now at 500,000 and expected to be around 750,000. The site >>> is only in English. The store owner wants to expand and be I18n: >>> Chinese, French, German, Korean, Spanish. You see how big and complex >>> that database gets? The store owners want to have this happens when a >>> customer clicks on a category: >>> >>> * show all subcategories for that category, if any Cache it in something like memcached - I doubt these change very often. >>> * show all products for that category, if any, Cache it in something like memcached, and update that cache when products change. >>> * show all manufacturers, used as filtering, for that category and >>> subcategories Cache it. >>> * show price range filter for that category No need to cache this. >>> * show features & specifications filter for that category Cache it. >>> * show 10 top sellers for that category and related subcategories Generate offline and cache it. >>> * the shopper can then select/deselect any of those filters and >>> ability to sort by manufacturers, prices, user rating, popularity >>> (purchased quantity) Use something like Sphinx to handle searching the data. It's far quicker for doing filtering like this than SQL. >>> * have the ability to switch to another language translation on the fly Doing this would simply change a prefix to the cache keys. >>> * from the moment the shopper click on a link, the response time (when >>> web browser saids "Done" in the status bar) is 5 seconds or less. >>> Preferably 2-3 seconds. Will be using stopwatch for the timer. I run a site that does very similar operations to this and response times average around 0.1s with the cache on, and 3-5ss with it off. Oh, and using a stopwatch doesn't take into account network latency or external dependencies. If you want an accurate timings you need to add that functionality into the code. >>> Now show me a website that meets those requirements and uses PHP, I'll >>> be glad to support your argument about PHP w/o threads :) BTW, this >>> is not even enterprise requirement. I may have another possible >>> project where # products is over 10 million easily. With similar >>> requirements when the user click on category. Do you think this site, >>> which currently isn't, can run on PHP? You want an example? Facebook! -Stuart -- http://stut.net/ -- 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 19:35, Rene Veerman wrote: > > take this example, sorry for the crosspost; > > my main concern atm is my own cms (50-100k lines of my own); it's > graphics-heavy, does fairly complicated db based logic, and if it ever > is to be used for a site like facebook, it'll get large dataflows that > have to be distributed over the servers used to generate html and > accessoiries for end-users. > i've built a layer into it that caches the output of oft-used pages > (like articles and their comments). > but adding many comments / minute to an article would result in quite > a bit of overhead, to update the html for that page and distribute it > (fast enough) to the relevant servers. > > i'm worried about php's single-threaded nature; each request has to > fetch html updated in the last few seconds, or generate it from a list > of comments. that's also a big query from a big table for every > end-user.. :( > i'd rather keep them comments for an article in shared memory. Shared memory in PHP generally means memcached. Look it up - it does exactly what you need here, and with the right usage strategy it's more than capable of handling data that changes many times a second. I think I'll need to spell this out, and I really hope you'll read this one properly. Use memcached to store data in the format in which you need to access it, update it when something changes not when requested and use the DB as permanent storage only. I've written highly scalable systems using this strategy, and the possibility that threading could improve the performance of said systems has never spent longer than a few seconds crossing my mind. And, if you don't mind me asking, when you say graphics-heavy do you mean it uses a lot of images? And if so, how the hell does that affect the scalability of PHP? -Stuart -- http://stut.net/ -- 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: On Wed, Mar 24, 2010 at 10:24 PM, Robert Cummings wrote: Are you suggesting that you need to be a guru in C to write threaded C code? I think the word you're looking for is competent. plz dont make me repeat myself, i've already indicated my reasons as to why i want to keep my codebase in 1 language, The above comment did not address your codebase and 1 language issue. It addressed the assertion that you need a C guru to write threaded C code. and why i would like to keep my large existing code base in php, and have php evolve with the times, and allow applications written in it to grow easily to large scale use. it would expand the user base of php as well i think. I think I'm going to win the lottery some day... I think. Are you suggesting cross platform thread libraries don't exist? I wonder how Apache does it... or MySQL... or any number of open source cross-platform systems. If they implement their own, then by the virtue of the source being open, you can feel free to incorporate. adding all these things as custom extensions that are hard to maintain and increase software complexity, is not what i want. the reason i chose php is for it's simplicity of use. Perhaps you should have chosen based on the functionality YOU want. PHP remains simple for a reason. I think this will be me last comment to you. Your responses don't stay on track, they keep leading back to your constant "I want, I want, I want" screams. Let's list a few: I want to use PHP. I want threading in PHP. I want someone else to do it. I want to not have to change my designs. I want everyone to stop having their own opinion. I want to have my cake and eat it too. Ummm... so yeah... I can see why the discussion is mostly degenerative. Have you even subscribed to the internals list yet? Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP -- 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 Wednesday 24 March 2010 22:42:17 Rene Veerman wrote: > On Wed, Mar 24, 2010 at 10:34 PM, Sancar Saran wrote: > > On Wednesday 24 March 2010 21:42:53 Tommy Pham wrote: > >> On Wed, Mar 24, 2010 at 10:18 AM, Sancar Saran > > > > wrote: > >> > On Wednesday 24 March 2010 03:17:56 Tommy Pham wrote: > >> >> Let's go back to my 1st e-commerce example. The manufacturers list > >> >> is about 3,700. The categories is about about 2,400. The products > >> >> list is right now at 500,000 and expected to be around 750,000. The > >> >> site is only in English. The store owner wants to expand and be > >> >> I18n: Chinese, French, German, Korean, Spanish. You see how big and > >> >> complex that database gets? The store owners want to have this > >> >> happens when a customer clicks on a category: > >> >> > >> >> * show all subcategories for that category, if any > >> >> * show all products for that category, if any, > >> >> * show all manufacturers, used as filtering, for that category and > >> >> subcategories * show price range filter for that category > >> >> * show features & specifications filter for that category > >> >> * show 10 top sellers for that category and related subcategories > >> >> * the shopper can then select/deselect any of those filters and > >> >> ability to sort by manufacturers, prices, user rating, popularity > >> >> (purchased quantity) > >> >> * have the ability to switch to another language translation on the > >> >> fly * from the moment the shopper click on a link, the response time > >> >> (when web browser saids "Done" in the status bar) is 5 seconds or > >> >> less. Preferably 2-3 seconds. Will be using stopwatch for the timer. > >> >> > >> >> Now show me a website that meets those requirements and uses PHP, > >> >> I'll be glad to support your argument about PHP w/o threads :) BTW, > >> >> this is not even enterprise requirement. I may have another > >> >> possible project where # products is over 10 million easily. With > >> >> similar requirements when the user click on category. Do you think > >> >> this site, which currently isn't, can run on PHP? > >> >> > >> >> Regards, > >> >> Tommy > >> > > >> > If you design and code correctly. Yes. > >> > > >> > > >> > If you want to use someting alredy. Try TYPO3. > >> > > >> > PS: Your arguments are something about implementation not something > >> > about platform abilities. You can do this things any server side > >> > programming with enough hardware. > >> > > >> > Regards > >> > > >> > Sancar > >> > >> Platform abilities = PHP with/without threads. > >> Implementation = If PHP has threads, how do I implement it. If not, > >> what work around / hacks do I need to do. > > > > Please forgive my low ability on English and you sound like. > > > > "I can drive a car, if it has a diesel engine and we want Ferrari for our > > need. Is there any way to fit a diesel engine in Ferrari ?" > > > > Your problem isn't php, You problem is your way to think... > > > > You are trying to bend php to fit your way of the building web sites. > > > > I'm sorry, things does not work like that. > > > > You are trying to represent your business logic as "ENTERPRISE SOFTWARE > > STANDARTS". > > > > I'm sorry, it wont ! > > > > Even with provocative subject, it still business logic at large. > > > > On Large Web sites, Site has own standards which enterprise must have to > > obey.. (like Facebook or any other uber number cruncher you name it) > > > > Anyway... > > > > You want to build a damn huge web site with damn huge data set and damn > > huge requests per second. > > > > and you still want to use that SQL for primary data store for reading. > > > > ARE YOU NUTS ??? > > > > With this kind of approach, > > > > You will be in deep trouble with any language, with any Reational SQL > > Server. > > > > If your customers need that kind of thing. You need lots of sophisticated > > people which know how to handle big things under web enviroment. > > > > Good luck to you. > > > > Regards > > how dramatic. > how elitist. > > and btw, use of sql where other solutions (like shared mem and > threading!) is exactly what i'm against. > > if you ppl just stop barracading, you'll see that with relatively > minimal effort php can evolve with the times and make such things > possible for us mere mortals. Alright. Lets think different. And please don't take things personal... If the only problem is threading... Will Python with mod wsgi solve the problem ? with this programming approach ? Regards Sancar... -- 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: >and btw, use of sql where other solutions (like shared mem and threading!) is >exactly what i'm against. should read "where other solutions (...) are very likely to work better / more efficiently".. On Wed, Mar 24, 2010 at 10:42 PM, Rene Veerman wrote: > On Wed, Mar 24, 2010 at 10:34 PM, Sancar Saran > wrote: >> On Wednesday 24 March 2010 21:42:53 Tommy Pham wrote: >>> On Wed, Mar 24, 2010 at 10:18 AM, Sancar Saran >> wrote: >>> > On Wednesday 24 March 2010 03:17:56 Tommy Pham wrote: >>> >> Let's go back to my 1st e-commerce example. The manufacturers list is >>> >> about 3,700. The categories is about about 2,400. The products list >>> >> is right now at 500,000 and expected to be around 750,000. The site >>> >> is only in English. The store owner wants to expand and be I18n: >>> >> Chinese, French, German, Korean, Spanish. You see how big and complex >>> >> that database gets? The store owners want to have this happens when a >>> >> customer clicks on a category: >>> >> >>> >> * show all subcategories for that category, if any >>> >> * show all products for that category, if any, >>> >> * show all manufacturers, used as filtering, for that category and >>> >> subcategories * show price range filter for that category >>> >> * show features & specifications filter for that category >>> >> * show 10 top sellers for that category and related subcategories >>> >> * the shopper can then select/deselect any of those filters and >>> >> ability to sort by manufacturers, prices, user rating, popularity >>> >> (purchased quantity) >>> >> * have the ability to switch to another language translation on the fly >>> >> * from the moment the shopper click on a link, the response time (when >>> >> web browser saids "Done" in the status bar) is 5 seconds or less. >>> >> Preferably 2-3 seconds. Will be using stopwatch for the timer. >>> >> >>> >> Now show me a website that meets those requirements and uses PHP, I'll >>> >> be glad to support your argument about PHP w/o threads :) BTW, this >>> >> is not even enterprise requirement. I may have another possible >>> >> project where # products is over 10 million easily. With similar >>> >> requirements when the user click on category. Do you think this site, >>> >> which currently isn't, can run on PHP? >>> >> >>> >> Regards, >>> >> Tommy >>> > >>> > If you design and code correctly. Yes. >>> > >>> > >>> > If you want to use someting alredy. Try TYPO3. >>> > >>> > PS: Your arguments are something about implementation not something about >>> > platform abilities. You can do this things any server side programming >>> > with enough hardware. >>> > >>> > Regards >>> > >>> > Sancar >>> >>> Platform abilities = PHP with/without threads. >>> Implementation = If PHP has threads, how do I implement it. If not, >>> what work around / hacks do I need to do. >> >> >> Please forgive my low ability on English and you sound like. >> >> "I can drive a car, if it has a diesel engine and we want Ferrari for our >> need. Is there any way to fit a diesel engine in Ferrari ?" >> >> Your problem isn't php, You problem is your way to think... >> >> You are trying to bend php to fit your way of the building web sites. >> >> I'm sorry, things does not work like that. >> >> You are trying to represent your business logic as "ENTERPRISE SOFTWARE >> STANDARTS". >> >> I'm sorry, it wont ! >> >> Even with provocative subject, it still business logic at large. >> >> On Large Web sites, Site has own standards which enterprise must have to >> obey.. (like Facebook or any other uber number cruncher you name it) >> >> Anyway... >> >> You want to build a damn huge web site with damn huge data set and damn huge >> requests per second. >> >> and you still want to use that SQL for primary data store for reading. >> >> ARE YOU NUTS ??? >> >> With this kind of approach, >> >> You will be in deep trouble with any language, with any Reational SQL Server. >> >> If your customers need that kind of thing. You need lots of sophisticated >> people which know how to handle big things under web enviroment. >> >> Good luck to you. >> >> Regards >> > > how dramatic. > how elitist. > > and btw, use of sql where other solutions (like shared mem and > threading!) is exactly what i'm against. > > if you ppl just stop barracading, you'll see that with relatively > minimal effort php can evolve with the times and make such things > possible for us mere mortals. > -- 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:34 PM, Sancar Saran wrote: > On Wednesday 24 March 2010 21:42:53 Tommy Pham wrote: >> On Wed, Mar 24, 2010 at 10:18 AM, Sancar Saran > wrote: >> > On Wednesday 24 March 2010 03:17:56 Tommy Pham wrote: >> >> Let's go back to my 1st e-commerce example. The manufacturers list is >> >> about 3,700. The categories is about about 2,400. The products list >> >> is right now at 500,000 and expected to be around 750,000. The site >> >> is only in English. The store owner wants to expand and be I18n: >> >> Chinese, French, German, Korean, Spanish. You see how big and complex >> >> that database gets? The store owners want to have this happens when a >> >> customer clicks on a category: >> >> >> >> * show all subcategories for that category, if any >> >> * show all products for that category, if any, >> >> * show all manufacturers, used as filtering, for that category and >> >> subcategories * show price range filter for that category >> >> * show features & specifications filter for that category >> >> * show 10 top sellers for that category and related subcategories >> >> * the shopper can then select/deselect any of those filters and >> >> ability to sort by manufacturers, prices, user rating, popularity >> >> (purchased quantity) >> >> * have the ability to switch to another language translation on the fly >> >> * from the moment the shopper click on a link, the response time (when >> >> web browser saids "Done" in the status bar) is 5 seconds or less. >> >> Preferably 2-3 seconds. Will be using stopwatch for the timer. >> >> >> >> Now show me a website that meets those requirements and uses PHP, I'll >> >> be glad to support your argument about PHP w/o threads :) BTW, this >> >> is not even enterprise requirement. I may have another possible >> >> project where # products is over 10 million easily. With similar >> >> requirements when the user click on category. Do you think this site, >> >> which currently isn't, can run on PHP? >> >> >> >> Regards, >> >> Tommy >> > >> > If you design and code correctly. Yes. >> > >> > >> > If you want to use someting alredy. Try TYPO3. >> > >> > PS: Your arguments are something about implementation not something about >> > platform abilities. You can do this things any server side programming >> > with enough hardware. >> > >> > Regards >> > >> > Sancar >> >> Platform abilities = PHP with/without threads. >> Implementation = If PHP has threads, how do I implement it. If not, >> what work around / hacks do I need to do. > > > Please forgive my low ability on English and you sound like. > > "I can drive a car, if it has a diesel engine and we want Ferrari for our > need. Is there any way to fit a diesel engine in Ferrari ?" > > Your problem isn't php, You problem is your way to think... > > You are trying to bend php to fit your way of the building web sites. > > I'm sorry, things does not work like that. > > You are trying to represent your business logic as "ENTERPRISE SOFTWARE > STANDARTS". > > I'm sorry, it wont ! > > Even with provocative subject, it still business logic at large. > > On Large Web sites, Site has own standards which enterprise must have to > obey.. (like Facebook or any other uber number cruncher you name it) > > Anyway... > > You want to build a damn huge web site with damn huge data set and damn huge > requests per second. > > and you still want to use that SQL for primary data store for reading. > > ARE YOU NUTS ??? > > With this kind of approach, > > You will be in deep trouble with any language, with any Reational SQL Server. > > If your customers need that kind of thing. You need lots of sophisticated > people which know how to handle big things under web enviroment. > > Good luck to you. > > Regards > how dramatic. how elitist. and btw, use of sql where other solutions (like shared mem and threading!) is exactly what i'm against. if you ppl just stop barracading, you'll see that with relatively minimal effort php can evolve with the times and make such things possible for us mere mortals. -- 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:24 PM, Robert Cummings wrote: > Are you suggesting that you need to be a guru in C to write threaded C code? > I think the word you're looking for is competent. plz dont make me repeat myself, i've already indicated my reasons as to why i want to keep my codebase in 1 language, and why i would like to keep my large existing code base in php, and have php evolve with the times, and allow applications written in it to grow easily to large scale use. it would expand the user base of php as well i think. > Are you suggesting cross platform thread libraries don't exist? I wonder how > Apache does it... or MySQL... or any number of open source cross-platform > systems. If they implement their own, then by the virtue of the source being > open, you can feel free to incorporate. adding all these things as custom extensions that are hard to maintain and increase software complexity, is not what i want. the reason i chose php is for it's simplicity of use. -- 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:19 PM, Ashley Sheridan wrote: > On Wed, 2010-03-24 at 22:15 +0200, Rene Veerman wrote: > > On Wed, Mar 24, 2010 at 10:05 PM, Ashley Sheridan > wrote: > > > > > > > So you're basically saying that you'd discount anyone who opposes you > > purely because you think you know best? > > > > Nice attitude. > > > > I ain't saying that at all, nor did i intend to imply it. > > In fact it's the anti-threading/shared-mem camp that thinks they know > everything best with their instistance that "throw more hardware at it, more > sql servers, more programming languages in a single project" will solve all > software design / growth problems with enough efficiency. > > They're offering the alternative. You keep disagreeing with their viewpoint > because you seem to think you know best on this matter and won't even > concede on a point. > they're offering an alternative that would not solve the use-case i could think of within 1 day.. and they also say 'add more hardware' which means more overhead of every kind, resulting in wasteful business practices. > In this case, you still haven't given me any other reason to oppose the > evolution of php with the market trend > > Do you have any proof of this 'market trend'? I suggested a vote, but you > 'nay-sayed' it on the basis that you'd lose to people who couldn't possibly > know as much as you do. > yes, twitter. facebook. the fact that a graphics upgrade would likely increase business for the first ones on that popularity level to implement it. that's the proof i have for the market trend. oh, and the fact "cloud computing" is becoming more and more of a buzzword in the industry. > > I wouldn't say I belonged to any particular camp at the start of this > thread, but now, having read what my betters have said, I'm inclined to > agree that threading isn't the magic wand that you seem to think it is. I > personally see one of the largest sites in the world running on PHP without > needing threading and without insulting half the list to attempt to get it. > > you haven't offered me any description at all of how i'd solve the large-scale realtime-web-app with existing techniques. and if i explain why i'd need the features we've discussed, you dismiss it by accepting a generalized "that can be solved with more sql servers" answer that is admitted to increase costs in every department, including energy consumption. on a non-linear scale btw.
Re: [PHP] Will PHP ever "grow up" and have threading?
On Wednesday 24 March 2010 21:42:53 Tommy Pham wrote: > On Wed, Mar 24, 2010 at 10:18 AM, Sancar Saran wrote: > > On Wednesday 24 March 2010 03:17:56 Tommy Pham wrote: > >> Let's go back to my 1st e-commerce example. The manufacturers list is > >> about 3,700. The categories is about about 2,400. The products list > >> is right now at 500,000 and expected to be around 750,000. The site > >> is only in English. The store owner wants to expand and be I18n: > >> Chinese, French, German, Korean, Spanish. You see how big and complex > >> that database gets? The store owners want to have this happens when a > >> customer clicks on a category: > >> > >> * show all subcategories for that category, if any > >> * show all products for that category, if any, > >> * show all manufacturers, used as filtering, for that category and > >> subcategories * show price range filter for that category > >> * show features & specifications filter for that category > >> * show 10 top sellers for that category and related subcategories > >> * the shopper can then select/deselect any of those filters and > >> ability to sort by manufacturers, prices, user rating, popularity > >> (purchased quantity) > >> * have the ability to switch to another language translation on the fly > >> * from the moment the shopper click on a link, the response time (when > >> web browser saids "Done" in the status bar) is 5 seconds or less. > >> Preferably 2-3 seconds. Will be using stopwatch for the timer. > >> > >> Now show me a website that meets those requirements and uses PHP, I'll > >> be glad to support your argument about PHP w/o threads :) BTW, this > >> is not even enterprise requirement. I may have another possible > >> project where # products is over 10 million easily. With similar > >> requirements when the user click on category. Do you think this site, > >> which currently isn't, can run on PHP? > >> > >> Regards, > >> Tommy > > > > If you design and code correctly. Yes. > > > > > > If you want to use someting alredy. Try TYPO3. > > > > PS: Your arguments are something about implementation not something about > > platform abilities. You can do this things any server side programming > > with enough hardware. > > > > Regards > > > > Sancar > > Platform abilities = PHP with/without threads. > Implementation = If PHP has threads, how do I implement it. If not, > what work around / hacks do I need to do. Please forgive my low ability on English and you sound like. "I can drive a car, if it has a diesel engine and we want Ferrari for our need. Is there any way to fit a diesel engine in Ferrari ?" Your problem isn't php, You problem is your way to think... You are trying to bend php to fit your way of the building web sites. I'm sorry, things does not work like that. You are trying to represent your business logic as "ENTERPRISE SOFTWARE STANDARTS". I'm sorry, it wont ! Even with provocative subject, it still business logic at large. On Large Web sites, Site has own standards which enterprise must have to obey.. (like Facebook or any other uber number cruncher you name it) Anyway... You want to build a damn huge web site with damn huge data set and damn huge requests per second. and you still want to use that SQL for primary data store for reading. ARE YOU NUTS ??? With this kind of approach, You will be in deep trouble with any language, with any Reational SQL Server. If your customers need that kind of thing. You need lots of sophisticated people which know how to handle big things under web enviroment. Good luck to you. Regards Sancar -- 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: On Wed, Mar 24, 2010 at 10:21 PM, Robert Cummings wrote: Rene Veerman wrote: On Wed, Mar 24, 2010 at 9:45 PM, Robert Cummings wrote: Rene Veerman wrote: On Wed, Mar 24, 2010 at 9:31 PM, Robert Cummings wrote: Rene Veerman wrote: On Wed, Mar 24, 2010 at 3:25 PM, Robert Cummings wrote: Rene Veerman wrote: php is not a hammer, its a programming language. It's hard to discuss anything with someone who doesn't comprehend a metaphor. haha. "comprehend". you mean "accept". that metaphor is stretched to breaking point as far as i'm concerned. one that i feel needs to stay ahead of the computing trend if it is to be considered a language for large scale applications. Personification of PHP doesn't make your argument any more salient. PHP isn't trying to stay ahead of anything. People are using it to solve problems, not to meet some phantom ideal of a "computing trend" threshold. but you nay-sayers here have convinced me; i'll be shopping for another language with which to serve my applications and the weboutput they produce.. thanks for opening my eyes and telling to abandon ship in time. Obviously we didn't open your eyes. Well excuse me for not dumping 50-100k lines of my own cms code instantly now that i realize that in order to scale it, i could really use features like threading and shared memory. Actually, you are th eone suggesting dumping your code since you said you were jumping ship. Many of us suggested that your problems can almost certainly be mitigated without threading. "almost certainly". at least you're acknowledging that you might be wrong. I'm certianly not right all the time. once I thought I was but I was wrong. take this example, sorry for the crosspost; my main concern atm is my own cms (50-100k lines of my own); it's graphics-heavy, does fairly complicated db based logic, and if it ever is to be used for a site like facebook, it'll get large dataflows that have to be distributed over the servers used to generate html and accessoiries for end-users. i've built a layer into it that caches the output of oft-used pages (like articles and their comments). but adding many comments / minute to an article would result in quite a bit of overhead, to update the html for that page and distribute it (fast enough) to the relevant servers. i'm worried about php's single-threaded nature; each request has to fetch html updated in the last few seconds, or generate it from a list of comments. that's also a big query from a big table for every end-user.. :( i'd rather keep them comments for an article in shared memory. I think you'll find when you get even close to the size of facebook, everything you think you know now about how it all stays running will be thrown out the window. But then, I'm not a fan of early optimization of this magnitude. A good design is usually flexible enough to allow redesign without recoding everything. Baby steps to the moon IMHO. yea, well, if i'm going to keep using php i need a path towards scalability, for this particular problem. i'd like to code the kinds of applications with big dataflows. call me a golddigger all you want, it's what i am ;) just not in the sexual sense hehe.. Your tools are up to date. Threading is in the future if at all... it's certainly not in the present. True, lets _keep_ 'm up-to-date, please. It is up to date. You mean make it have all the features you want. PHP is by it's very existence and ongoing development "up to date". yet you seem to oppose said development into the threading/shared-mem corner. without giving an alternative way to implement my previous case description (facebook/twitter level commenting to graphics-heavy pages at busy times). and that's just 1 case description. hundreds if not thousands more can be thought up or simply the best solution in the near future. I'm not sure why you think I'm opposed to such development. I've already told you to subscribe to internals or write your own patch. Do you need me to use a larger font? Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP -- 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:21 PM, Robert Cummings wrote: > > > Rene Veerman wrote: >> >> On Wed, Mar 24, 2010 at 9:45 PM, Robert Cummings >> wrote: >>> >>> Rene Veerman wrote: On Wed, Mar 24, 2010 at 9:31 PM, Robert Cummings wrote: > > Rene Veerman wrote: >> >> On Wed, Mar 24, 2010 at 3:25 PM, Robert Cummings >> >> wrote: >>> >>> Rene Veerman wrote: php is not a hammer, its a programming language. >>> >>> It's hard to discuss anything with someone who doesn't comprehend a >>> metaphor. >> >> haha. "comprehend". you mean "accept". >> that metaphor is stretched to breaking point as far as i'm concerned. >> one that i feel needs to stay ahead of the computing trend if it is to be considered a language for large scale applications. >>> >>> Personification of PHP doesn't make your argument any more salient. >>> PHP >>> isn't trying to stay ahead of anything. People are using it to solve >>> problems, not to meet some phantom ideal of a "computing trend" >>> threshold. >>> but you nay-sayers here have convinced me; i'll be shopping for another language with which to serve my applications and the weboutput they produce.. thanks for opening my eyes and telling to abandon ship in time. >>> >>> Obviously we didn't open your eyes. >>> >> Well excuse me for not dumping 50-100k lines of my own cms code >> instantly now that i realize that in order to scale it, i could really >> use features like threading and shared memory. > > Actually, you are th eone suggesting dumping your code since you said > you > were jumping ship. Many of us suggested that your problems can almost > certainly be mitigated without threading. > "almost certainly". at least you're acknowledging that you might be wrong. >>> >>> I'm certianly not right all the time. once I thought I was but I was >>> wrong. >>> take this example, sorry for the crosspost; my main concern atm is my own cms (50-100k lines of my own); it's graphics-heavy, does fairly complicated db based logic, and if it ever is to be used for a site like facebook, it'll get large dataflows that have to be distributed over the servers used to generate html and accessoiries for end-users. i've built a layer into it that caches the output of oft-used pages (like articles and their comments). but adding many comments / minute to an article would result in quite a bit of overhead, to update the html for that page and distribute it (fast enough) to the relevant servers. i'm worried about php's single-threaded nature; each request has to fetch html updated in the last few seconds, or generate it from a list of comments. that's also a big query from a big table for every end-user.. :( i'd rather keep them comments for an article in shared memory. >>> >>> I think you'll find when you get even close to the size of facebook, >>> everything you think you know now about how it all stays running will be >>> thrown out the window. But then, I'm not a fan of early optimization of >>> this >>> magnitude. A good design is usually flexible enough to allow redesign >>> without recoding everything. Baby steps to the moon IMHO. >>> >> yea, well, if i'm going to keep using php i need a path towards >> scalability, for this particular problem. >> >> i'd like to code the kinds of applications with big dataflows. >> call me a golddigger all you want, it's what i am ;) >> just not in the sexual sense hehe.. >> >>> Your tools are up to date. Threading is in the future if at all... it's >>> certainly not in the present. >> >> True, lets _keep_ 'm up-to-date, please. > > It is up to date. You mean make it have all the features you want. PHP is by > it's very existence and ongoing development "up to date". > yet you seem to oppose said development into the threading/shared-mem corner. without giving an alternative way to implement my previous case description (facebook/twitter level commenting to graphics-heavy pages at busy times). and that's just 1 case description. hundreds if not thousands more can be thought up or simply the best solution in the near future. -- 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 22:15 +0200, Rene Veerman wrote: > On Wed, Mar 24, 2010 at 10:05 PM, Ashley Sheridan > wrote: > > > > > > > So you're basically saying that you'd discount anyone who opposes you > > purely because you think you know best? > > > > Nice attitude. > > > > I ain't saying that at all, nor did i intend to imply it. > > In fact it's the anti-threading/shared-mem camp that thinks they know > everything best with their instistance that "throw more hardware at it, more > sql servers, more programming languages in a single project" will solve all > software design / growth problems with enough efficiency. They're offering the alternative. You keep disagreeing with their viewpoint because you seem to think you know best on this matter and won't even concede on a point. > > In this case, you still haven't given me any other reason to oppose the > evolution of php with the market trend Do you have any proof of this 'market trend'? I suggested a vote, but you 'nay-sayed' it on the basis that you'd lose to people who couldn't possibly know as much as you do. > , other than that it would cost > php-dev team time that can be spent on other things. > you (that camp) haven't even told me what features you want 'm to spend time > on instead. There are no new features that *I* can think of that *I* need in PHP, which is not to say that there aren't any that *other* people want. Again, I did suggest some sort of vote on this, which would give the internals team an idea of how keen people were to see this in the near future, but you said that too many people would oppose it. This comes round to the fact again that you seem to know best, and if the majority of people oppose your suggestion then they must be wrong, so any vote wouldn't count. 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. 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 4:28 AM, Per Jessen wrote: Tommy Pham wrote: On Wed, Mar 24, 2010 at 3:44 AM, Per Jessen wrote: Tommy Pham wrote: On Wed, Mar 24, 2010 at 3:20 AM, Per Jessen wrote: Tommy Pham wrote: What I find funny is that one of opponents of PHP threads earlier mentioned that how silly it would be to be using C in a web app. Now I hear people mentioning C when they need "productivity" or "speed"... I think I was the one to mention the latter, but as I started out saying, and as others have said too, it's about the right tool for the right job. When choosing a tool, there are a number of factors to consider - developer productivity, available skills, future maintenance, performance, scalability, portability, parallelism, performance etcetera. Funny you should mention all that. Let's say that you're longer with that company, either by direct employment or contract consultant. You've implemented C because you need 'thread'. Now your replacement comes in and has no clue about C even though your replacement is a PHP guru. How much headache is maintenance gonna be? Scalability? Portability? wow Who was the idi... who hired someone who wasn't suited for the job? Tommy, that's a moot argument. You can't fit a square peg in a round hole. -- Per Jessen, Zürich (12.5°C) Suited for the job? You mean introduce more complexity to a problem that what could be avoided to begin with if PHP has thread support? hmmm Tommy, it's perfectly simple: in my company we hire people with C skills for C programming jobs. We hire people with database skills to be database administrators. We hire people with Linux skills to work on Linux systems. We explicitly do _not_ hire PHP web-programmers to maintain our C code. And vice versa for that matter. No problem, no complexity. -- Per Jessen, Zürich (13.4°C) That may just work out fine if you work directly for the company with all the proper staffing. But some of us work as consultants or for companies without the proper staffing. As such, let's dissect what you mentioned: 1) PHP with internal thread support 2) PHP with external C/C++ thread support * Performance - having external thread support, now you have to call an extension (more memory usage and CPU cycles). If you happen to have a C/C++ guru who can then code that thread support into PHP extension, wouldn't it still perform better at the core vs as an extension because it's not talking to a 'middle man'? Having said that, not everyone has access to a C/C++ guru. Thus not mass availability. Are you suggesting that you need to be a guru in C to write threaded C code? I think the word you're looking for is competent. * Portability - if you're currently running PHP on Windows, but manage to convince management to switch to *BSD/Linux, then you'd have to rewrite that external thread support. But for us consultants, we may have 1 project the runs on Windows, the next may be *BSD/Linux. PHP code snippets goes a lot further versus your custom work around. * Managability - should your need to upgrade PHP for either bug fix, new features you'd want to implement to add more functionality to your site, will that then break your custom external solution? How much more manageable is it if it's done under 1 language versus 2+? Are you suggesting cross platform thread libraries don't exist? I wonder how Apache does it... or MySQL... or any number of open source cross-platform systems. If they implement their own, then by the virtue of the source being open, you can feel free to incorporate. Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP -- 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: On Wed, Mar 24, 2010 at 9:45 PM, la...@garfieldtech.com wrote: On 3/24/10 2:33 PM, Rene Veerman wrote: It's a debate. The dev team consider proposals and weigh in on the merits. I was a proponent for goto support during the development of PHP 5. We now have it. If you arguments are valid and there's no technical issue preventing it, and there's someone with time and skill to created the functionality, then it will happen. If not then it won't. I've seen many things added to PHP and I've watched and participated in the threads on internals that have lead to many new features. This is open source, opinions matter, but personal attacks and poor argument do not really make the cut. hahaha... you dismiss what i believe to be valid explanations without any counter-argument besides "more sql hardware!", not just by me but by all advocates of threading&shared memory in php. for some reason, which is still not clear to me, you nay-sayers refuse to let a PROGRAMMING LANGUAGE (not a "hammer", not a "fishing boat") evolve to stay useful, relevant even, in a changing market. and you're blatantly telling me to use a different kind of "hammer", one that would force me to rewrite large sections of my existing code-base, and one that i have told you i would find for many other _valid_ reasons not optimal. And what you seem to be missing is that making PHP userspace threaded is such a major change to the underlying code base and architecture that it would essentially be a total and complete rewrite, and would require people to rewrite large portions of their existing PHP userspace code. ehm, my newsscraper does threading via a fopen($threadURLonOwnServer) -> fread(threads,2048)+check for feof($thread) + usleep(50ms) -> if feof($thread) process($threadResults). so with a hack, you can let apache handle the threading, today. i suppose i could write something for shared memory in C++ but doing so would also be a hack that has to be installed on each server, rather than having it neatly as part of php. See PECL. 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 Wed, Mar 24, 2010 at 09:50:15PM +0200, Rene Veerman wrote: > On Wed, Mar 24, 2010 at 9:45 PM, Robert Cummings > wrote: > > > Your tools are up to date. Threading is in the future if at all... it's > > certainly not in the present. > > True, lets _keep_ 'm up-to-date, please. > > And you'd enable other uses of PHP besides helping this > real-time-web-scalability problem. Rene: You've been told you have two choices. Handle this with the PHP developers, or use a different language. Clearly, you're not making any converts on *this* list, and no one here can help you. Everyone else: Rene is baiting you, and drawing out the "discussion". He's simply thrashing about, trying to make you wrong for disagreeing with him. There is no more blood to be gained from the turnip of this thread. If you'd like to see it ended sometime this century, stop replying to him (in this and his other thread) and let him go bother the PHP developers, or use some other language. Paul -- Paul M. Foster -- 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: On Wed, Mar 24, 2010 at 9:45 PM, Robert Cummings wrote: Rene Veerman wrote: On Wed, Mar 24, 2010 at 9:31 PM, Robert Cummings wrote: Rene Veerman wrote: On Wed, Mar 24, 2010 at 3:25 PM, Robert Cummings wrote: Rene Veerman wrote: php is not a hammer, its a programming language. It's hard to discuss anything with someone who doesn't comprehend a metaphor. haha. "comprehend". you mean "accept". that metaphor is stretched to breaking point as far as i'm concerned. one that i feel needs to stay ahead of the computing trend if it is to be considered a language for large scale applications. Personification of PHP doesn't make your argument any more salient. PHP isn't trying to stay ahead of anything. People are using it to solve problems, not to meet some phantom ideal of a "computing trend" threshold. but you nay-sayers here have convinced me; i'll be shopping for another language with which to serve my applications and the weboutput they produce.. thanks for opening my eyes and telling to abandon ship in time. Obviously we didn't open your eyes. Well excuse me for not dumping 50-100k lines of my own cms code instantly now that i realize that in order to scale it, i could really use features like threading and shared memory. Actually, you are th eone suggesting dumping your code since you said you were jumping ship. Many of us suggested that your problems can almost certainly be mitigated without threading. "almost certainly". at least you're acknowledging that you might be wrong. I'm certianly not right all the time. once I thought I was but I was wrong. take this example, sorry for the crosspost; my main concern atm is my own cms (50-100k lines of my own); it's graphics-heavy, does fairly complicated db based logic, and if it ever is to be used for a site like facebook, it'll get large dataflows that have to be distributed over the servers used to generate html and accessoiries for end-users. i've built a layer into it that caches the output of oft-used pages (like articles and their comments). but adding many comments / minute to an article would result in quite a bit of overhead, to update the html for that page and distribute it (fast enough) to the relevant servers. i'm worried about php's single-threaded nature; each request has to fetch html updated in the last few seconds, or generate it from a list of comments. that's also a big query from a big table for every end-user.. :( i'd rather keep them comments for an article in shared memory. I think you'll find when you get even close to the size of facebook, everything you think you know now about how it all stays running will be thrown out the window. But then, I'm not a fan of early optimization of this magnitude. A good design is usually flexible enough to allow redesign without recoding everything. Baby steps to the moon IMHO. yea, well, if i'm going to keep using php i need a path towards scalability, for this particular problem. i'd like to code the kinds of applications with big dataflows. call me a golddigger all you want, it's what i am ;) just not in the sexual sense hehe.. Your tools are up to date. Threading is in the future if at all... it's certainly not in the present. True, lets _keep_ 'm up-to-date, please. It is up to date. You mean make it have all the features you want. PHP is by it's very existence and ongoing development "up to date". 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 Wed, Mar 24, 2010 at 10:05 PM, Ashley Sheridan wrote: > > > So you're basically saying that you'd discount anyone who opposes you > purely because you think you know best? > > Nice attitude. > I ain't saying that at all, nor did i intend to imply it. In fact it's the anti-threading/shared-mem camp that thinks they know everything best with their instistance that "throw more hardware at it, more sql servers, more programming languages in a single project" will solve all software design / growth problems with enough efficiency. In this case, you still haven't given me any other reason to oppose the evolution of php with the market trend, other than that it would cost php-dev team time that can be spent on other things. you (that camp) haven't even told me what features you want 'm to spend time on instead.
Re: [PHP] Will PHP ever "grow up" and have threading?
On Wed, 2010-03-24 at 22:05 +0200, Rene Veerman wrote: > On Wed, Mar 24, 2010 at 9:54 PM, Ashley Sheridan > wrote: > > > On Wed, 2010-03-24 at 21:50 +0200, Rene Veerman wrote: > > > > On Wed, Mar 24, 2010 at 9:45 PM, Robert Cummings > > wrote: > > > Rene Veerman wrote: > > >> > > >> On Wed, Mar 24, 2010 at 9:31 PM, Robert Cummings > > >> wrote: > > >>> > > >>> Rene Veerman wrote: > > > > On Wed, Mar 24, 2010 at 3:25 PM, Robert Cummings > > wrote: > > > > > > Rene Veerman wrote: > > >> > > >> php is not a hammer, its a programming language. > > > > > > It's hard to discuss anything with someone who doesn't comprehend a > > > metaphor. > > > > haha. "comprehend". you mean "accept". > > that metaphor is stretched to breaking point as far as i'm concerned. > > > > >> one that i feel needs to stay ahead of the computing trend if it is > > >> to > > >> be considered a language for large scale applications. > > > > > > Personification of PHP doesn't make your argument any more salient. > > > PHP > > > isn't trying to stay ahead of anything. People are using it to solve > > > problems, not to meet some phantom ideal of a "computing trend" > > > threshold. > > > > > >> but you nay-sayers here have convinced me; i'll be shopping for > > >> another language with which to serve my applications and the > > >> weboutput > > >> they produce.. > > >> > > >> thanks for opening my eyes and telling to abandon ship in time. > > > > > > Obviously we didn't open your eyes. > > > > > Well excuse me for not dumping 50-100k lines of my own cms code > > instantly now that i realize that in order to scale it, i could really > > use features like threading and shared memory. > > >>> > > >>> Actually, you are th eone suggesting dumping your code since you said > > >>> you > > >>> were jumping ship. Many of us suggested that your problems can almost > > >>> certainly be mitigated without threading. > > >>> > > >> > > >> "almost certainly". at least you're acknowledging that you might be > > >> wrong. > > > > > > I'm certianly not right all the time. once I thought I was but I was > > > wrong. > > > > > >> take this example, sorry for the crosspost; > > >> > > >> my main concern atm is my own cms (50-100k lines of my own); it's > > >> graphics-heavy, does fairly complicated db based logic, and if it ever > > >> is to be used for a site like facebook, it'll get large dataflows that > > >> have to be distributed over the servers used to generate html and > > >> accessoiries for end-users. > > >> i've built a layer into it that caches the output of oft-used pages > > >> (like articles and their comments). > > >> but adding many comments / minute to an article would result in quite > > >> a bit of overhead, to update the html for that page and distribute it > > >> (fast enough) to the relevant servers. > > >> > > >> i'm worried about php's single-threaded nature; each request has to > > >> fetch html updated in the last few seconds, or generate it from a list > > >> of comments. that's also a big query from a big table for every > > >> end-user.. :( > > >> i'd rather keep them comments for an article in shared memory. > > > > > > I think you'll find when you get even close to the size of facebook, > > > everything you think you know now about how it all stays running will be > > > thrown out the window. But then, I'm not a fan of early optimization of > > > this > > > magnitude. A good design is usually flexible enough to allow redesign > > > without recoding everything. Baby steps to the moon IMHO. > > > > > yea, well, if i'm going to keep using php i need a path towards > > scalability, for this particular problem. > > > > i'd like to code the kinds of applications with big dataflows. > > call me a golddigger all you want, it's what i am ;) > > just not in the sexual sense hehe.. > > > > >Your tools are up to date. Threading is in the future if at all... it's > > >certainly not in the present. > > > > True, lets _keep_ 'm up-to-date, please. > > > > And you'd enable other uses of PHP besides helping this > > real-time-web-scalability problem. > > > > > > > > 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. > > > > we'd probably lose that vote because so many of you other php programmers > refuse to see that we do have good uses for it, and you don't. yet. > > but ultimately it's a matter of the php dev's team time and effort, so when > this thread has run it's course i may go to the internals list and raise it > -diplomatically- there. So you're basically saying that you'd discount anyone who opposes you purely because you think you know best?
Re: [PHP] Will PHP ever "grow up" and have threading?
On Wed, Mar 24, 2010 at 9:54 PM, Ashley Sheridan wrote: > On Wed, 2010-03-24 at 21:50 +0200, Rene Veerman wrote: > > On Wed, Mar 24, 2010 at 9:45 PM, Robert Cummings wrote: > > Rene Veerman wrote: > >> > >> On Wed, Mar 24, 2010 at 9:31 PM, Robert Cummings > >> wrote: > >>> > >>> Rene Veerman wrote: > > On Wed, Mar 24, 2010 at 3:25 PM, Robert Cummings > wrote: > > > > Rene Veerman wrote: > >> > >> php is not a hammer, its a programming language. > > > > It's hard to discuss anything with someone who doesn't comprehend a > > metaphor. > > haha. "comprehend". you mean "accept". > that metaphor is stretched to breaking point as far as i'm concerned. > > >> one that i feel needs to stay ahead of the computing trend if it is to > >> be considered a language for large scale applications. > > > > Personification of PHP doesn't make your argument any more salient. PHP > > isn't trying to stay ahead of anything. People are using it to solve > > problems, not to meet some phantom ideal of a "computing trend" > > threshold. > > > >> but you nay-sayers here have convinced me; i'll be shopping for > >> another language with which to serve my applications and the weboutput > >> they produce.. > >> > >> thanks for opening my eyes and telling to abandon ship in time. > > > > Obviously we didn't open your eyes. > > > Well excuse me for not dumping 50-100k lines of my own cms code > instantly now that i realize that in order to scale it, i could really > use features like threading and shared memory. > >>> > >>> Actually, you are th eone suggesting dumping your code since you said you > >>> were jumping ship. Many of us suggested that your problems can almost > >>> certainly be mitigated without threading. > >>> > >> > >> "almost certainly". at least you're acknowledging that you might be wrong. > > > > I'm certianly not right all the time. once I thought I was but I was wrong. > > > >> take this example, sorry for the crosspost; > >> > >> my main concern atm is my own cms (50-100k lines of my own); it's > >> graphics-heavy, does fairly complicated db based logic, and if it ever > >> is to be used for a site like facebook, it'll get large dataflows that > >> have to be distributed over the servers used to generate html and > >> accessoiries for end-users. > >> i've built a layer into it that caches the output of oft-used pages > >> (like articles and their comments). > >> but adding many comments / minute to an article would result in quite > >> a bit of overhead, to update the html for that page and distribute it > >> (fast enough) to the relevant servers. > >> > >> i'm worried about php's single-threaded nature; each request has to > >> fetch html updated in the last few seconds, or generate it from a list > >> of comments. that's also a big query from a big table for every > >> end-user.. :( > >> i'd rather keep them comments for an article in shared memory. > > > > I think you'll find when you get even close to the size of facebook, > > everything you think you know now about how it all stays running will be > > thrown out the window. But then, I'm not a fan of early optimization of this > > magnitude. A good design is usually flexible enough to allow redesign > > without recoding everything. Baby steps to the moon IMHO. > > > yea, well, if i'm going to keep using php i need a path towards > scalability, for this particular problem. > > i'd like to code the kinds of applications with big dataflows. > call me a golddigger all you want, it's what i am ;) > just not in the sexual sense hehe.. > > >Your tools are up to date. Threading is in the future if at all... it's > >certainly not in the present. > > True, lets _keep_ 'm up-to-date, please. > > And you'd enable other uses of PHP besides helping this > real-time-web-scalability problem. > > > > 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. > we'd probably lose that vote because so many of you other php programmers refuse to see that we do have good uses for it, and you don't. yet. but ultimately it's a matter of the php dev's team time and effort, so when this thread has run it's course i may go to the internals list and raise it -diplomatically- there.
Re: [PHP] Will PHP ever "grow up" and have threading?
On Wed, 2010-03-24 at 21:50 +0200, Rene Veerman wrote: > On Wed, Mar 24, 2010 at 9:45 PM, Robert Cummings wrote: > > Rene Veerman wrote: > >> > >> On Wed, Mar 24, 2010 at 9:31 PM, Robert Cummings > >> wrote: > >>> > >>> Rene Veerman wrote: > > On Wed, Mar 24, 2010 at 3:25 PM, Robert Cummings > wrote: > > > > Rene Veerman wrote: > >> > >> php is not a hammer, its a programming language. > > > > It's hard to discuss anything with someone who doesn't comprehend a > > metaphor. > > haha. "comprehend". you mean "accept". > that metaphor is stretched to breaking point as far as i'm concerned. > > >> one that i feel needs to stay ahead of the computing trend if it is to > >> be considered a language for large scale applications. > > > > Personification of PHP doesn't make your argument any more salient. PHP > > isn't trying to stay ahead of anything. People are using it to solve > > problems, not to meet some phantom ideal of a "computing trend" > > threshold. > > > >> but you nay-sayers here have convinced me; i'll be shopping for > >> another language with which to serve my applications and the weboutput > >> they produce.. > >> > >> thanks for opening my eyes and telling to abandon ship in time. > > > > Obviously we didn't open your eyes. > > > Well excuse me for not dumping 50-100k lines of my own cms code > instantly now that i realize that in order to scale it, i could really > use features like threading and shared memory. > >>> > >>> Actually, you are th eone suggesting dumping your code since you said you > >>> were jumping ship. Many of us suggested that your problems can almost > >>> certainly be mitigated without threading. > >>> > >> > >> "almost certainly". at least you're acknowledging that you might be wrong. > > > > I'm certianly not right all the time. once I thought I was but I was wrong. > > > >> take this example, sorry for the crosspost; > >> > >> my main concern atm is my own cms (50-100k lines of my own); it's > >> graphics-heavy, does fairly complicated db based logic, and if it ever > >> is to be used for a site like facebook, it'll get large dataflows that > >> have to be distributed over the servers used to generate html and > >> accessoiries for end-users. > >> i've built a layer into it that caches the output of oft-used pages > >> (like articles and their comments). > >> but adding many comments / minute to an article would result in quite > >> a bit of overhead, to update the html for that page and distribute it > >> (fast enough) to the relevant servers. > >> > >> i'm worried about php's single-threaded nature; each request has to > >> fetch html updated in the last few seconds, or generate it from a list > >> of comments. that's also a big query from a big table for every > >> end-user.. :( > >> i'd rather keep them comments for an article in shared memory. > > > > I think you'll find when you get even close to the size of facebook, > > everything you think you know now about how it all stays running will be > > thrown out the window. But then, I'm not a fan of early optimization of this > > magnitude. A good design is usually flexible enough to allow redesign > > without recoding everything. Baby steps to the moon IMHO. > > > yea, well, if i'm going to keep using php i need a path towards > scalability, for this particular problem. > > i'd like to code the kinds of applications with big dataflows. > call me a golddigger all you want, it's what i am ;) > just not in the sexual sense hehe.. > > >Your tools are up to date. Threading is in the future if at all... it's > >certainly not in the present. > > True, lets _keep_ 'm up-to-date, please. > > And you'd enable other uses of PHP besides helping this > real-time-web-scalability problem. > 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. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [PHP] Will PHP ever "grow up" and have threading?
On Wed, Mar 24, 2010 at 9:45 PM, la...@garfieldtech.com wrote: > On 3/24/10 2:33 PM, Rene Veerman wrote: > >>> It's a debate. The dev team consider proposals and weigh in on the >>> merits. I >>> was a proponent for goto support during the development of PHP 5. We now >>> have it. If you arguments are valid and there's no technical issue >>> preventing it, and there's someone with time and skill to created the >>> functionality, then it will happen. If not then it won't. I've seen many >>> things added to PHP and I've watched and participated in the threads on >>> internals that have lead to many new features. This is open source, >>> opinions >>> matter, but personal attacks and poor argument do not really make the >>> cut. >>> >> >> hahaha... you dismiss what i believe to be valid explanations without >> any counter-argument besides "more sql hardware!", not just by me but >> by all advocates of threading&shared memory in php. >> >> for some reason, which is still not clear to me, you nay-sayers refuse >> to let a PROGRAMMING LANGUAGE (not a "hammer", not a "fishing boat") >> evolve to stay useful, relevant even, in a changing market. >> >> and you're blatantly telling me to use a different kind of "hammer", >> one that would force me to rewrite large sections of my existing >> code-base, and one that i have told you i would find for many other >> _valid_ reasons not optimal. > > And what you seem to be missing is that making PHP userspace threaded is > such a major change to the underlying code base and architecture that it > would essentially be a total and complete rewrite, and would require people > to rewrite large portions of their existing PHP userspace code. ehm, my newsscraper does threading via a fopen($threadURLonOwnServer) -> fread(threads,2048)+check for feof($thread) + usleep(50ms) -> if feof($thread) process($threadResults). so with a hack, you can let apache handle the threading, today. i suppose i could write something for shared memory in C++ but doing so would also be a hack that has to be installed on each server, rather than having it neatly as part of php. yet if i can code 'm as addons, it must not be hard to include it in the core. the paradigm "shared nothing" may still be the preferred default if you want, but fact is _current_ PHP can set_time_limit(0) and usleep(50ms) until it has something to do again. so i refute it would require a rewrite of php. both features i request for php6/7 can be put in as addons. > > So it's either you adjust your code to fit the paradigm that PHP is built > for from the ground up, or the entire rest of the world adjusts its code to > fit the paradigm that you think you want to have. that's just not the case imo. > >> basically, you're determining my choice of options without me ever >> having forced you to do something a certain way.. >> >> so you'll have to excuse my strong language. >> it's just letting you know that you shouldn't butt into other peoples >> business when it doesn't really affect you. > > Except having to rewrite all of my code to be thread safe would affect me. > > If you didn't want to have a discussion, which by nature has differing view > points, you shouldn't be on a discussion list. > > --Larry Garfield > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
On Wed, Mar 24, 2010 at 4:28 AM, Per Jessen wrote: > Tommy Pham wrote: > >> On Wed, Mar 24, 2010 at 3:44 AM, Per Jessen wrote: >>> Tommy Pham wrote: >>> On Wed, Mar 24, 2010 at 3:20 AM, Per Jessen wrote: > Tommy Pham wrote: > >> What I find funny is that one of opponents of PHP threads earlier >> mentioned that how silly it would be to be using C in a web app. >> Now I hear people mentioning C when they need "productivity" or >> "speed"... >> > > I think I was the one to mention the latter, but as I started out > saying, and as others have said too, it's about the right tool for > the right job. When choosing a tool, there are a number of factors > to consider - developer productivity, available skills, future > maintenance, performance, scalability, portability, parallelism, > performance etcetera. > Funny you should mention all that. Let's say that you're longer with that company, either by direct employment or contract consultant. You've implemented C because you need 'thread'. Now your replacement comes in and has no clue about C even though your replacement is a PHP guru. How much headache is maintenance gonna be? Scalability? Portability? wow >>> >>> Who was the idi... who hired someone who wasn't suited for the job? >>> Tommy, that's a moot argument. You can't fit a square peg in a round >>> hole. >>> >>> -- >>> Per Jessen, Zürich (12.5°C) >>> >> >> Suited for the job? You mean introduce more complexity to a problem >> that what could be avoided to begin with if PHP has thread support? >> hmmm > > Tommy, it's perfectly simple: in my company we hire people with C > skills for C programming jobs. We hire people with database skills to > be database administrators. We hire people with Linux skills to work > on Linux systems. We explicitly do _not_ hire PHP web-programmers to > maintain our C code. And vice versa for that matter. No problem, no > complexity. > > > -- > Per Jessen, Zürich (13.4°C) > > That may just work out fine if you work directly for the company with all the proper staffing. But some of us work as consultants or for companies without the proper staffing. As such, let's dissect what you mentioned: 1) PHP with internal thread support 2) PHP with external C/C++ thread support * Performance - having external thread support, now you have to call an extension (more memory usage and CPU cycles). If you happen to have a C/C++ guru who can then code that thread support into PHP extension, wouldn't it still perform better at the core vs as an extension because it's not talking to a 'middle man'? Having said that, not everyone has access to a C/C++ guru. Thus not mass availability. * Portability - if you're currently running PHP on Windows, but manage to convince management to switch to *BSD/Linux, then you'd have to rewrite that external thread support. But for us consultants, we may have 1 project the runs on Windows, the next may be *BSD/Linux. PHP code snippets goes a lot further versus your custom work around. * Managability - should your need to upgrade PHP for either bug fix, new features you'd want to implement to add more functionality to your site, will that then break your custom external solution? How much more manageable is it if it's done under 1 language versus 2+? 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 Wed, Mar 24, 2010 at 9:45 PM, Robert Cummings wrote: > Rene Veerman wrote: >> >> On Wed, Mar 24, 2010 at 9:31 PM, Robert Cummings >> wrote: >>> >>> Rene Veerman wrote: On Wed, Mar 24, 2010 at 3:25 PM, Robert Cummings wrote: > > Rene Veerman wrote: >> >> php is not a hammer, its a programming language. > > It's hard to discuss anything with someone who doesn't comprehend a > metaphor. haha. "comprehend". you mean "accept". that metaphor is stretched to breaking point as far as i'm concerned. >> one that i feel needs to stay ahead of the computing trend if it is to >> be considered a language for large scale applications. > > Personification of PHP doesn't make your argument any more salient. PHP > isn't trying to stay ahead of anything. People are using it to solve > problems, not to meet some phantom ideal of a "computing trend" > threshold. > >> but you nay-sayers here have convinced me; i'll be shopping for >> another language with which to serve my applications and the weboutput >> they produce.. >> >> thanks for opening my eyes and telling to abandon ship in time. > > Obviously we didn't open your eyes. > Well excuse me for not dumping 50-100k lines of my own cms code instantly now that i realize that in order to scale it, i could really use features like threading and shared memory. >>> >>> Actually, you are th eone suggesting dumping your code since you said you >>> were jumping ship. Many of us suggested that your problems can almost >>> certainly be mitigated without threading. >>> >> >> "almost certainly". at least you're acknowledging that you might be wrong. > > I'm certianly not right all the time. once I thought I was but I was wrong. > >> take this example, sorry for the crosspost; >> >> my main concern atm is my own cms (50-100k lines of my own); it's >> graphics-heavy, does fairly complicated db based logic, and if it ever >> is to be used for a site like facebook, it'll get large dataflows that >> have to be distributed over the servers used to generate html and >> accessoiries for end-users. >> i've built a layer into it that caches the output of oft-used pages >> (like articles and their comments). >> but adding many comments / minute to an article would result in quite >> a bit of overhead, to update the html for that page and distribute it >> (fast enough) to the relevant servers. >> >> i'm worried about php's single-threaded nature; each request has to >> fetch html updated in the last few seconds, or generate it from a list >> of comments. that's also a big query from a big table for every >> end-user.. :( >> i'd rather keep them comments for an article in shared memory. > > I think you'll find when you get even close to the size of facebook, > everything you think you know now about how it all stays running will be > thrown out the window. But then, I'm not a fan of early optimization of this > magnitude. A good design is usually flexible enough to allow redesign > without recoding everything. Baby steps to the moon IMHO. > yea, well, if i'm going to keep using php i need a path towards scalability, for this particular problem. i'd like to code the kinds of applications with big dataflows. call me a golddigger all you want, it's what i am ;) just not in the sexual sense hehe.. >Your tools are up to date. Threading is in the future if at all... it's >certainly not in the present. True, lets _keep_ 'm up-to-date, please. And you'd enable other uses of PHP besides helping this real-time-web-scalability 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?
Rene Veerman wrote: On Wed, Mar 24, 2010 at 9:41 PM, Robert Cummings wrote: Rene Veerman wrote: On Wed, Mar 24, 2010 at 9:30 PM, Robert Cummings wrote: Rene Veerman wrote: On Wed, Mar 24, 2010 at 3:13 PM, Robert Cummings wrote: Rene Veerman wrote: 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. Umm... you or your boss/client chose PHP. That means one of those two determined your toolset. Maybe next time you might want to pony up for a requirements analysis to determine if the toolset is right for the job. you've never heard of feature-creep, changing environments and requirements, etc? Not usually, at the level of the language choice, is an about turn done after a requirements analysis has been completed. Feature creep is a management issue. it's a managment issue only because it's a fact of life. A billable one. i prefer to reduce my headaches and bill size at the same time with up-to-date tools. Your tools are up to date. Threading is in the future if at all... it's certainly not in the present. 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?
Rene Veerman wrote: On Wed, Mar 24, 2010 at 9:31 PM, Robert Cummings wrote: Rene Veerman wrote: On Wed, Mar 24, 2010 at 3:25 PM, Robert Cummings wrote: Rene Veerman wrote: php is not a hammer, its a programming language. It's hard to discuss anything with someone who doesn't comprehend a metaphor. haha. "comprehend". you mean "accept". that metaphor is stretched to breaking point as far as i'm concerned. one that i feel needs to stay ahead of the computing trend if it is to be considered a language for large scale applications. Personification of PHP doesn't make your argument any more salient. PHP isn't trying to stay ahead of anything. People are using it to solve problems, not to meet some phantom ideal of a "computing trend" threshold. but you nay-sayers here have convinced me; i'll be shopping for another language with which to serve my applications and the weboutput they produce.. thanks for opening my eyes and telling to abandon ship in time. Obviously we didn't open your eyes. Well excuse me for not dumping 50-100k lines of my own cms code instantly now that i realize that in order to scale it, i could really use features like threading and shared memory. Actually, you are th eone suggesting dumping your code since you said you were jumping ship. Many of us suggested that your problems can almost certainly be mitigated without threading. "almost certainly". at least you're acknowledging that you might be wrong. I'm certianly not right all the time. once I thought I was but I was wrong. take this example, sorry for the crosspost; my main concern atm is my own cms (50-100k lines of my own); it's graphics-heavy, does fairly complicated db based logic, and if it ever is to be used for a site like facebook, it'll get large dataflows that have to be distributed over the servers used to generate html and accessoiries for end-users. i've built a layer into it that caches the output of oft-used pages (like articles and their comments). but adding many comments / minute to an article would result in quite a bit of overhead, to update the html for that page and distribute it (fast enough) to the relevant servers. i'm worried about php's single-threaded nature; each request has to fetch html updated in the last few seconds, or generate it from a list of comments. that's also a big query from a big table for every end-user.. :( i'd rather keep them comments for an article in shared memory. I think you'll find when you get even close to the size of facebook, everything you think you know now about how it all stays running will be thrown out the window. But then, I'm not a fan of early optimization of this magnitude. A good design is usually flexible enough to allow redesign without recoding everything. Baby steps to the moon IMHO. 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 3/24/10 2:33 PM, Rene Veerman wrote: It's a debate. The dev team consider proposals and weigh in on the merits. I was a proponent for goto support during the development of PHP 5. We now have it. If you arguments are valid and there's no technical issue preventing it, and there's someone with time and skill to created the functionality, then it will happen. If not then it won't. I've seen many things added to PHP and I've watched and participated in the threads on internals that have lead to many new features. This is open source, opinions matter, but personal attacks and poor argument do not really make the cut. hahaha... you dismiss what i believe to be valid explanations without any counter-argument besides "more sql hardware!", not just by me but by all advocates of threading&shared memory in php. for some reason, which is still not clear to me, you nay-sayers refuse to let a PROGRAMMING LANGUAGE (not a "hammer", not a "fishing boat") evolve to stay useful, relevant even, in a changing market. and you're blatantly telling me to use a different kind of "hammer", one that would force me to rewrite large sections of my existing code-base, and one that i have told you i would find for many other _valid_ reasons not optimal. And what you seem to be missing is that making PHP userspace threaded is such a major change to the underlying code base and architecture that it would essentially be a total and complete rewrite, and would require people to rewrite large portions of their existing PHP userspace code. So it's either you adjust your code to fit the paradigm that PHP is built for from the ground up, or the entire rest of the world adjusts its code to fit the paradigm that you think you want to have. basically, you're determining my choice of options without me ever having forced you to do something a certain way.. so you'll have to excuse my strong language. it's just letting you know that you shouldn't butt into other peoples business when it doesn't really affect you. Except having to rewrite all of my code to be thread safe would affect me. If you didn't want to have a discussion, which by nature has differing view points, you shouldn't be on a discussion list. --Larry Garfield -- 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 9:41 PM, Robert Cummings wrote: > > > Rene Veerman wrote: >> >> On Wed, Mar 24, 2010 at 9:30 PM, Robert Cummings >> wrote: >>> >>> Rene Veerman wrote: On Wed, Mar 24, 2010 at 3:13 PM, Robert Cummings wrote: > > Rene Veerman wrote: >> >> 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. > > Umm... you or your boss/client chose PHP. That means one of those two > determined your toolset. Maybe next time you might want to pony up for > a > requirements analysis to determine if the toolset is right for the job. > you've never heard of feature-creep, changing environments and requirements, etc? >>> >>> Not usually, at the level of the language choice, is an about turn done >>> after a requirements analysis has been completed. Feature creep is a >>> management issue. >>> >> it's a managment issue only because it's a fact of life. > > A billable one. > i prefer to reduce my headaches and bill size at the same time with up-to-date tools. -- 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:18 AM, Sancar Saran wrote: > On Wednesday 24 March 2010 03:17:56 Tommy Pham wrote: >> Let's go back to my 1st e-commerce example. The manufacturers list is >> about 3,700. The categories is about about 2,400. The products list >> is right now at 500,000 and expected to be around 750,000. The site >> is only in English. The store owner wants to expand and be I18n: >> Chinese, French, German, Korean, Spanish. You see how big and complex >> that database gets? The store owners want to have this happens when a >> customer clicks on a category: >> >> * show all subcategories for that category, if any >> * show all products for that category, if any, >> * show all manufacturers, used as filtering, for that category and >> subcategories * show price range filter for that category >> * show features & specifications filter for that category >> * show 10 top sellers for that category and related subcategories >> * the shopper can then select/deselect any of those filters and >> ability to sort by manufacturers, prices, user rating, popularity >> (purchased quantity) >> * have the ability to switch to another language translation on the fly >> * from the moment the shopper click on a link, the response time (when >> web browser saids "Done" in the status bar) is 5 seconds or less. >> Preferably 2-3 seconds. Will be using stopwatch for the timer. >> >> Now show me a website that meets those requirements and uses PHP, I'll >> be glad to support your argument about PHP w/o threads :) BTW, this >> is not even enterprise requirement. I may have another possible >> project where # products is over 10 million easily. With similar >> requirements when the user click on category. Do you think this site, >> which currently isn't, can run on PHP? >> >> Regards, >> Tommy > > > If you design and code correctly. Yes. > > > If you want to use someting alredy. Try TYPO3. > > PS: Your arguments are something about implementation not something about > platform abilities. You can do this things any server side programming with > enough hardware. > > Regards > > Sancar > > Platform abilities = PHP with/without threads. Implementation = If PHP has threads, how do I implement it. If not, what work around / hacks do I need to do. -- 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: On Wed, Mar 24, 2010 at 9:30 PM, Robert Cummings wrote: Rene Veerman wrote: On Wed, Mar 24, 2010 at 3:13 PM, Robert Cummings wrote: Rene Veerman wrote: 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. Umm... you or your boss/client chose PHP. That means one of those two determined your toolset. Maybe next time you might want to pony up for a requirements analysis to determine if the toolset is right for the job. you've never heard of feature-creep, changing environments and requirements, etc? Not usually, at the level of the language choice, is an about turn done after a requirements analysis has been completed. Feature creep is a management issue. it's a managment issue only because it's a fact of life. A billable one. 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 Wed, Mar 24, 2010 at 3:37 PM, Jochem Maas wrote: > > Someone who respects you will buy you a sandwich if you need it. i'd rather build products that are useful enough to be sold, than to wait for anti-starvation handouts gained from respect. > > But seemingly you're only interested in leveraging other peoples time and > experience to further your own career, good luck with that around here. > i've spent quite a bit of time on this list writing replies of my own to other people's software problems here. in fact i think i've spent more time on other's problems for free than i've received back in useful tips. and i'm not bitching about that. -- 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: On Wed, Mar 24, 2010 at 3:29 PM, Robert Cummings wrote: Rene Veerman wrote: unless the actual php development team would like to weigh in on this matter of course. Wrong list. Subscribe to internals. 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. It's a debate. The dev team consider proposals and weigh in on the merits. I was a proponent for goto support during the development of PHP 5. We now have it. If you arguments are valid and there's no technical issue preventing it, and there's someone with time and skill to created the functionality, then it will happen. If not then it won't. I've seen many things added to PHP and I've watched and participated in the threads on internals that have lead to many new features. This is open source, opinions matter, but personal attacks and poor argument do not really make the cut. hahaha... you dismiss what i believe to be valid explanations without any counter-argument besides "more sql hardware!", not just by me but by all advocates of threading&shared memory in php. for some reason, which is still not clear to me, you nay-sayers refuse to let a PROGRAMMING LANGUAGE (not a "hammer", not a "fishing boat") evolve to stay useful, relevant even, in a changing market. and you're blatantly telling me to use a different kind of "hammer", one that would force me to rewrite large sections of my existing code-base, and one that i have told you i would find for many other _valid_ reasons not optimal. basically, you're determining my choice of options without me ever having forced you to do something a certain way.. so you'll have to excuse my strong language. it's just letting you know that you shouldn't butt into other peoples business when it doesn't really affect you. We can't be determining your choice of options since threading is not currently an option. If you want it, do as I suggested, subscribe to internals and engage in due process. 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?
From: Rene Veerman > i've spent quite a bit of time on this list writing replies of my own > to other people's software problems here. > in fact i think i've spent more time on other's problems for free than > i've received back in useful tips. and i'm not bitching about that. That describes a lot of people here, but I think of it as my payment for PHP. Our continued input helps to draw others into the community, which increases the knowledge and experience pool using the language and answering questions. Which means there may be more help available the next time I run into a thorny issue. Yes, it's a continuous cycle of growth, like rolling a snowball downhill in wet snow. But every little bit helps. Bob McConnell -- 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 9:31 PM, Robert Cummings wrote: > > > Rene Veerman wrote: >> >> On Wed, Mar 24, 2010 at 3:25 PM, Robert Cummings >> wrote: >>> >>> Rene Veerman wrote: php is not a hammer, its a programming language. >>> >>> It's hard to discuss anything with someone who doesn't comprehend a >>> metaphor. >> >> haha. "comprehend". you mean "accept". >> that metaphor is stretched to breaking point as far as i'm concerned. >> one that i feel needs to stay ahead of the computing trend if it is to be considered a language for large scale applications. >>> >>> Personification of PHP doesn't make your argument any more salient. PHP >>> isn't trying to stay ahead of anything. People are using it to solve >>> problems, not to meet some phantom ideal of a "computing trend" >>> threshold. >>> but you nay-sayers here have convinced me; i'll be shopping for another language with which to serve my applications and the weboutput they produce.. thanks for opening my eyes and telling to abandon ship in time. >>> >>> Obviously we didn't open your eyes. >>> >> >> Well excuse me for not dumping 50-100k lines of my own cms code >> instantly now that i realize that in order to scale it, i could really >> use features like threading and shared memory. > > Actually, you are th eone suggesting dumping your code since you said you > were jumping ship. Many of us suggested that your problems can almost > certainly be mitigated without threading. > "almost certainly". at least you're acknowledging that you might be wrong. take this example, sorry for the crosspost; my main concern atm is my own cms (50-100k lines of my own); it's graphics-heavy, does fairly complicated db based logic, and if it ever is to be used for a site like facebook, it'll get large dataflows that have to be distributed over the servers used to generate html and accessoiries for end-users. i've built a layer into it that caches the output of oft-used pages (like articles and their comments). but adding many comments / minute to an article would result in quite a bit of overhead, to update the html for that page and distribute it (fast enough) to the relevant servers. i'm worried about php's single-threaded nature; each request has to fetch html updated in the last few seconds, or generate it from a list of comments. that's also a big query from a big table for every end-user.. :( i'd rather keep them comments for an article in shared memory. -- 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 9:30 PM, Robert Cummings wrote: > > > Rene Veerman wrote: >> >> On Wed, Mar 24, 2010 at 3:13 PM, Robert Cummings >> wrote: >>> >>> Rene Veerman wrote: 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. >>> >>> Umm... you or your boss/client chose PHP. That means one of those two >>> determined your toolset. Maybe next time you might want to pony up for a >>> requirements analysis to determine if the toolset is right for the job. >>> >> >> you've never heard of feature-creep, changing environments and >> requirements, etc? > > Not usually, at the level of the language choice, is an about turn done > after a requirements analysis has been completed. Feature creep is a > management issue. > it's a managment issue only because it's a fact of life. -- 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:29 PM, Robert Cummings wrote: > Rene Veerman wrote: >> >> unless the actual php development team would like to weigh in on this >> matter of course. > > Wrong list. Subscribe to internals. > >> 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. > > It's a debate. The dev team consider proposals and weigh in on the merits. I > was a proponent for goto support during the development of PHP 5. We now > have it. If you arguments are valid and there's no technical issue > preventing it, and there's someone with time and skill to created the > functionality, then it will happen. If not then it won't. I've seen many > things added to PHP and I've watched and participated in the threads on > internals that have lead to many new features. This is open source, opinions > matter, but personal attacks and poor argument do not really make the cut. > hahaha... you dismiss what i believe to be valid explanations without any counter-argument besides "more sql hardware!", not just by me but by all advocates of threading&shared memory in php. for some reason, which is still not clear to me, you nay-sayers refuse to let a PROGRAMMING LANGUAGE (not a "hammer", not a "fishing boat") evolve to stay useful, relevant even, in a changing market. and you're blatantly telling me to use a different kind of "hammer", one that would force me to rewrite large sections of my existing code-base, and one that i have told you i would find for many other _valid_ reasons not optimal. basically, you're determining my choice of options without me ever having forced you to do something a certain way.. so you'll have to excuse my strong language. it's just letting you know that you shouldn't butt into other peoples business when it doesn't really affect you. -- 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: On Wed, Mar 24, 2010 at 3:25 PM, Robert Cummings wrote: Rene Veerman wrote: php is not a hammer, its a programming language. It's hard to discuss anything with someone who doesn't comprehend a metaphor. haha. "comprehend". you mean "accept". that metaphor is stretched to breaking point as far as i'm concerned. one that i feel needs to stay ahead of the computing trend if it is to be considered a language for large scale applications. Personification of PHP doesn't make your argument any more salient. PHP isn't trying to stay ahead of anything. People are using it to solve problems, not to meet some phantom ideal of a "computing trend" threshold. but you nay-sayers here have convinced me; i'll be shopping for another language with which to serve my applications and the weboutput they produce.. thanks for opening my eyes and telling to abandon ship in time. Obviously we didn't open your eyes. Well excuse me for not dumping 50-100k lines of my own cms code instantly now that i realize that in order to scale it, i could really use features like threading and shared memory. Actually, you are th eone suggesting dumping your code since you said you were jumping ship. Many of us suggested that your problems can almost certainly be mitigated without threading. 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 Wed, Mar 24, 2010 at 3:22 PM, Robert Cummings wrote: > Rene Veerman wrote: >> >> On Wed, Mar 24, 2010 at 11:13 AM, Per Jessen wrote: >>> >>> Rene Veerman wrote: >>> again: a) you're determining the contents of my toolset, without it affecting you at all. the way you want it php will degrade into a toy language. >>> >>> Rene, it seems to me that you and I are advocating two opposite >>> positions on the topic of threading in PHP, so aren't we both trying to >>> determine the contents of each others toolset? >>> >> >> Per: that's EXACTLY the point. >> You are determining it for me, i'm not for you. >> Simply because you dont have to use the language features you atm >> think you don't need in php. > > Actually, no. You are determine aspects of the toolset as it stands. To add > threading is not a benign additon because we can choose to use it or not. If > added it would affect the future irrevocably since undoubtedly we would need > to maintain someone's code that contains threads because they didn't > understand the shared nothing nature of PHP. yes you may encounter bad code. it happens now too. but most realtime programmers know not to use threads unless necessary. -- 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:25 PM, Robert Cummings wrote: > Rene Veerman wrote: >> >> php is not a hammer, its a programming language. > > It's hard to discuss anything with someone who doesn't comprehend a > metaphor. haha. "comprehend". you mean "accept". that metaphor is stretched to breaking point as far as i'm concerned. > >> one that i feel needs to stay ahead of the computing trend if it is to >> be considered a language for large scale applications. > > Personification of PHP doesn't make your argument any more salient. PHP > isn't trying to stay ahead of anything. People are using it to solve > problems, not to meet some phantom ideal of a "computing trend" threshold. > >> but you nay-sayers here have convinced me; i'll be shopping for >> another language with which to serve my applications and the weboutput >> they produce.. >> >> thanks for opening my eyes and telling to abandon ship in time. > > Obviously we didn't open your eyes. > Well excuse me for not dumping 50-100k lines of my own cms code instantly now that i realize that in order to scale it, i could really use features like threading and shared memory. -- 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: On Wed, Mar 24, 2010 at 3:13 PM, Robert Cummings wrote: Rene Veerman wrote: 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. Umm... you or your boss/client chose PHP. That means one of those two determined your toolset. Maybe next time you might want to pony up for a requirements analysis to determine if the toolset is right for the job. you've never heard of feature-creep, changing environments and requirements, etc? Not usually, at the level of the language choice, is an about turn done after a requirements analysis has been completed. Feature creep is a management issue. 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 Wed, Mar 24, 2010 at 3:13 PM, Robert Cummings wrote: > Rene Veerman wrote: >> >> 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. > > Umm... you or your boss/client chose PHP. That means one of those two > determined your toolset. Maybe next time you might want to pony up for a > requirements analysis to determine if the toolset is right for the job. > you've never heard of feature-creep, changing environments and requirements, 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?
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. I don't know about the proposed scenario you give. But I do know when my own site felt a little sluggish, I implemented APC and a cron job that preloads all the queries at the beginning of the day. Any changes to a table dump the cache and reload it. Site is now fast and the database is only pounded in the early AM cache preload (which may actually not even be necessary, but I do it just in case there are any scenarios where I change DB and forget to nuke cache for effected queries). If database is your bottleneck, APC (or other caching methods) is your friend. -- 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 Wednesday 24 March 2010 03:17:56 Tommy Pham wrote: > Let's go back to my 1st e-commerce example. The manufacturers list is > about 3,700. The categories is about about 2,400. The products list > is right now at 500,000 and expected to be around 750,000. The site > is only in English. The store owner wants to expand and be I18n: > Chinese, French, German, Korean, Spanish. You see how big and complex > that database gets? The store owners want to have this happens when a > customer clicks on a category: > > * show all subcategories for that category, if any > * show all products for that category, if any, > * show all manufacturers, used as filtering, for that category and > subcategories * show price range filter for that category > * show features & specifications filter for that category > * show 10 top sellers for that category and related subcategories > * the shopper can then select/deselect any of those filters and > ability to sort by manufacturers, prices, user rating, popularity > (purchased quantity) > * have the ability to switch to another language translation on the fly > * from the moment the shopper click on a link, the response time (when > web browser saids "Done" in the status bar) is 5 seconds or less. > Preferably 2-3 seconds. Will be using stopwatch for the timer. > > Now show me a website that meets those requirements and uses PHP, I'll > be glad to support your argument about PHP w/o threads :) BTW, this > is not even enterprise requirement. I may have another possible > project where # products is over 10 million easily. With similar > requirements when the user click on category. Do you think this site, > which currently isn't, can run on PHP? > > Regards, > Tommy If you design and code correctly. Yes. If you want to use someting alredy. Try TYPO3. PS: Your arguments are something about implementation not something about platform abilities. You can do this things any server side programming with enough hardware. Regards Sancar -- 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 6:34 AM, Rene Veerman wrote: > On Wed, Mar 24, 2010 at 12:28 PM, Tommy Pham wrote: > > > > Funny you should mention all that. Let's say that you're longer with > > that company, either by direct employment or contract consultant. > > You've implemented C because you need 'thread'. Now your replacement > > comes in and has no clue about C even though your replacement is a PHP > > guru. How much headache is maintenance gonna be? Scalability? > > Portability? wow > > > Thanks for posting this before i had to. > > +1, +1, +1... > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > [Sorry for posting here, my earlier response went to a partial thread] Rene, I don't want you to jump ship. You've been helpful to many other posters, and I appreciate various points of view on all subjects, yours included. Please bottom post in the future now that you know of their preference, and please step back for a few and take some time to relax. No harm, no foul (a phrase I appreciate more and more as I slow down on the court ;) I will confess that I understand why Rene feels ganged up on. While the words used to counter him have been quite restrained, his request for a feature has been consistently met with "You must be doing the other stuff wrong" responses. That doesn't speak to the heart of the issue, and Rene from previous posts has shown that he's quite capable on many fronts. Requesting a new feature does not necessarily mean that somebody isn't best using the current features. For example, in the past, PHP considered a new array syntax, but those against it expressed the belief that the current syntax was sufficient: http://markmail.org/message/rsi4welftwou24p3 Sufficient, PHP often is, but it's competing within a diverse eco-system of increasingly capable languages, and I hope we all keep focused on how it can continue to improve. The value of our skill set is largely dependent on the strength of the other PHP developers out there, the availability of PHP, etc. Whether it's a new array syntax, threading, or any other new feature, I hope we all carefully deliberate on what the feature may do to attract new PHP developers and keep existing PHP developers. True, developers can mix and match languages as needed, but I find I hear phrases like "Well, if language X doesn't support Y, then why not use langauge Z for everything." That doesn't mean I agree with that approach, but sentiment among executives does exist. For the record, I liked the alternative array syntax suggested in my example, and I've said earlier in this thread that I'd like threading. My example is my web framework. It doesn't use front- or page-level-controllers, but rather micro-controllers with embedded views. Autonomous views could be elegantly processed in parallel, speeding the rendering of the page. And, in F# and Clojure, this is exactly what I'm doing. It would be really nice to do this in PHP, too, as I really do love PHP. And in many examples, caching is not the answer (information is often user specific and/or time specific.) Perhaps some of you won't agree with this need, but that doesn't mean it's not playing a role in the value proposition of PHP in my work. That said, this is not the only reason I'd be for threading, as I believe PHP is directly competing with several other very nice languages in many situations (Python, Ruby, Scala, C#, F#, Scala, etc.), and they all offer some form of threading, and I hope PHP continues to attract a broad range of talents amongst the alternatives. Now, do I expect threading in the near future? NO. PHP does present some special issues for this feature. However, I hope we all will carefully consider where we want PHP to be in the future language market whenever we consider any new features, be they arrays, threading, or mind control ;) I'll not speak anything further on this thread. Adam -- Nephtali: PHP web framework that functions beautifully http://nephtaliproject.com
Re: [PHP] Will PHP ever "grow up" and have threading?
> > > Rene, I don't want you to jump ship. You've been helpful to many other posters, and I appreciate various points of view on all subjects, yours included. Please bottom post in the future now that you know of their preference, and please step back for a few and take some time to relax. No harm, no foul (a phrase I appreciate more and more as I slow down on the court ;) I will confess that I understand why Rene feels ganged up on. While the words used to counter him have been quite restrained, his request for a feature has been consistently met with "You must be doing the other stuff wrong" responses. That doesn't speak to the heart of the issue, and Rene from previous posts has shown that he's quite capable on many fronts. Requesting a new feature does not necessarily mean that somebody isn't best using the current features. For example, in the past, PHP considered a new array syntax, but those against it expressed the belief that the current syntax was sufficient: http://markmail.org/message/rsi4welftwou24p3 Sufficient, PHP often is, but it's competing within a diverse eco-system of increasingly capable languages, and I hope we all keep focused on how it can continue to improve. The value of our skill set is largely dependent on the strength of the other PHP developers out there, the availability of PHP, etc. Whether it's a new array syntax, threading, or any other new feature, I hope we all carefully deliberate on what the feature may do to attract new PHP developers and keep existing PHP developers. True, developers can mix and match languages as needed, but I find I hear phrases like "Well, if language X doesn't support Y, then why not use langauge Z for everything." That doesn't mean I agree with that approach, but sentiment among executives does exist. For the record, I liked the alternative array syntax suggested in my example, and I've said earlier in this thread that I'd like threading. My example is my web framework. It doesn't use front- or page-level-controllers, but rather micro-controllers with embedded views. Autonomous views could be elegantly processed in parallel, speeding the rendering of the page. And, in F# and Clojure, this is exactly what I'm doing. It would be really nice to do this in PHP, too, as I really do love PHP. And in many examples, caching is not the answer (information is often user specific and/or time specific.) Perhaps some of you won't agree with this need, but that doesn't mean it's not playing a role in the value proposition of PHP in my work. That said, this is not the only reason I'd be for threading, as I believe PHP is directly competing with several other very nice languages in many situations (Python, Ruby, Scala, C#, F#, Scala, etc.), and they all offer some form of threading, and I hope PHP continues to attract a broad range of talents amongst the alternatives. Now, do I expect threading in the near future? NO. PHP does present some special issues for this feature. However, I hope we all will carefully consider where we want PHP to be in the future language market whenever we consider any new features, be they arrays, threading, or mind control ;) I'll not speak anything further on this thread. Adam -- Nephtali: PHP web framework that functions beautifully http://nephtaliproject.com
Re: [PHP] Will PHP ever "grow up" and have threading?
Hi gang: When I'm confronted with a large number of emails to read under one subject (like this one), I put on the "Robert, Stuart, Brown" Filter. As such, I only read their post and everything gets to the point quicker and makes more sense. Cheers, tedd -- --- http://sperling.com http://ancientstones.com http://earthstones.com -- 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?
2010/3/24 Rene Veerman : > yea right.. > > i really want to keep my code base in 1 language, because that > simplifies everything later on imo. > you people, who are against the evolotion of php towards cloud > computing, would force me to do mixed-languages projects or even > rewrite large sections of my codebase if as i want, i keep my codebase > in 1 language. > > maybe now you understand why i'm so pissed off with you know-it-alls. > > Why did you chose PHP in the first place? And as a programmer you have to be flexible despite the chosen language. C++/C programmer sometimes must use assembler, in asp/dot.net have to switch between VB,C# and so on. nothing new. thats why languages now days are mainly based on C/C++ to make it easier to jump between languages. (PHP, Perl, Java, JavaScript is based on C/C++ aso) -- MvH / Hans Åhlin Tel: +46761488019 http//www.kronan-net.com/ -- 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?
From: larry at garfieldtech dot com > On 3/23/10 6:04 PM, Tommy Pham wrote: >> If throwing hardware at it won't work because of the above mentioned, >> then you would change the design right? How long would that take? >> What if PHP has threads, how long would it take you implement threads >> with minor changes versus and overhaul of application design, coding, >> QA, etc... In summary, you're saying that PHP can not grow/evolve with >> business right? 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. > > But let's consider what adding threads to PHP would take. That would > mean making PHP a shared-memory architecture, so that different requests > now operated in the same memory space. That means RAM-based > persistence. That means needing to write thread-safe PHP libraries. > (Not the ones in C; I mean the millions of lines of code of PHP already > out there.) > > In short, adding threading support to PHP means PHP is no longer PHP. > It's Java with dollarsigns. It's a complete and total rewrite of the > entire language runtime and environment, and all of the code build atop it. > > The idea that you could "just add threads" to PHP and make it > "enterprise-ready" is so naive it's mind boggling. This pretty much describes the path the Perl community took several years back. While they didn't end up looking like Java, they still actively discourage the use of threads in Perl because nobody has a good handle on which portions of CPAN are actually thread safe. It will likely take them several more years before they find and fix all of the libraries and modules that aren't. Bob McConnell -- 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: popular : facebook youtube etc I doubt very much you're popular like facebook. Nothing is as popular as facebook. http://www.fastcompany.com/1584920/facebook-now-more-popular-than-google-let-the-ad-wars-begin Unless you're actually a facebook developer... which I doubt. 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. No, you've imposed the toolset and now you want to change the set. Nothing wrong with wanting a new tool in your bag, but you're current arguments aren't really passing muster. 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?
Rene Veerman wrote: well i have this very strong gut feeling that at least some php apps stand to gain so much efficiency per box with threading and shared memory that they'll save not only their operators a lot of headaches, but also significant money and energy. that in turn benefits those outside the company using php. Sometimes when I have a gut feeling, it's indigestion >:D 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?
Tommy Pham wrote: On Wed, Mar 24, 2010 at 3:52 AM, Lester Caine wrote: Tommy Pham wrote: How exactly will threading in PHP help with the size of the database? That makes no sense to me, please help me understand how you think threading will help in this scenario. Looking at my example, not just the rows There are other features that require queries to a DB for simple request of a category by a shopper, instead of running those queries in series, running them in parallel would yield better response time. Database size issues are tackled with clustering, caching and DB optimisation. Threading in the language accessing the DB has no advantage here. Yes, it does. As mentioned several times, instead of running the queries in series, run them in parallel. If each of the queries takes about .05 to .15 seconds. How long would it take to run them in serial? How long do you it take to run them in parallel? Any you have a database that can actually handle that? If the database is taking 0.1 seconds per query, and you have 10 queries, then getting the data is going to take 1 second to generate. If you want some slow query to be started, and come back for the data later, then I thought we already had that? But again this is part of the database driver anyway. No need to add threading to PHP to get the database connection to pull data in the most efficient way. And one does not write the driver in PHP? We are using C there already? -- Lester Caine - G8HFL - 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? You seem to think that those 10 queries are happening in isolation. What about the other 100 concurrent users all smacking the db server with 10 queries. The db server is just going to queue them and serially process them as each of it's own processing threads become free. In high concurrency situations threading isn't going to make much difference, in fact it's very likely to decrease performance because now you've added the overhead of thread concurrency handling in PHP when the db server is already handling this issue between the multiple web server requests. 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
