Re: [PHP] Will PHP ever "grow up" and have threading?
Tommy Pham wrote: > The company started small. As their business grows because they have > products & services that do not exist in the marketplace, their > hardware are already growing along side with it, (load balancers, > clusters). So then your solution is buy bigger/more boxes? What if > the their server room is filled and already using recent hardware. Same answer - buy a bigger box (i.e. serverroom). I would certainly also start a redesign from the ground up, but to solve the immediate problem, get more hardware. > Their current business needs doesn't need to move to a bigger > building. What then? Hire data center's services? What if they want > to protect their proprietary break through products and services? Rent space and maybe hardware. That's what most businesses do. > What about unnecessary additional total cost of ownership (licenses, > power consumption, etc...) for more/bigger boxes, even if they have > available space, that could be avoided by just implementing threads? If you believe threading is such a silver bullet, I really think you need to reconsider. This business has already invested in more hardware to satisfy demand, so the application has some scalability - presumably achieved by running multiple processes. Threads have some advantages over processes, but when your design doesn't take that into account anyway, why do you need threads? [snip] > In summary, you're saying that PHP can not grow/evolve with > business right? Certainly not. PHP is just a language, like most other programming languages, it doesn't grow nor does it evolve a lot. (the OOP paradigm is an example of where PHP evolved). I'm saying that a back-of-a-fag-packet design won't grow nor evolve very well, and its inevitable shortcomings will not be solved by bolting on "threading". > If the company started small and want to use available open source > solutions, then grow quickly because of their unique and quality > products and services, and become enterprise level with-in a few > years, what then? Slow down business growth just so that IT can > migrate everything to another language? Of all the enterprise > applications I've seen, they used threads. Tommy, that's not about the language, that's a design issue. Run PHP in multiple processes, and you've got the parallelism you seem to seek. /Per -- Per Jessen, Zürich (6.8°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
On Tue, Mar 23, 2010 at 9:55 PM, Teus Benschop wrote: > On Tue, 2010-03-23 at 21:32 -0700, Tommy Pham wrote: >> # of requests / second can be solved by load balancers/clusters. What >> about the multiple answers for a simple request per user as in my >> example? How you would solve that if not by threading? Amazon has >> about 30 million products and they have filters similar to what I >> mentioned. But when clicking on one of the I18n site at the bottom, >> you're taken to another server, which looks like it uses a different >> DB back end (I could be wrong) and you don't get instant translation >> of the category you're looking at. Their response time is about 3 >> seconds on my 10mbs (not cable) download. As for what programming >> language they use... >> > > Well, the multiple answers for a simple request per user as in your > example, seem to be a lot of information to display all on one page, and > present all that information to the user in one request. I would > probably resolve it, IMHO, by using pagers. That is, only part of the Pagers are needed when there's a lot of products to display. But using the filters and show them is different. Look at Amazon (not endorsing it). Click any category. You'll see what I mean by the filters (manufacturers, price range, subcategories, etc) and the display requirements (specials, bestsellers) as I mentioned. They also have other things, like shoppers' discussions, on that page too. Think about how many queries they have to run for all that info to show based on a simple request of a 'category'. Then time the response time. > information is shown to the user at one time, and the user can page > through that information so as to get to other bits of information. If > only part is shown, then the database query becomes so much faster > (hopefully), and PHP still can do all of it in one thread. > > A PHP application, by the nature of PHP, consists of small page requests > to be done at one time, rather than move a lot of information around per > request. Thinking the PHP-way requires some study because, as said, the > information is presented or moved about in small chunks. Desktop > applications, and probably Java web applications (I have no experience > with Java but have read up on it a little) work differently. A > successful PHP application is redesigned from the ground up, rather than > remorphing a Java or other desktop application in PHP without changing > the design principles. > > The key to makign your eCommerce application snappy, is, I think, not > threading, but optimization of database queries. And another key is that > less information presented to the user is usually clearer to the user, > and thus they feel better at the site, and would return sooner to buy > something. The real head-ache here and the difficult part is: How to > design a clear and clean interface for the user. It's not threading. > > Teus. > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
On Tue, Mar 23, 2010 at 9:49 PM, Larry Garfield wrote: > On Tuesday 23 March 2010 11:32:10 pm Tommy Pham wrote: >> On Tue, Mar 23, 2010 at 9:06 PM, Teus Benschop > wrote: >> > When looking at PHP as used in enterprise class applications, we can see >> > the following happening. Let imagine that we have a site that gets a >> > 1000 requests per second. That seems to be a good candidate for >> > threading so as to be able to handle the 1000 requests per second. The >> > site runs PHP and Apache. Well, what happens? Each request coming in is >> > handed of to a separate instance of Apache. Thus the site would be able >> > to process many requests simultaneously. It looks as if parallel >> > computing is taking place here, which looks much like threading. Even >> > though PHP itself does not know about threads, and does not need to, I >> > think, the whole process of handling the 1000 requests per second uses >> > parallel computing. There are no performance bottle-necks here. Teus. >> >> # of requests / second can be solved by load balancers/clusters. What >> about the multiple answers for a simple request per user as in my >> example? How you would solve that if not by threading? Amazon has >> about 30 million products and they have filters similar to what I >> mentioned. But when clicking on one of the I18n site at the bottom, >> you're taken to another server, which looks like it uses a different >> DB back end (I could be wrong) and you don't get instant translation >> of the category you're looking at. Their response time is about 3 >> seconds on my 10mbs (not cable) download. As for what programming >> language they use... > > Honestly, how WOULD you solve that with threading? You describe a page that > needs to be generated that has a half-dozen queries against the database > ranging from simple to moderately complex, some of which are site-generic and > some are user-specific. > > How does one solve that with threading? > > 1) Run the site-generic queries once and cache them in memory and let other > threads just use that query result. You can do that without threads. Just > render that part of the page and cache that string to disk, to the database, > or to memcache. If the memecache server is on the same box then it should be > identical to the threading version, performance-wise. (Give or take VM > considerations.) > > 2) Push the user-specific DB queries to separate threads so they can run in > parallel. All that does is push the hard work off onto the DB server, which > is > still running the same number of queries. And PHP can't respond until all of > the queries finish anyway, and the DB server will respond no faster, so you're > really gaining nothing. > > You keep saying "how would you solve this without threads?" as if they're some > magical speed fairy dust. Given the scenario you describe, I don't even see > how threads would buy you anything at all. > > Where threads would be useful is for lots of very small writes on rapidly > changing data. I would never want to write, say, the World of Warcraft > servers without threading and a persistent runtime, but then I wouldn't want > to write them in PHP to begin with. > > Insert that old saying about hammers and nails here. > > --Larry Garfield > The difference is doing all those queries in serial operations (one after another) versus parallel operations (threads). Instead of waiting, for example, about .05 to .25 sec for each of those queries, the total wait time would be diminishes since each thread would execute a query. Either way, the DB is still doing the required total work. Difference is serial & parallel operations as I iterated several times. Being running in parallel, the web browser will be getting the required info faster since PHP is able to get all the info faster. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
On Tue, 2010-03-23 at 21:32 -0700, Tommy Pham wrote: > # of requests / second can be solved by load balancers/clusters. What > about the multiple answers for a simple request per user as in my > example? How you would solve that if not by threading? Amazon has > about 30 million products and they have filters similar to what I > mentioned. But when clicking on one of the I18n site at the bottom, > you're taken to another server, which looks like it uses a different > DB back end (I could be wrong) and you don't get instant translation > of the category you're looking at. Their response time is about 3 > seconds on my 10mbs (not cable) download. As for what programming > language they use... > Well, the multiple answers for a simple request per user as in your example, seem to be a lot of information to display all on one page, and present all that information to the user in one request. I would probably resolve it, IMHO, by using pagers. That is, only part of the information is shown to the user at one time, and the user can page through that information so as to get to other bits of information. If only part is shown, then the database query becomes so much faster (hopefully), and PHP still can do all of it in one thread. A PHP application, by the nature of PHP, consists of small page requests to be done at one time, rather than move a lot of information around per request. Thinking the PHP-way requires some study because, as said, the information is presented or moved about in small chunks. Desktop applications, and probably Java web applications (I have no experience with Java but have read up on it a little) work differently. A successful PHP application is redesigned from the ground up, rather than remorphing a Java or other desktop application in PHP without changing the design principles. The key to makign your eCommerce application snappy, is, I think, not threading, but optimization of database queries. And another key is that less information presented to the user is usually clearer to the user, and thus they feel better at the site, and would return sooner to buy something. The real head-ache here and the difficult part is: How to design a clear and clean interface for the user. It's not threading. Teus. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
On Tue, Mar 23, 2010 at 9:13 PM, Phpster wrote: > Most if that stuff should only be in the db as a reference and when editing > te lists. The actual user acessed data should sit in simple XML files that > can be passed to the client, broken out by category or prod line. The > reasons are simple, database access time is going to suck, no matter what > you are running. And why would you ever need to run translation real time. I > can tell you from persoanl experience that such solution totally blows. I > lost that battle at work and the current solution build every field on the > fly each time with translation ( supporting 12 languages) and it's damn > slow. Cache out whatever you can, to an in memory cache or to the file > system. Let the web server do it's job of serving files, not processing > upteen little bits of data from a db. > > It's about design, from all I've seen, threading introduces about as many > challenges as problems it solves. > > Bastien If having the products info in categorized XML files as you mention, why the need for DB then? What about some product name changes to correctly describe the product without the informed shopper having to read the description/specifications? The translation is fetched from the DB and not using any 3rd party software translation on the fly. > > Sent from my iPod > > On Mar 23, 2010, at 9:17 PM, 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 >> >> -- >> 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 Tuesday 23 March 2010 11:32:10 pm Tommy Pham wrote: > On Tue, Mar 23, 2010 at 9:06 PM, Teus Benschop wrote: > > When looking at PHP as used in enterprise class applications, we can see > > the following happening. Let imagine that we have a site that gets a > > 1000 requests per second. That seems to be a good candidate for > > threading so as to be able to handle the 1000 requests per second. The > > site runs PHP and Apache. Well, what happens? Each request coming in is > > handed of to a separate instance of Apache. Thus the site would be able > > to process many requests simultaneously. It looks as if parallel > > computing is taking place here, which looks much like threading. Even > > though PHP itself does not know about threads, and does not need to, I > > think, the whole process of handling the 1000 requests per second uses > > parallel computing. There are no performance bottle-necks here. Teus. > > # of requests / second can be solved by load balancers/clusters. What > about the multiple answers for a simple request per user as in my > example? How you would solve that if not by threading? Amazon has > about 30 million products and they have filters similar to what I > mentioned. But when clicking on one of the I18n site at the bottom, > you're taken to another server, which looks like it uses a different > DB back end (I could be wrong) and you don't get instant translation > of the category you're looking at. Their response time is about 3 > seconds on my 10mbs (not cable) download. As for what programming > language they use... Honestly, how WOULD you solve that with threading? You describe a page that needs to be generated that has a half-dozen queries against the database ranging from simple to moderately complex, some of which are site-generic and some are user-specific. How does one solve that with threading? 1) Run the site-generic queries once and cache them in memory and let other threads just use that query result. You can do that without threads. Just render that part of the page and cache that string to disk, to the database, or to memcache. If the memecache server is on the same box then it should be identical to the threading version, performance-wise. (Give or take VM considerations.) 2) Push the user-specific DB queries to separate threads so they can run in parallel. All that does is push the hard work off onto the DB server, which is still running the same number of queries. And PHP can't respond until all of the queries finish anyway, and the DB server will respond no faster, so you're really gaining nothing. You keep saying "how would you solve this without threads?" as if they're some magical speed fairy dust. Given the scenario you describe, I don't even see how threads would buy you anything at all. Where threads would be useful is for lots of very small writes on rapidly changing data. I would never want to write, say, the World of Warcraft servers without threading and a persistent runtime, but then I wouldn't want to write them in PHP to begin with. Insert that old saying about hammers and nails here. --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
On Tue, Mar 23, 2010 at 9:06 PM, Teus Benschop wrote: > When looking at PHP as used in enterprise class applications, we can see > the following happening. Let imagine that we have a site that gets a > 1000 requests per second. That seems to be a good candidate for > threading so as to be able to handle the 1000 requests per second. The > site runs PHP and Apache. Well, what happens? Each request coming in is > handed of to a separate instance of Apache. Thus the site would be able > to process many requests simultaneously. It looks as if parallel > computing is taking place here, which looks much like threading. Even > though PHP itself does not know about threads, and does not need to, I > think, the whole process of handling the 1000 requests per second uses > parallel computing. There are no performance bottle-necks here. Teus. > # of requests / second can be solved by load balancers/clusters. What about the multiple answers for a simple request per user as in my example? How you would solve that if not by threading? Amazon has about 30 million products and they have filters similar to what I mentioned. But when clicking on one of the I18n site at the bottom, you're taken to another server, which looks like it uses a different DB back end (I could be wrong) and you don't get instant translation of the category you're looking at. Their response time is about 3 seconds on my 10mbs (not cable) download. As for what programming language they use... -- 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?
Most if that stuff should only be in the db as a reference and when editing te lists. The actual user acessed data should sit in simple XML files that can be passed to the client, broken out by category or prod line. The reasons are simple, database access time is going to suck, no matter what you are running. And why would you ever need to run translation real time. I can tell you from persoanl experience that such solution totally blows. I lost that battle at work and the current solution build every field on the fly each time with translation ( supporting 12 languages) and it's damn slow. Cache out whatever you can, to an in memory cache or to the file system. Let the web server do it's job of serving files, not processing upteen little bits of data from a db. It's about design, from all I've seen, threading introduces about as many challenges as problems it solves. Bastien Sent from my iPod On Mar 23, 2010, at 9:17 PM, 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 -- 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 Tue, 2010-03-23 at 19:08 -0700, Tommy Pham wrote: > The response time, max 5 seconds, will be tested on local gigabit LAN > to ensure the adequate response (optimized DB & code & proper > hardware) without worrying about users' connection limit and site's > upload bandwidth limit (which can easily rectify). Then thereafter > will be doing stress test of about 10 concurrent users. As for the > major queries, that's where threads come in, IMO, because those > queries depend on 1 primary parameter (category ID) and 1 secondary > parameter (language ID). This particular site starts with 500 > products about 15 categories, without many of those mentioned filters, > later grew to its current state. > The bottle neck looking at speed in this example seems to be the database backend, not PHP. What would be needed is a fast database, and SQL queries optimized for speed. Teus. -- 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?
When looking at PHP as used in enterprise class applications, we can see the following happening. Let imagine that we have a site that gets a 1000 requests per second. That seems to be a good candidate for threading so as to be able to handle the 1000 requests per second. The site runs PHP and Apache. Well, what happens? Each request coming in is handed of to a separate instance of Apache. Thus the site would be able to process many requests simultaneously. It looks as if parallel computing is taking place here, which looks much like threading. Even though PHP itself does not know about threads, and does not need to, I think, the whole process of handling the 1000 requests per second uses parallel computing. There are no performance bottle-necks here. Teus. -- 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?
First of all, I'll apologize for the top-post. My DROID doesn't give me the option of top or bottom. So not ready for enterprise. Secondly, I'll append to the statements made by Larry that, unless it's non-web based, there are far more layers involved before, during, and after PHP's execution. Threading is fantastic if you're not relying on several other components (which are likely non-threaded themselves). On Mar 23, 2010 7:27 PM, "la...@garfieldtech.com" wrote: On 3/23/10 6:04 PM, Tommy Pham wrote: > If throwing hardware at it won't work because of the above ... The word "enterprise" is meaningless in this context because it provides no context for the distinction. What does "enterprise" mean? Gets Captain Kirk to his next date? Is OpenOffice.org's plugin download site enterprise? Is Sony BMG enterprise? The sites for the cities of London and Athens? Whitehouse.gov? That's just a couple of sites now running on Drupal, a particular single-threaded PHP application. That's not counting the thousands of similar organizations running PHP (not even PHP-wrapping-custom-C like Yahoo) applications of various and sundry kinds. (Wikipedia anyone?) PHP *is* in the enterprise and quite happy there. "Not ready for the enterprise" is a totally meaningless statement. Similarly, if you cannot think of any way to scale an application that doesn't involve threads then I question your competence as a programmer. Sure, threads can be one way to speed things up. There are lots and lots of others that may be more or less appropriate depending on the circumstances. Threads have their own scaling issues, namely they have to live within the same process on the same box. That means when you hit the maximum size of your server, you're done. That doesn't mean threads are bad, but they have their trade-offs just like everything else does. 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. --Larry Garfield -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub...
Re: [PHP] Will PHP ever "grow up" and have threading?
Paul M Foster wrote: On Tue, Mar 23, 2010 at 06:17:56PM -0700, 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? That strikes me as a pretty stiff target, no matter how you look at it. You effectively want 6 major queries at once, plus response in under 3 seconds on a 75 row product table. I'm not sure I could produce that kind of performance in C at the command line. (I'm sure some smart guy on the list will say he can do it in 2 seconds flat over a 10 Base 2 network with teletypes and acoustic modems.) I'm not sure why you consider this 6 major queries. To show all sub-categories for a category is a major query only if you need to recursively gather sub-categories. Admittedly that would be a slow hit to the database server on first request, but afterwards one would expect the tree to be cached so the next request would be very fast due to priming of the cache. Show all products for a category should be quite fast, the category would be associated with an integer ID upon which I would presume indexing has occured. Presumably "show all" means show all products in a paged manner. The same principles should show true for manufacturer. Price range also plays nicely with indexes. Features and specifications may be a biut of a hump, but it depends. It's hard to say exactly what is meant by this filter. The top 10 sellers might be an issue, but I don't see why a cron job can't handle updating top sellers information so that this is an indexable field. I'm not sure why language translation would be an issue. Presumably if you have support for one, switching to another requires the same legwork with different pants. Also, it's notable that all of the search data is based on need to read only. This screams replication to me if the server is very busy. The big thing about indexes is that the more rows you add, the time to retrieve a particular indexed row only grows logarithmically. 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 Tue, Mar 23, 2010 at 6:57 PM, Paul M Foster wrote: > On Tue, Mar 23, 2010 at 06:17:56PM -0700, 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? > > That strikes me as a pretty stiff target, no matter how you look at it. > You effectively want 6 major queries at once, plus response in under 3 > seconds on a 75 row product table. I'm not sure I could produce that > kind of performance in C at the command line. (I'm sure some smart guy > on the list will say he can do it in 2 seconds flat over a 10 Base 2 > network with teletypes and acoustic modems.) > > Which brings me to my question. Why do people expect console-level > performance from a web browser? It's kind of rhetorical, since people > want everything they can get and more all the time. But if performance > came up as a customer question for me, I'd make it clear that they're > not going to get console-level performance from a web browser, unless > they want to spend a whole lot more money. Neither the world wide web > nor browser software were ever designed primarily with speed in mind. > The internet is not your local 64-bit 10 gigabyte memory loaded machine. > > Paul > > -- > Paul M. Foster > 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. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
On Tue, Mar 23, 2010 at 06:17:56PM -0700, 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? That strikes me as a pretty stiff target, no matter how you look at it. You effectively want 6 major queries at once, plus response in under 3 seconds on a 75 row product table. I'm not sure I could produce that kind of performance in C at the command line. (I'm sure some smart guy on the list will say he can do it in 2 seconds flat over a 10 Base 2 network with teletypes and acoustic modems.) Which brings me to my question. Why do people expect console-level performance from a web browser? It's kind of rhetorical, since people want everything they can get and more all the time. But if performance came up as a customer question for me, I'd make it clear that they're not going to get console-level performance from a web browser, unless they want to spend a whole lot more money. Neither the world wide web nor browser software were ever designed primarily with speed in mind. The internet is not your local 64-bit 10 gigabyte memory loaded machine. 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?
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 I don't currently know a site, sounds like a fun job though. 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? Yes, I do. There's nothing in your requirements above that sound particularly difficult for PHP to handle with a good design and lots of caching... and of course the right hardware. I think you're hung up on the numbers a bit... those aren't very big numbers for a database. 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 Tue, Mar 23, 2010 at 6:17 PM, 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 forgot to mention: * show 10 random sale specials for that category and 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 > -- 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?
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 -- 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 Tue, Mar 23, 2010 at 3:33 PM, Per Jessen wrote: Tommy Pham wrote: On Tue, Mar 23, 2010 at 2:04 AM, Per Jessen wrote: Use the right tool for the right job - PHP is a scripting/interpreted language, it does not need threading (IMO of course). -- Per Jessen, Zürich (9.4°C) I couldn't agree more. But here's a real life example. Your client has a forum and is using phpbb for their in house use. They also have an in house custom PHP app, integrated with phpbb, built to suit their needs. Now they want to implement some kind of CMS. You come in and implemented a PHP based CMS to integrate into their existing applications. Then you realize something troublesome, you have a performance issue where it could be resolved by implementing thread. What are you going to do? The standard, mature, experienced answer is - buy a bigger box. The company started small. As their business grows because they have products & services that do not exist in the marketplace, their hardware are already growing along side with it, (load balancers, clusters). So then your solution is buy bigger/more boxes? What if the their server room is filled and already using recent hardware. Their current business needs doesn't need to move to a bigger building. What then? Hire data center's services? Very few companies have a legitimate reason to run their own server room at this point in time and should be using a data center if they are not already. Data centers have excellent bandwidth, diesel generators to keep things live during sustained power outages, temperature control to keep things cool, and often have technicians on hand with spare parts that can take care of many hardware issues 24/7. -- 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 Tommy Pham : > On Tue, Mar 23, 2010 at 3:33 PM, Per Jessen wrote: >> Tommy Pham wrote: >> >>> On Tue, Mar 23, 2010 at 2:04 AM, Per Jessen wrote: Use the right tool for the right job - PHP is a scripting/interpreted language, it does not need threading (IMO of course). -- Per Jessen, Zürich (9.4°C) >>> >>> I couldn't agree more. But here's a real life example. Your client >>> has a forum and is using phpbb for their in house use. They also have >>> an in house custom PHP app, integrated with phpbb, built to suit their >>> needs. Now they want to implement some kind of CMS. You come in and >>> implemented a PHP based CMS to integrate into their existing >>> applications. Then you realize something troublesome, you have a >>> performance issue where it could be resolved by implementing thread. >>> What are you going to do? >> >> The standard, mature, experienced answer is - buy a bigger box. >> > > The company started small. As their business grows because they have > products & services that do not exist in the marketplace, their > hardware are already growing along side with it, (load balancers, > clusters). So then your solution is buy bigger/more boxes? What if > the their server room is filled and already using recent hardware. > Their current business needs doesn't need to move to a bigger > building. What then? Hire data center's services? What if they want > to protect their proprietary break through products and services? > What about unnecessary additional total cost of ownership (licenses, > power consumption, etc...) for more/bigger boxes, even if they have > available space, that could be avoided by just implementing threads? > That screams poor code design. Then to solve the problem might not be threading or change of language but a reanalyze of the code and the design, probably a re-write. >> [snip] >>> What do you think the client's response is when their need for the >>> solution requires a short time frame of, if not immediate, >>> implementation? >> >> There are no immediate solutions to immediate performance problems. If >> you have a poor design that restricts your throughput, you can 1) throw >> hardware at it or 2) change the design. At some point you'll hit yet >> another limit with 1), and you are forced back to 2). Somewhere along >> the line the original designer has presumably left or been made to. >> >> >> /Per >> >> -- >> Per Jessen, Zürich (7.5°C) >> > > 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. > Same answer as above. > Regards, > Tommy > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- 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?
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. Regards, Tommy The word "enterprise" is meaningless in this context because it provides no context for the distinction. What does "enterprise" mean? Gets Captain Kirk to his next date? Is OpenOffice.org's plugin download site enterprise? Is Sony BMG enterprise? The sites for the cities of London and Athens? Whitehouse.gov? That's just a couple of sites now running on Drupal, a particular single-threaded PHP application. That's not counting the thousands of similar organizations running PHP (not even PHP-wrapping-custom-C like Yahoo) applications of various and sundry kinds. (Wikipedia anyone?) PHP *is* in the enterprise and quite happy there. "Not ready for the enterprise" is a totally meaningless statement. Similarly, if you cannot think of any way to scale an application that doesn't involve threads then I question your competence as a programmer. Sure, threads can be one way to speed things up. There are lots and lots of others that may be more or less appropriate depending on the circumstances. Threads have their own scaling issues, namely they have to live within the same process on the same box. That means when you hit the maximum size of your server, you're done. That doesn't mean threads are bad, but they have their trade-offs just like everything else does. 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. --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 Tue, Mar 23, 2010 at 3:33 PM, Per Jessen wrote: > Tommy Pham wrote: > >> On Tue, Mar 23, 2010 at 2:04 AM, Per Jessen wrote: >>> >>> Use the right tool for the right job - PHP is a scripting/interpreted >>> language, it does not need threading (IMO of course). >>> >>> >>> -- >>> Per Jessen, Zürich (9.4°C) >>> >>> >> >> I couldn't agree more. But here's a real life example. Your client >> has a forum and is using phpbb for their in house use. They also have >> an in house custom PHP app, integrated with phpbb, built to suit their >> needs. Now they want to implement some kind of CMS. You come in and >> implemented a PHP based CMS to integrate into their existing >> applications. Then you realize something troublesome, you have a >> performance issue where it could be resolved by implementing thread. >> What are you going to do? > > The standard, mature, experienced answer is - buy a bigger box. > The company started small. As their business grows because they have products & services that do not exist in the marketplace, their hardware are already growing along side with it, (load balancers, clusters). So then your solution is buy bigger/more boxes? What if the their server room is filled and already using recent hardware. Their current business needs doesn't need to move to a bigger building. What then? Hire data center's services? What if they want to protect their proprietary break through products and services? What about unnecessary additional total cost of ownership (licenses, power consumption, etc...) for more/bigger boxes, even if they have available space, that could be avoided by just implementing threads? > [snip] >> What do you think the client's response is when their need for the >> solution requires a short time frame of, if not immediate, >> implementation? > > There are no immediate solutions to immediate performance problems. If > you have a poor design that restricts your throughput, you can 1) throw > hardware at it or 2) change the design. At some point you'll hit yet > another limit with 1), and you are forced back to 2). Somewhere along > the line the original designer has presumably left or been made to. > > > /Per > > -- > Per Jessen, Zürich (7.5°C) > 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. 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?
Tommy Pham wrote: > On Tue, Mar 23, 2010 at 2:04 AM, Per Jessen wrote: >> >> Use the right tool for the right job - PHP is a scripting/interpreted >> language, it does not need threading (IMO of course). >> >> >> -- >> Per Jessen, Zürich (9.4°C) >> >> > > I couldn't agree more. But here's a real life example. Your client > has a forum and is using phpbb for their in house use. They also have > an in house custom PHP app, integrated with phpbb, built to suit their > needs. Now they want to implement some kind of CMS. You come in and > implemented a PHP based CMS to integrate into their existing > applications. Then you realize something troublesome, you have a > performance issue where it could be resolved by implementing thread. > What are you going to do? The standard, mature, experienced answer is - buy a bigger box. [snip] > What do you think the client's response is when their need for the > solution requires a short time frame of, if not immediate, > implementation? There are no immediate solutions to immediate performance problems. If you have a poor design that restricts your throughput, you can 1) throw hardware at it or 2) change the design. At some point you'll hit yet another limit with 1), and you are forced back to 2). Somewhere along the line the original designer has presumably left or been made to. /Per -- Per Jessen, Zürich (7.5°C) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
On Tue, Mar 23, 2010 at 2:04 AM, Per Jessen wrote: > > Use the right tool for the right job - PHP is a scripting/interpreted > language, it does not need threading (IMO of course). > > > -- > Per Jessen, Zürich (9.4°C) > > I couldn't agree more. But here's a real life example. Your client has a forum and is using phpbb for their in house use. They also have an in house custom PHP app, integrated with phpbb, built to suit their needs. Now they want to implement some kind of CMS. You come in and implemented a PHP based CMS to integrate into their existing applications. Then you realize something troublesome, you have a performance issue where it could be resolved by implementing thread. What are you going to do? Are you going to say to the client "We seem to have a problem. I suggest we migrate to Java or ASP.Net because threading will resolve the performance issue." Or are you going to spend who knows how long to try find a hack to resolve the issue? What do you think the client's response is when their need for the solution requires a short time frame of, if not immediate, implementation? 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?
Rene Veerman wrote: But i've yet to find a way to keep global objects in memory between http requests, outside $_SESSION, which i believe is just stored to- and loaded from disk between http requests. You can store sessions in a cache and avoid the disk IO. -- 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 23 March 2010 00:02, Daevid Vincent wrote: > douche-bags I think this is about the best way to get the wrong attention. Not everyone has a sense of humour like yours. Maybe no one has a sense of humour like yours. Good luck. Richard. -- - Richard Quadling "Standing on the shoulders of some very clever giants!" EE : http://www.experts-exchange.com/M_248814.html EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 ZOPA : http://uk.zopa.com/member/RQuadling -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
> > > You could implement the features yourself. > > > > Damn, Mr McGlone beat me to it :) > > That's such a STUPID retort I'm so sick of hearing from the FOSS community. > "build it yourself uh huhh uhhh huhhh". Obviously I'm not a low-level C/C++ > coder -- that's WHY I use PHP. :-\ So, you just stay content with the > status quo. I will continue to ask for features to enhance the language. > They may fall on deaf ears, but sometimes... just sometimes... The squeaky > wheel get's the grease. I didn't intend for my reply to sound nasty. After reading your OP, I see that you are a very experienced programmer and I meant for it as a suggestion. -- Blessings David M. I have been driven to my knees many times by the overwhelming conviction that I had nowhere else to go. -- 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?
hmm i use scripted languages because i prefer and they allow/force simple-to-read-code. but that does not mean a scripted language can't evolve to expose "complicated" code constructs like multi-threading and daemon-building in a simple manner too. i'd prefer it if a language like PHP can be used for other things besides webserving too. i also think at least some web-apps could benefit from multi-threading and daemon-building.. particularly web-apps that deal with real-time dataflows. and btw, the distinction between compiled and scripted is not a hard one anymore eh.. not with zend and that facebook php-compiler out there. On Tue, Mar 23, 2010 at 10:04 AM, Per Jessen wrote: > Daevid Vincent wrote: > >> I've been using PHP for a decade or so (since PHP/FI) and love it. The >> one problem that seems to always keep coming back on enterprise level >> projects is the lack of threading. This always means we have to write >> some back-end code in Ruby or Java or C/C++ and some hacky database >> layer or DBUS or something to communicate with PHP. > > Use the right tool for the right job - PHP is a scripting/interpreted > language, it does not need threading (IMO of course). > > > -- > Per Jessen, Zürich (9.4°C) > > > -- > 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?
Daevid Vincent wrote: > I've been using PHP for a decade or so (since PHP/FI) and love it. The > one problem that seems to always keep coming back on enterprise level > projects is the lack of threading. This always means we have to write > some back-end code in Ruby or Java or C/C++ and some hacky database > layer or DBUS or something to communicate with PHP. Use the right tool for the right job - PHP is a scripting/interpreted language, it does not need threading (IMO of course). -- Per Jessen, Zürich (9.4°C) -- 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?
Here's another analogy. For those of us in the field long enough, we see the power of AJAX and we use it in one form or another. For the newbies, they have yet to see it's power nor the requirements to implement it. Threading is similar to that. It's not for everybody. But for those of us that are ready and have need for it, we can implement it IF IT'S THERE, which is the point of OP, although the way he put it isn't exactly welcoming... perhaps he had a very long week and it's just starting too. -- 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 Mon, Mar 22, 2010 at 10:01 PM, Larry Garfield wrote: > On Monday 22 March 2010 10:51:14 pm Tommy Pham wrote: >> Threading is one of the 2 two main reasons why I moved to Java & >> asp.net (C#). I've built a PHP based web crawler about 10 years ago. >> I ran into some problems: cookies, form handling and submission, >> threading, and application variables. I later found some solutions >> for cookies, form handling & submission. But no solution for >> threading and application variables. Thus the move. Here's a simple >> example of one of the many uses for threading. For an e-commerce >> site, when the shopper requests for a category (ID), you can have a >> thread to get all subcategories for that category, another thread to >> get any assigned products, another thread to fetch all manufacturers >> listed under that category, another thread to fetch any filters (price >> ranges, features, specs, etc) set by the store owner that would fall >> under that category, etc... versus what PHP currently doing now: >> fetch subcategories, then fetch assigned products, then fetch >> manufacturers, etc Performance would increase ten fold because of >> parallel (threading) operations versus serial operations. Add that to >> application variable (less memory usage and CPU cycles due to >> creating/GC of variables that could be used for an entire application >> regardless of requests & sessions), you have an excellent tool. >> >> Regards, >> Tommy > > Threading is also much more difficult to program for safely, because thread > order is non-deterministic. Do you really want to unleash hoards of > marginally competent programmers on a threaded enviornment? :-) Marginally competent? I think some, if not many, on this list will disagree with that ;) > > Also, the architecture you describe above is fine if you're scaling a single > server really big. PHP is designed to scale the other direction: Just add > more servers. There's no data shared from one request to another, so there's > no need to share data between web heads. Throw a load balancer in front of it > and spin up as many web servers as you need. Load balancer is used when the server is overloaded with requests and upgrade has reached it's limit. That's not the same thing as a simple request where multiple answers are needed as in my example. If you're thinking of implementing something like my example across multiple servers (where each server will fetch an answer for a simple request) via another method, then you're going to face similar issues as threading ie session/request sync which is equivalent to thread safety/sync/deadlock but now it's worse because it's spread across network where performance issues comes in because internal system IO > (network IO + internal system IO). > > The "shared nothing" design is very deliberate. It has design trade-offs like > anything else. > > PHP is a web-centric language. It's not really intended for building tier-1 > daemon processes, just like you'd be an idiot to try and code your entire web > app in C from the start. Of course since C was engineered to create OSes and (text based) apps when SMP/MC is unheard of. But we're now in the digital era where SMP/MC is very common place. In fact, trying to buy a new desktop/laptop now without a multicore becomes very difficult and undesired. Why not make use of the SMP/MC? :) PHP seems strive and somewhat 'imitate' languages like java & asp.net. Not trying to go off topice but for example: namespace (namespace in asp.net and packages in java). For many of us that don't use namespace now or even when it's not yet implemented, we (PHP web app dev) already implement our own version of it - subfolders. So why not copy or imitate the features that would be more beneficial if not more usability ie threading? PHP is already ahead of java & asp.net in terms of generics, not strong typed. Regards, Tommy > > --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?
ExecSum:
* +1 for better threading features in PHP.
* overloading = inheritance?
* listreaders plz allow ppl to vent some frustration without
starting a flamewar.
Threading can be implemented in PHP with an
fopen('http://yourserver.com/url')->fread()_all_threads+usleep(50ms)->fclose()+process
loop.
My own newsscraper threads well like this.
The central script figures out what sites to scrape, and the treaded
subsystem makes sure 1 page per site per N seconds is retrieved.
But i've yet to find a way to keep global objects in memory between
http requests, outside $_SESSION, which i believe is just stored to-
and loaded from disk between http requests.
However, now that i think of it, you could have large pieces of
software stay in memory in a single php script that runs forever and
reads commands (as arrays) out of files (on memory disk?) (put there
by "thread-scripts") and [the "forever running script"] outputs to
stdout, which is caught by the thread-scripts, then passed back to the
thread-caller via fread().
I usually use json for such constructs.
But it's a total hack of course, and i have no idea about performance
issues or even timing bugs. it's "theoretically possible"..
>there is NO reason NOT to let
> the developer choose WHICH of the list of parameters they want to set in a
> function/method call aside from being stubborn! Especially when there are
> many parameters and you can't overload functions like you can in Java
well you could shove all the params in an array, then shove that to
the function called, _or_ a preparatory function that calls the old
function.
as for overloading functions, i think with a bit of cleverness you can
come up with a class / set of functions that simulate overloading of
functions and even inheritance. i for a fact simulate polymorphism
with $functionName_fromPluginX ($params).
i smell all the ingredients that would allow you to overload functions
in php aswell. you'd just have to call things a bit differently,
perhaps like
$var = $overloadingManager->call ('functionName',
'context(object-instance-id)', $param1, $param2).
Better yet; aren't OOP's (and php5's) inheritance features (for
classes) similar to functions overloading? k, it forces you to group
such functions into an object, and derivations into subobjects, but
that's not a show-stopper at all.. You can always ignore the object
boundary and have 1 object-tree for all functions that require
overloading.
& lastly, about the politics of this mail-thread;
imo, it's the ones who "open the counterattack" who start the
flamewar, out of something that is clearly in this case just venting
some frustration with at least partially valid reasons..
imo, it would be wiser to have offered the guy some actual tips and/or
a casual "hey, you could've phrased it friendlier, given the fact that
php costs nothing and all, dude", rather than grabbing the
flamethrower and setting it to vaporize.
On Tue, Mar 23, 2010 at 1:02 AM, Daevid Vincent wrote:
> I've been using PHP for a decade or so (since PHP/FI) and love it. The one
> problem that seems to always keep coming back on enterprise level projects
> is the lack of threading. This always means we have to write some back-end
> code in Ruby or Java or C/C++ and some hacky database layer or DBUS or
> something to communicate with PHP.
>
> Will PHP ever have proper threading? It would sure let the language take
> the next logical leap to writing applications and daemons. I love the idea
> that Rails/Ruby have where you can just load objects in memory once and
> keep using them from page to page (this is NOT the same as a $_SESSION,
> it's way more flexible and powerful).
>
> But more importantly, in one application I'm working on, we need to connect
> to an Asterisk system for the IVR abilities. This means we have Ruby doing
> all that fun stuff and PHP doing the web stuff, but we're also duplicating
> a LOT of work. Both Ruby AND PHP now have to have ORMs for the user who's
> calling in, advertisements served, products shown, etc. We could have used
> Rails for the web portion, but I want to stay with PHP and I'm sure I don't
> have to explain to you PHPers why that is. Without threads, PHP just isn't
> even an option or only one user would be able to call in at a time.
>
> The pcntl stuff is not feasible. It's a hack at best. Spawning multiple
> scripts is also a recipie for disaster.
>
> When will the PHP core-devs (Zend?) realize that PHP is much more than a
> hook to a database. It's much more than web pages.
>
> Is this a case of "it's too hard"? Or is it a case of PHP core developers
> just being douche-bags like they are about the whole
> "foo($set_this_parameter=$bar);" bull$hit??! (there is NO reason NOT to let
> the developer choose WHICH of the list of parameters they want to set in a
> function/method call aside from being stubborn! Especially when there are
> many parameters and you can't overload functions like you can in Java or
> other typed languages
Re: [PHP] Will PHP ever "grow up" and have threading?
Op 3/23/10 12:02 AM, Daevid Vincent schreef: > I've been using PHP for a decade or so (since PHP/FI) and love it. The one well they certainly ripped you a new one didn't they :) why no threads? shared-nothing architecture, that's very deliberate, it has draw backs as well as advantages, either way you have to understand the reasoning and how to leverage it. shared-nothing obviously doesn't lend itself to writing fast daemonized code, then again it wasn't meant to. I'd say that named function/method parameters would be a nice addition though - although having said that a decent IDE with code completion (DocBlocks) and well commented, well structured code mitigate the issue, for me anyway. > > -- 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 Monday 22 March 2010 10:51:14 pm Tommy Pham wrote: > Threading is one of the 2 two main reasons why I moved to Java & > asp.net (C#). I've built a PHP based web crawler about 10 years ago. > I ran into some problems: cookies, form handling and submission, > threading, and application variables. I later found some solutions > for cookies, form handling & submission. But no solution for > threading and application variables. Thus the move. Here's a simple > example of one of the many uses for threading. For an e-commerce > site, when the shopper requests for a category (ID), you can have a > thread to get all subcategories for that category, another thread to > get any assigned products, another thread to fetch all manufacturers > listed under that category, another thread to fetch any filters (price > ranges, features, specs, etc) set by the store owner that would fall > under that category, etc... versus what PHP currently doing now: > fetch subcategories, then fetch assigned products, then fetch > manufacturers, etc Performance would increase ten fold because of > parallel (threading) operations versus serial operations. Add that to > application variable (less memory usage and CPU cycles due to > creating/GC of variables that could be used for an entire application > regardless of requests & sessions), you have an excellent tool. > > Regards, > Tommy Threading is also much more difficult to program for safely, because thread order is non-deterministic. Do you really want to unleash hoards of marginally competent programmers on a threaded enviornment? :-) Also, the architecture you describe above is fine if you're scaling a single server really big. PHP is designed to scale the other direction: Just add more servers. There's no data shared from one request to another, so there's no need to share data between web heads. Throw a load balancer in front of it and spin up as many web servers as you need. The "shared nothing" design is very deliberate. It has design trade-offs like anything else. PHP is a web-centric language. It's not really intended for building tier-1 daemon processes, just like you'd be an idiot to try and code your entire web app in C from the start. --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?
There can be, and there are, differences between the languages. There are so many languages out there, and it works like a market place. If you like the language, use it. It it fails to do what you want, you switch to another one. There is no need to beg the php developers to implement anything, as long as you can switch to another language. Teus. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Will PHP ever "grow up" and have threading?
On Mon, Mar 22, 2010 at 7:40 PM, Adam Richardson wrote: > On Mon, Mar 22, 2010 at 10:23 PM, Daevid Vincent wrote: > >> > Is this a case of "it's too hard"? >> > >> > Subscribe to internals. Read the archives. The truth is out there. >> >> I have Googled a while on this and don't see much of anything about "PHP >> threading" of use. Just a bunch of people desperately wishing for this >> feature and trying to hack some way of doing it. Hence my asking here. >> >> "foo($set_this_parameter=$bar);" bull$hit??! (there is NO >> >>> reason NOT to let >> >>> >> the developer choose WHICH of the list of parameters they >> >>> want to set in a >> >> > There are reasons. You would know this if you had done the legwork >> > before opening your mouth and letting crap fall out. >> >> I have researched this. (http://bugs.php.net/bug.php?id=47331) The only >> reason I see given for this lack of feature is "it was decided that you can >> pass an array parameter instead". This isn't a solution, it's a hack. AND >> it only works if you are creating a new function or adding to a function. >> It does nothing for existing functions that have many parameters. Why >> wouldn't you want to make an already amazing language better and more >> flexible. I honestly see zero downside or complication to this. In fact I >> am working on a site coded in PHP by Python people, and often find exactly >> what I suggest in the code because Python can do this. Ironically it works >> by dumb luck b/c PHP ignores the assignment or something and so the >> parameters just happened to line up. Even C# can do this. >> >> > many parameters and you can't overload functions like you >> > >>> can in Java or >> > >> > PHP is NOT Java. >> > >> > other typed languages) >> > >> > Nor is it OTHER types languages. >> >> Uh. Pretty much EVERY other major language has threading. C++, C#, Java, >> Ruby, Python and even the archaic Perl. >> >> I KNOW PHP is not Java. That's why I use it. That doesn't take away from >> the fact it still needs to have threading to compete as a serious language >> if you ever want to do anything more than web pages. >> >> > > You could implement the features yourself. >> > >> > Damn, Mr McGlone beat me to it :) >> >> That's such a STUPID retort I'm so sick of hearing from the FOSS community. >> "build it yourself uh huhh uhhh huhhh". Obviously I'm not a low-level C/C++ >> coder -- that's WHY I use PHP. :-\ So, you just stay content with the >> status quo. I will continue to ask for features to enhance the language. >> They may fall on deaf ears, but sometimes... just sometimes... The squeaky >> wheel get's the grease. >> >> > When you set the subject line of your rant to something like >> > "Will PHP >> > ever 'grow up'", I expect your argument to at least be rationale, >> > logical, and quite possibly contain a patch. It's called >> > "open source" >> > because you too can make changes. >> >> It was logical and rational. I gave examples of why threads are needed in >> PHP and why it's STILL considered a sub-language by many enterprise level >> people, and also why it will NEVER be used for anything more than web pages >> until threading is implemented. >> >> By "grow up", I mean exactly that. PHP needs to be considered a contender >> and an equal to other enterprise level languages, not this little amateur >> language that script kiddies use. While we here may know the power and >> virtues of the language, I assure you that most of the world still views it >> as a toy language. And spare me your examples of Google or Twitter or some >> other large site that uses it. I'm saying, as a whole, it is still viewed >> that way by most enterprises. But more importantly, it is IMPOSSIBLE for >> PHP to be used in writing daemons or anything of any complexity save web >> pages. This is one reason why Python is used for most of your Linux >> scripts. Or why Java/C# are used for applications. And honestly, I'd say a >> big reason that Rails has taken off even. >> >> You're all getting hung up on my little paragraph rant about the parameter >> feature that is desperately missing from PHP too. I'm sorry I threw that >> into the mix, I didn't realize it would confuse you all so much from the >> main topic. >> >> Clearly you had nothing of value to add to the question(s) and only wished >> to chastise me for using harsh words which offended your delicate ears. I'm >> sorry, but when a project like PHP is made for the masses to use, and when >> many people are asking for useful, sane and reasonable features, and the >> internal devs simply dismiss them because they don't feel like implementing >> something (or maybe they don't have the skills to), I call bullshit. And >> then to hide under the safety net of "well then submit a patch" is just >> cowardice. I suspect that even *if* I submitted the perfect patch, that the >> internal devs would not put it in the main tree because THEY are >> fundamentally against the idea, so it
Re: [PHP] Will PHP ever "grow up" and have threading?
On Mon, Mar 22, 2010 at 10:23 PM, Daevid Vincent wrote: > > Is this a case of "it's too hard"? > > > > Subscribe to internals. Read the archives. The truth is out there. > > I have Googled a while on this and don't see much of anything about "PHP > threading" of use. Just a bunch of people desperately wishing for this > feature and trying to hack some way of doing it. Hence my asking here. > > "foo($set_this_parameter=$bar);" bull$hit??! (there is NO > >>> reason NOT to let > >>> > the developer choose WHICH of the list of parameters they > >>> want to set in a > > > There are reasons. You would know this if you had done the legwork > > before opening your mouth and letting crap fall out. > > I have researched this. (http://bugs.php.net/bug.php?id=47331) The only > reason I see given for this lack of feature is "it was decided that you can > pass an array parameter instead". This isn't a solution, it's a hack. AND > it only works if you are creating a new function or adding to a function. > It does nothing for existing functions that have many parameters. Why > wouldn't you want to make an already amazing language better and more > flexible. I honestly see zero downside or complication to this. In fact I > am working on a site coded in PHP by Python people, and often find exactly > what I suggest in the code because Python can do this. Ironically it works > by dumb luck b/c PHP ignores the assignment or something and so the > parameters just happened to line up. Even C# can do this. > > > many parameters and you can't overload functions like you > > >>> can in Java or > > > > PHP is NOT Java. > > > > other typed languages) > > > > Nor is it OTHER types languages. > > Uh. Pretty much EVERY other major language has threading. C++, C#, Java, > Ruby, Python and even the archaic Perl. > > I KNOW PHP is not Java. That's why I use it. That doesn't take away from > the fact it still needs to have threading to compete as a serious language > if you ever want to do anything more than web pages. > > > > You could implement the features yourself. > > > > Damn, Mr McGlone beat me to it :) > > That's such a STUPID retort I'm so sick of hearing from the FOSS community. > "build it yourself uh huhh uhhh huhhh". Obviously I'm not a low-level C/C++ > coder -- that's WHY I use PHP. :-\ So, you just stay content with the > status quo. I will continue to ask for features to enhance the language. > They may fall on deaf ears, but sometimes... just sometimes... The squeaky > wheel get's the grease. > > > When you set the subject line of your rant to something like > > "Will PHP > > ever 'grow up'", I expect your argument to at least be rationale, > > logical, and quite possibly contain a patch. It's called > > "open source" > > because you too can make changes. > > It was logical and rational. I gave examples of why threads are needed in > PHP and why it's STILL considered a sub-language by many enterprise level > people, and also why it will NEVER be used for anything more than web pages > until threading is implemented. > > By "grow up", I mean exactly that. PHP needs to be considered a contender > and an equal to other enterprise level languages, not this little amateur > language that script kiddies use. While we here may know the power and > virtues of the language, I assure you that most of the world still views it > as a toy language. And spare me your examples of Google or Twitter or some > other large site that uses it. I'm saying, as a whole, it is still viewed > that way by most enterprises. But more importantly, it is IMPOSSIBLE for > PHP to be used in writing daemons or anything of any complexity save web > pages. This is one reason why Python is used for most of your Linux > scripts. Or why Java/C# are used for applications. And honestly, I'd say a > big reason that Rails has taken off even. > > You're all getting hung up on my little paragraph rant about the parameter > feature that is desperately missing from PHP too. I'm sorry I threw that > into the mix, I didn't realize it would confuse you all so much from the > main topic. > > Clearly you had nothing of value to add to the question(s) and only wished > to chastise me for using harsh words which offended your delicate ears. I'm > sorry, but when a project like PHP is made for the masses to use, and when > many people are asking for useful, sane and reasonable features, and the > internal devs simply dismiss them because they don't feel like implementing > something (or maybe they don't have the skills to), I call bullshit. And > then to hide under the safety net of "well then submit a patch" is just > cowardice. I suspect that even *if* I submitted the perfect patch, that the > internal devs would not put it in the main tree because THEY are > fundamentally against the idea, so it's a Catch22. You need their blessing > either way. As John Acton said, "Power corrupts; absolute power corrupts > absolutely". > > > > -- > PHP General Ma
RE: [PHP] Will PHP ever "grow up" and have threading?
> Is this a case of "it's too hard"? > > Subscribe to internals. Read the archives. The truth is out there. I have Googled a while on this and don't see much of anything about "PHP threading" of use. Just a bunch of people desperately wishing for this feature and trying to hack some way of doing it. Hence my asking here. "foo($set_this_parameter=$bar);" bull$hit??! (there is NO >>> reason NOT to let >>> the developer choose WHICH of the list of parameters they >>> want to set in a > There are reasons. You would know this if you had done the legwork > before opening your mouth and letting crap fall out. I have researched this. (http://bugs.php.net/bug.php?id=47331) The only reason I see given for this lack of feature is "it was decided that you can pass an array parameter instead". This isn't a solution, it's a hack. AND it only works if you are creating a new function or adding to a function. It does nothing for existing functions that have many parameters. Why wouldn't you want to make an already amazing language better and more flexible. I honestly see zero downside or complication to this. In fact I am working on a site coded in PHP by Python people, and often find exactly what I suggest in the code because Python can do this. Ironically it works by dumb luck b/c PHP ignores the assignment or something and so the parameters just happened to line up. Even C# can do this. > many parameters and you can't overload functions like you > >>> can in Java or > > PHP is NOT Java. > > other typed languages) > > Nor is it OTHER types languages. Uh. Pretty much EVERY other major language has threading. C++, C#, Java, Ruby, Python and even the archaic Perl. I KNOW PHP is not Java. That's why I use it. That doesn't take away from the fact it still needs to have threading to compete as a serious language if you ever want to do anything more than web pages. > > You could implement the features yourself. > > Damn, Mr McGlone beat me to it :) That's such a STUPID retort I'm so sick of hearing from the FOSS community. "build it yourself uh huhh uhhh huhhh". Obviously I'm not a low-level C/C++ coder -- that's WHY I use PHP. :-\ So, you just stay content with the status quo. I will continue to ask for features to enhance the language. They may fall on deaf ears, but sometimes... just sometimes... The squeaky wheel get's the grease. > When you set the subject line of your rant to something like > "Will PHP > ever 'grow up'", I expect your argument to at least be rationale, > logical, and quite possibly contain a patch. It's called > "open source" > because you too can make changes. It was logical and rational. I gave examples of why threads are needed in PHP and why it's STILL considered a sub-language by many enterprise level people, and also why it will NEVER be used for anything more than web pages until threading is implemented. By "grow up", I mean exactly that. PHP needs to be considered a contender and an equal to other enterprise level languages, not this little amateur language that script kiddies use. While we here may know the power and virtues of the language, I assure you that most of the world still views it as a toy language. And spare me your examples of Google or Twitter or some other large site that uses it. I'm saying, as a whole, it is still viewed that way by most enterprises. But more importantly, it is IMPOSSIBLE for PHP to be used in writing daemons or anything of any complexity save web pages. This is one reason why Python is used for most of your Linux scripts. Or why Java/C# are used for applications. And honestly, I'd say a big reason that Rails has taken off even. You're all getting hung up on my little paragraph rant about the parameter feature that is desperately missing from PHP too. I'm sorry I threw that into the mix, I didn't realize it would confuse you all so much from the main topic. Clearly you had nothing of value to add to the question(s) and only wished to chastise me for using harsh words which offended your delicate ears. I'm sorry, but when a project like PHP is made for the masses to use, and when many people are asking for useful, sane and reasonable features, and the internal devs simply dismiss them because they don't feel like implementing something (or maybe they don't have the skills to), I call bullshit. And then to hide under the safety net of "well then submit a patch" is just cowardice. I suspect that even *if* I submitted the perfect patch, that the internal devs would not put it in the main tree because THEY are fundamentally against the idea, so it's a Catch22. You need their blessing either way. As John Acton said, "Power corrupts; absolute power corrupts absolutely". -- 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?
It's code design problem you face, there is loots of solutions to "use treading" in php. (analyse the way ms C# and VB creates and handles threads, and when you have done that you can create a couple of php scripts to acquire the same result). Read GOF (gang of fore) Design Patterns: Elements of Reusable Object-Oriented Software (ISBN 0-201-63361-2) and PHP 5 Power Programming (ISBN 0-131-47149-X) Start reading and stop being an AHole. 2010/3/23 Daevid Vincent : > I've been using PHP for a decade or so (since PHP/FI) and love it. The one > problem that seems to always keep coming back on enterprise level projects > is the lack of threading. This always means we have to write some back-end > code in Ruby or Java or C/C++ and some hacky database layer or DBUS or > something to communicate with PHP. > > Will PHP ever have proper threading? It would sure let the language take > the next logical leap to writing applications and daemons. I love the idea > that Rails/Ruby have where you can just load objects in memory once and > keep using them from page to page (this is NOT the same as a $_SESSION, > it's way more flexible and powerful). > > But more importantly, in one application I'm working on, we need to connect > to an Asterisk system for the IVR abilities. This means we have Ruby doing > all that fun stuff and PHP doing the web stuff, but we're also duplicating > a LOT of work. Both Ruby AND PHP now have to have ORMs for the user who's > calling in, advertisements served, products shown, etc. We could have used > Rails for the web portion, but I want to stay with PHP and I'm sure I don't > have to explain to you PHPers why that is. Without threads, PHP just isn't > even an option or only one user would be able to call in at a time. > > The pcntl stuff is not feasible. It's a hack at best. Spawning multiple > scripts is also a recipie for disaster. > > When will the PHP core-devs (Zend?) realize that PHP is much more than a > hook to a database. It's much more than web pages. > > Is this a case of "it's too hard"? Or is it a case of PHP core developers > just being douche-bags like they are about the whole > "foo($set_this_parameter=$bar);" bull$hit??! (there is NO reason NOT to let > the developer choose WHICH of the list of parameters they want to set in a > function/method call aside from being stubborn! Especially when there are > many parameters and you can't overload functions like you can in Java or > other typed languages) > > As usual, I created a poll here too: > http://www.rapidpoll.net/awp1ocy > > Past polls are below: > http://www.rapidpoll.net/8opnt1e > http://www.rapidpoll.net/arc1opy (although someone hacked this poll and > loaded up the 76 votes like a little cheater) > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- 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?
David McGlone wrote: On Monday 22 March 2010 20:59:21 Daevid Vincent wrote: That's okay Larry, YOU don't have to answer. Sorry my post offended you Larry (and anyone else equally offended). ...and yes. I AM angry that they refuse to add functionality to the PHP language that MANY people have been requesting, just because they are stubborn. I'll spare you the links to the threads (no pun intended) as you can easily find them. Have a lovely day! Your best friend always, Daevid. -Original Message- From: Larry Garfield [mailto:la...@garfieldtech.com] Sent: Monday, March 22, 2010 5:39 PM To: php-general@lists.php.net Subject: Re: [PHP] Will PHP ever "grow up" and have threading? Perhaps if you asked a question you'd get an answer rather than coming off as an angry immature crybaby in your last paragraph... No, I'm not going to dignify your post with a real answer. Come back when you can ask a real question and maybe you'll get a real answer. --Larry Garfield Is this a case of "it's too hard"? Or is it a case of PHP core developers Subscribe to internals. Read the archives. The truth is out there. just being douche-bags like they are about the whole That's just rude. "foo($set_this_parameter=$bar);" bull$hit??! (there is NO reason NOT to let the developer choose WHICH of the list of parameters they want to set in a There are reasons. You would know this if you had done the legwork before opening your mouth and letting crap fall out. function/method call aside from being stubborn! Especially when there are many parameters and you can't overload functions like you can in Java or PHP is NOT Java. other typed languages) Nor is it OTHER types languages. You could implement the features yourself. Damn, Mr McGlone beat me to it :) When you set the subject line of your rant to something like "Will PHP ever 'grow up'", I expect your argument to at least be rationale, logical, and quite possibly contain a patch. It's called "open source" because you too can make changes. 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 Monday 22 March 2010 20:59:21 Daevid Vincent wrote: > That's okay Larry, YOU don't have to answer. > > Sorry my post offended you Larry (and anyone else equally offended). > > ...and yes. I AM angry that they refuse to add functionality to the PHP > language that MANY people have been requesting, just because they are > stubborn. I'll spare you the links to the threads (no pun intended) as you > can easily find them. > > Have a lovely day! > > Your best friend always, > > Daevid. > > > -Original Message- > > From: Larry Garfield [mailto:la...@garfieldtech.com] > > Sent: Monday, March 22, 2010 5:39 PM > > To: php-general@lists.php.net > > Subject: Re: [PHP] Will PHP ever "grow up" and have threading? > > > > Perhaps if you asked a question you'd get an answer rather > > than coming off as > > an angry immature crybaby in your last paragraph... No, I'm > > not going to > > dignify your post with a real answer. Come back when you can > > ask a real > > question and maybe you'll get a real answer. > > > > --Larry Garfield > > > > > Is this a case of "it's too hard"? Or is it a case of PHP > > > > core developers > > > > > just being douche-bags like they are about the whole > > > "foo($set_this_parameter=$bar);" bull$hit??! (there is NO > > > > reason NOT to let > > > > > the developer choose WHICH of the list of parameters they > > > > want to set in a > > > > > function/method call aside from being stubborn! Especially > > > > when there are > > > > > many parameters and you can't overload functions like you > > > > can in Java or > > > > > other typed languages) > You could implement the features yourself. -- Blessings David M. I have been driven to my knees many times by the overwhelming conviction that I had nowhere else to go. -- 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?
That's okay Larry, YOU don't have to answer. Sorry my post offended you Larry (and anyone else equally offended). ...and yes. I AM angry that they refuse to add functionality to the PHP language that MANY people have been requesting, just because they are stubborn. I'll spare you the links to the threads (no pun intended) as you can easily find them. Have a lovely day! Your best friend always, Daevid. > -Original Message- > From: Larry Garfield [mailto:la...@garfieldtech.com] > Sent: Monday, March 22, 2010 5:39 PM > To: php-general@lists.php.net > Subject: Re: [PHP] Will PHP ever "grow up" and have threading? > > Perhaps if you asked a question you'd get an answer rather > than coming off as > an angry immature crybaby in your last paragraph... No, I'm > not going to > dignify your post with a real answer. Come back when you can > ask a real > question and maybe you'll get a real answer. > > --Larry Garfield > > > Is this a case of "it's too hard"? Or is it a case of PHP > core developers > > just being douche-bags like they are about the whole > > "foo($set_this_parameter=$bar);" bull$hit??! (there is NO > reason NOT to let > > the developer choose WHICH of the list of parameters they > want to set in a > > function/method call aside from being stubborn! Especially > when there are > > many parameters and you can't overload functions like you > can in Java or > > other typed languages) -- 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?
Perhaps if you asked a question you'd get an answer rather than coming off as an angry immature crybaby in your last paragraph... No, I'm not going to dignify your post with a real answer. Come back when you can ask a real question and maybe you'll get a real answer. --Larry Garfield On Monday 22 March 2010 07:02:30 pm Daevid Vincent wrote: > I've been using PHP for a decade or so (since PHP/FI) and love it. The one > problem that seems to always keep coming back on enterprise level projects > is the lack of threading. This always means we have to write some back-end > code in Ruby or Java or C/C++ and some hacky database layer or DBUS or > something to communicate with PHP. > > Will PHP ever have proper threading? It would sure let the language take > the next logical leap to writing applications and daemons. I love the idea > that Rails/Ruby have where you can just load objects in memory once and > keep using them from page to page (this is NOT the same as a $_SESSION, > it's way more flexible and powerful). > > But more importantly, in one application I'm working on, we need to connect > to an Asterisk system for the IVR abilities. This means we have Ruby doing > all that fun stuff and PHP doing the web stuff, but we're also duplicating > a LOT of work. Both Ruby AND PHP now have to have ORMs for the user who's > calling in, advertisements served, products shown, etc. We could have used > Rails for the web portion, but I want to stay with PHP and I'm sure I don't > have to explain to you PHPers why that is. Without threads, PHP just isn't > even an option or only one user would be able to call in at a time. > > The pcntl stuff is not feasible. It's a hack at best. Spawning multiple > scripts is also a recipie for disaster. > > When will the PHP core-devs (Zend?) realize that PHP is much more than a > hook to a database. It's much more than web pages. > > Is this a case of "it's too hard"? Or is it a case of PHP core developers > just being douche-bags like they are about the whole > "foo($set_this_parameter=$bar);" bull$hit??! (there is NO reason NOT to let > the developer choose WHICH of the list of parameters they want to set in a > function/method call aside from being stubborn! Especially when there are > many parameters and you can't overload functions like you can in Java or > other typed languages) > > As usual, I created a poll here too: > http://www.rapidpoll.net/awp1ocy > > Past polls are below: > http://www.rapidpoll.net/8opnt1e > http://www.rapidpoll.net/arc1opy (although someone hacked this poll and > loaded up the 76 votes like a little cheater) > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
