[PHP-DEV] Removing zend_hash_func in PHP 6.0
Hi List, I recently discovered that zend_hash_func is equal to zend_get_hash_value. To clean this up, I would like to remove zend_hash_func in favor of zend_get_hash in HEAD. If there are no objections I would commit a patch in a few days. David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Removing zend_hash_func in PHP 6.0
2009/5/26 David Soria Parra dso...@gmx.net: Hi List, I recently discovered that zend_hash_func is equal to zend_get_hash_value. To clean this up, I would like to remove zend_hash_func in favor of zend_get_hash in HEAD. If there are no objections I would commit a patch in a few days. Did you grep through pecl and the source to make sure it won't break anything? If you did, then I see no problems. -- Slan, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Removing zend_hash_func in PHP 6.0
On 26.05.2009 16:13, David Soria Parra wrote: Hi List, I recently discovered that zend_hash_func is equal to zend_get_hash_value. To clean this up, I would like to remove zend_hash_func in favor of zend_get_hash in HEAD. If there are no objections I would commit a patch in a few days. 12:48 @tony2001 dsp__: I see no point in removing it completely and breaking BC for no reason 12:48 @tony2001 you can remove it, but leave a macro to make sure old code still works -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PHP] Question about Olivier's method
Hello, I'm looking for information about Olivier's method in order to supplement a talk. I spent a lot of time on engine searchers and I didn't find something documented enough to make me understand the way of working of such a method. Then I decided to contact you directly. Because I use the php similar_text function using this method to study how regular sentences change when they spread in a sample of people. I thought you could help me. Do you know a webpage or something else where I could find information about Olivier's method ? Thank you very much, Best regards, AZMODAI Paul,
Re: [PHP-DEV] [PHP] Question about Olivier's method
On Tue, May 26, 2009 at 16:17, paul (aka: azmodai) azmodai.p...@gmail.com wrote: Hello, I'm looking for information about Olivier's method in order to supplement a talk. I spent a lot of time on engine searchers and I didn't find something documented enough to make me understand the way of working of such a method. Then I decided to contact you directly. Because I use the php similar_text function using this method to study how regular sentences change when they spread in a sample of people. I thought you could help me. Do you know a webpage or something else where I could find information about Olivier's method ? To decrypt this question, he is talking about the comment in the manual on www.php.net/similar_text calculates the similarity between two strings as described in Oliver [1993]. Note that this implementation does not use a stack as in Oliver's pseudo code, but recursive calls which may or may not speed up the whole process. Note also that the complexity of this algorithm is O(N**3) where N is the length of the longest string. That comment has been there since 9 years and 11 months ago, committed by sas (which was the initial commit). So, who is this Oliver - and where is that description/pseudo code? :) -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP] Question about Olivier's method
On Tue, May 26, 2009 at 7:06 PM, Hannes Magnusson hannes.magnus...@gmail.com wrote: On Tue, May 26, 2009 at 16:17, paul (aka: azmodai) So, who is this Oliver - and where is that description/pseudo code? :) A note on that page (from brad dot fish at gmail dot com on 24-Feb-2006 10:30) says: The link below to the Oliver document appears to be broken. Here is one that works: http://citeseer.ist.psu.edu/oliver93decision.html; Paul -- Paul Biggar paul.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP] Question about Olivier's method
On Tue, May 26, 2009 at 20:21, Paul Biggar paul.big...@gmail.com wrote: On Tue, May 26, 2009 at 7:06 PM, Hannes Magnusson hannes.magnus...@gmail.com wrote: On Tue, May 26, 2009 at 16:17, paul (aka: azmodai) So, who is this Oliver - and where is that description/pseudo code? :) A note on that page (from brad dot fish at gmail dot com on 24-Feb-2006 10:30) says: The link below to the Oliver document appears to be broken. Here is one that works: http://citeseer.ist.psu.edu/oliver93decision.html; Heh. I had assumed he read the notes :) That link is broken to, but archive.org has it from 1997; http://web.archive.org/web/*/http://www.cs.monash.edu.au/~jono/TechReports/TR173.dgraph.ps -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP] Question about Olivier's method
On Tue, May 26, 2009 at 7:31 PM, Hannes Magnusson hannes.magnus...@gmail.com wrote: On Tue, May 26, 2009 at 20:21, Paul Biggar paul.big...@gmail.com wrote: The link below to the Oliver document appears to be broken. Here is one that works: http://citeseer.ist.psu.edu/oliver93decision.html; That link is broken to, but archive.org has it from 1997; http://web.archive.org/web/*/http://www.cs.monash.edu.au/~jono/TechReports/TR173.dgraph.ps Citeseer keeps a cache (in the top right-hand-side of the page). Citeseer has been very reliable for the last year or so, but there were problems with links changing, and an unreliable connection before that. Maybe archive.org is better as a result. Paul -- Paul Biggar paul.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP] Question about Olivier's method
On Tue, May 26, 2009 at 7:31 PM, Hannes Magnusson hannes.magnus...@gmail.com wrote: On Tue, May 26, 2009 at 20:21, Paul Biggar paul.big...@gmail.com wrote: The link below to the Oliver document appears to be broken. Here is one that works: http://citeseer.ist.psu.edu/oliver93decision.html; That link is broken to, but archive.org has it from 1997; http://web.archive.org/web/*/http://www.cs.monash.edu.au/~jono/TechReports/TR173.dgraph.ps Citeseer keeps a cache (in the top right-hand-side of the page). Citeseer has been very reliable for the last year or so, but there were problems with links changing, and an unreliable connection before that. Maybe archive.org is better as a result. Paul -- Paul Biggar paul.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Removing zend_hash_func in PHP 6.0
Antony Dovgal wrote: On 26.05.2009 16:13, David Soria Parra wrote: Hi List, I recently discovered that zend_hash_func is equal to zend_get_hash_value. To clean this up, I would like to remove zend_hash_func in favor of zend_get_hash in HEAD. If there are no objections I would commit a patch in a few days. 12:48@tony2001 dsp__: I see no point in removing it completely and breaking BC for no reason 12:48@tony2001 you can remove it, but leave a macro to make sure old code still works I would like to see us clean up items like this as part of the PHP-6 release, part of the list of todo items was to get rid of any bits like this that can be unnecessarily confusing etc. I do think it should be done in a way that deprecates one of the functions, but not the other to make migration easier for extensions (unless we have a compelling reason for a complete rename). -shire -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP scalability problem
PHP is a server side scripting language, so that means that the server will have to do the bulk of the processing if not most. I was thinking about shifting the processing to the client. Kinda like how java does it. I don't know really know how java does it but it would be interesting if it could be done for PHP also. Thank you, Leonard D'Oliveira
Re: [PHP-DEV] PHP scalability problem
1) PHP is Rarely The Bottleneck: http://talks.php.net/show/drupal08/http://talks.php.net/show/drupal08/7 2) Invest in an opcode cache 3) DB I/O is always the most restrictive part of your application, read the mysql performance blog (a lot applies for postgres too) 4) If you're serious about scalability, ditch apache and use a better webserver 5) You're describing what ajax does in a lot of cases 6) Have you deployed flatfile cache / apc / memcached? If so, how? 7) Do you regularly run siege tests on new server stacks and profile each piece's impact on performance? 8) Do you profile your code every time you change some piece of logic? Scalability is an enormous mountain to climb and there's only so much you can offload on to the client. Chances are there's more room for improvement at any stage in your development than there is potentiality for client-side processing. On Tue, May 26, 2009 at 10:46 PM, tRace DOliveira married...@yahoo.comwrote: PHP is a server side scripting language, so that means that the server will have to do the bulk of the processing if not most. I was thinking about shifting the processing to the client. Kinda like how java does it. I don't know really know how java does it but it would be interesting if it could be done for PHP also. Thank you, Leonard D'Oliveira
[PHP-DEV] PHP scalability problem
What I am trying to achieve is to have the server do less processing. Like I said PHP is a server side scripting language and each time a request is made a process is spawned and processes are heavy weight as compared to a thread which is a light weight process. So I want to take away much processing away from the server and have the client do it instead. Because if many requests are made the server will eventually go down because it will over the server.I am not trying to get away from PHP but I am trying to solve the problem of scalability Thank you, Leonard D'Oliveira
Re: [PHP-DEV] PHP scalability problem
On 26-May-09, at 11:10 PM, tRace DOliveira wrote: What I am trying to achieve is to have the server do less processing. Like I said PHP is a server side scripting language and each time a request is made a process is spawned and processes are heavy weight as compared to a thread which is a light weight process. So I want to take away much processing away from the server and have the client do it instead. Because if many requests are made the server will eventually go down because it will over the server.I am not trying to get away from PHP but I am trying to solve the problem of scalability Unfortunately, the only thing you have achieved is writing on the wrong mailing list :-) Try php-general, where this kind of query is addressed by a larger group of people. Cheers! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP scalability problem
Succinct and great reply. Better webserver: nginx :) #3 is probably the most important piece. I'd like to also note scaling php is pretty simple. Scaling out typically provides better results as opposed to scaling up. Scaling your datastore will always be your pain point. Adding new data nodes is complex. Adding more php processing nodes is simple. Php nodes are just worker bees. They're great for shared-nothing processing engines. I can't think of a good metaphor right now other than that. On May 26, 2009, at 7:55 PM, Eddie Drapkin oorza...@gmail.com wrote: 1) PHP is Rarely The Bottleneck: http://talks.php.net/show/drupal08/http://talks.php.net/show/drupal08/7 2) Invest in an opcode cache 3) DB I/O is always the most restrictive part of your application, read the mysql performance blog (a lot applies for postgres too) 4) If you're serious about scalability, ditch apache and use a better webserver 5) You're describing what ajax does in a lot of cases 6) Have you deployed flatfile cache / apc / memcached? If so, how? 7) Do you regularly run siege tests on new server stacks and profile each piece's impact on performance? 8) Do you profile your code every time you change some piece of logic? Scalability is an enormous mountain to climb and there's only so much you can offload on to the client. Chances are there's more room for improvement at any stage in your development than there is potentiality for client-side processing. On Tue, May 26, 2009 at 10:46 PM, tRace DOliveira married...@yahoo.com wrote: PHP is a server side scripting language, so that means that the server will have to do the bulk of the processing if not most. I was thinking about shifting the processing to the client. Kinda like how java does it. I don't know really know how java does it but it would be interesting if it could be done for PHP also. Thank you, Leonard D'Oliveira -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP scalability problem
nginx and php-fpm is the fastest setup I could find, after spending almost 2 weeks trying different combinations. Apache pre-fork model: 1900 reqs/second (this is with running queries per pageload) nginx w/ fpm: 3400 reqs/second And nginx's doc setup is awesome. Like Michael said, scaling PHP itself is no big deal, just add more worker nodes to your process pool, the issue is scaling out your sql server (memcache scaling is piss easy too) On Tue, May 26, 2009 at 11:24 PM, Michael Shadle mike...@gmail.com wrote: Succinct and great reply. Better webserver: nginx :) #3 is probably the most important piece. I'd like to also note scaling php is pretty simple. Scaling out typically provides better results as opposed to scaling up. Scaling your datastore will always be your pain point. Adding new data nodes is complex. Adding more php processing nodes is simple. Php nodes are just worker bees. They're great for shared-nothing processing engines. I can't think of a good metaphor right now other than that. On May 26, 2009, at 7:55 PM, Eddie Drapkin oorza...@gmail.com wrote: 1) PHP is Rarely The Bottleneck: http://talks.php.net/show/drupal08/http://talks.php.net/show/drupal08/7 2) Invest in an opcode cache 3) DB I/O is always the most restrictive part of your application, read the mysql performance blog (a lot applies for postgres too) 4) If you're serious about scalability, ditch apache and use a better webserver 5) You're describing what ajax does in a lot of cases 6) Have you deployed flatfile cache / apc / memcached? If so, how? 7) Do you regularly run siege tests on new server stacks and profile each piece's impact on performance? 8) Do you profile your code every time you change some piece of logic? Scalability is an enormous mountain to climb and there's only so much you can offload on to the client. Chances are there's more room for improvement at any stage in your development than there is potentiality for client-side processing. On Tue, May 26, 2009 at 10:46 PM, tRace DOliveira married...@yahoo.com wrote: PHP is a server side scripting language, so that means that the server will have to do the bulk of the processing if not most. I was thinking about shifting the processing to the client. Kinda like how java does it. I don't know really know how java does it but it would be interesting if it could be done for PHP also. Thank you, Leonard D'Oliveira
