Re: [PHP] Re: Multithreading for OOP PHP
> As far as php side goes, it's a
> problem of design of the apps. Just because people decided to go through
> hoops to use the threaded model doesn't mean that it is any faster than
> writing to the same thing in event driven model, event driven way is
> sometimes much faster than threads.
I'm on both sides of the fence on this one. Imagine the database
operation (not necessarily a SELECT statement) that could take an
arbitrarily long time to complete. PHP should be able to hand that off
to another thread and be done with it:
$dbOpertation = dbThread($sql)
$dbOpertation->start();
Currently, we've got to to write an alternative file dbOperation.php
and call it via exec(), complete with shell-escaping arguments and all
the dangers that go with that:
exec('dbOperation.php'.escapeshellarg($sql));
Now who knows what escapeshellarg() will do to my precious
hand-crafted SQL so I'll have to debug and test that as well. Wait
until you see what that does to your single quotes, and you are in a
world of hurt if your SQL contains literals that also happen to
contain escaped quotes. I don't even know what other characters
escapeshellarg() will mungle, it is not mentioned in the fine manual
so I can either go read the source or start experimenting. And I
happen to be a hobbiest sysadmin, what happens to the poor PHP dev who
doesn't even quite understand the shell or think to escape the
arguments. The prevalence of PDO for simple queries even further
removes many (novice) PHP devs from thoughts of escaping
> Don't blame the language, blame the
> poor dev who made it harder on themselves... There are plenty of big and
> well performing systems online that pull data from many a locations on the
> back end and still manage to serve it to you in less than 2 hundredth of a
> second without the need for threading server side code. That's because they
> are designed well and implemented well as a system.
That is either naive or trolling. You either know very well that some
database operation cannot be completed in n/100 of a second, and we
haven't even started to talk about curl or other potentially
long-running operations.
> Finally another thing to consider is how the operating systems deal with
> high amounts of threads, how different architectures deal with them, while
> Linux is pretty good about threads, other systems have significant
> problems. Php is meant to run on all of them so you choose the model that
> works for all.
I see. Due to a Windows deficiency my PHP-on-*Nix code should suffer.
Are you not aware that some PHP features are available on some OS but
not others? Or that function differently by OS? Seriously, it looks
like you are trolling.
> Lastly I am sorry, but massively parallel architecture for general
> computing is still about 10 years out. That's where parallel processing
> design will be bore efficient and beneficial. When we have that, and
> programmers learn massively parallel design, maybe then we will have a need
> for parallel php (pphp?) for now, there is no need, only poor design.
What? i don't know what you mean by "massively parallel architecture"
but it certainly has no relevancy to the PHP dev who wants to run a
long SQL query.
--
Dotan Cohen
http://gibberish.co.il
http://what-is-what.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Multithreading for OOP PHP
Threading doesn't increase complexity? Spoken truly like somebody who has not had to actually write, test and debug proper, high performance threaded code. Please tell me how threading doesn't increase complexity of any data structure? I may agree if you talk about php running in cli, but then the very choice of using php is arguable, you want to thread your console apps, write them in a language that is threaded. That once again brings up the point that that is not the market that is meant to be addressed. As far as your phone goes, again why would you want to run even more threads, if you have 24 threads on your system, you will configure Apache to run 24 threads, each of you which will serve a request in parallel which will make your server capable of handling significant load. As far as php side goes, it's a problem of design of the apps. Just because people decided to go through hoops to use the threaded model doesn't mean that it is any faster than writing to the same thing in event driven model, event driven way is sometimes much faster than threads. Don't blame the language, blame the poor dev who made it harder on themselves... There are plenty of big and well performing systems online that pull data from many a locations on the back end and still manage to serve it to you in less than 2 hundredth of a second without the need for threading server side code. That's because they are designed well and implemented well as a system. Finally another thing to consider is how the operating systems deal with high amounts of threads, how different architectures deal with them, while Linux is pretty good about threads, other systems have significant problems. Php is meant to run on all of them so you choose the model that works for all. Lastly I am sorry, but massively parallel architecture for general computing is still about 10 years out. That's where parallel processing design will be bore efficient and beneficial. When we have that, and programmers learn massively parallel design, maybe then we will have a need for parallel php (pphp?) for now, there is no need, only poor design.
Re: [PHP] Re: Multithreading for OOP PHP
On 31/10/2012 13:46, Alex Nikitin wrote: Hey guys (and/or gals), I have heard this question entirely too many times, I think at some point Rasmus just stopped responding to it. The real reason that PHP is not threaded has nothing to do with PHP internal or extension thread safety, the reason is more to the extent that it doesn't make sense to add threading to PHP, it will only increase code and model complexity and create more points of failure, but again the reason is not this, the reason is that it doesn't make sense in PHP's native environment to add threading in the first place. Natively PHP is summoned by a web server, yes you can call PHP in CLI, but that's not it's point market, PHP is first and foremost a server-side language for the web and it is ran by a web server such as Apache or Nginx or IIS(i wouldn't know why you would use IIS, but it could be). All of these web servers (maybe with exception of IIS, i wouldn't know) work pretty much on the same principal, you have the main process that spawns a bunch of worker threads (this is adjustable in configuration, but is typically 1 per cpu thread). These threads are what actually process the requests and call PHP, meaning that if multiple threads are processing multiple requests, multiple instances of PHP will be called. This is why adding threading to PHP makes absolutely no sense, why would you spawn threads in something that is already being called by a thread? Don't get me wrong, threads spawning other threads is a solution, but it is a solution on massively parallel architectures, such as the GPGPUs that can handle over a thousand threads, and it is a solution for an entirely different problem, namely costly conditional statements; PHP on the other hand runs on a general purpose processor that already cache thrashes and runs into issues with instruction pipelines in parallel execution, adding more threads to it would do nothing for performance (or make it worse), make for more complex code and introduce new issues, like for example how do you test threaded code, debugging, messaging, etc, which will introduce new places where php apps fail, new security concerns, etc, and I think we are far from having current issues fixed... Want to parallelize your PHP execution? Learn to love curl_multi :) In this case, fix the program, not the programming language. Just my $0.02 -- Alex -- The trouble with programmers is that you can never tell what a programmer is doing until it’s too late. ~Seymour Cray You're very wrong. Adding threading doesn't increase complexity at all, the fact is, that people are coming up with horrible ways to execute what they should be executing in threads. It's 2012, my mobile phone has a dual core processor !! All that adding threading does is allow those people bending over backwards - using horrible hacks just to do two things at once - to do things properly. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Multithreading for OOP PHP
You do all that in the context of a single PHP instance and linear code, calling curl_multi handles its own threading, you just get back results, you dont have to store it anywhere outside PHP memory space, and you can configure timeouts and all that stuff, or you can regulate it yourself. The database connector is already doing what it is doing and doing it darn well, and you are still in the same execution context just a few lines down; call out to db, call out to multi for soap requests, handle the results, no syncing issues, no ITC issues, fast, linearly salable. Thread communication, sync, messaging, thread-safe storage, that you would be introduced with threads, and is one that is not there now. "Since nothing is shared, you'll need some place store that information (ie memached or DB). No idea what you are asking about... -- The trouble with programmers is that you can never tell what a programmer is doing until it’s too late. ~Seymour Cray
Re: [PHP] Re: Multithreading for OOP PHP
On Wed, Oct 31, 2012 at 9:27 AM, Alex Nikitin wrote: >> >> That's all understood but there are times when that one request from >> the visitor requires many sub-requests like connection to DB and >> making SOAP calls. > > > I would say it's more than just "there are times", that's how a typical > script lives, it imports libraries, queries the database, and talks to other > systems. > >> >> Sure, it can much faster do you think the response >> time for the visitor when the sub requests are done in child threads? > > > I am not so sure of that. Let's make it a mental exercise really quickly. So > let's say we have a website, lets say that we want to query the database and > make 2 soap calls at the same time, so for every request we spawn 3 threads > to do this. Now, ofcourse for every single request, if they were not > concurrent, we would run faster, but what happens when we add a little load > to this, say 300 requests per second (and i have built wordpress instances > that do 360 on a small ec2 instance). You have say 4 cores @ 1 thread/core, > so your web server has 4 threads that are continuously running + 1 for > dispatch, and then you have 900 threads that you now have to spawn, process, > transfer execution to other threads (context switch in and out, maybe a few > time) and terminate per second. The problem is that modern CPUs are not very > good at doing this, you are context switching between threads, you are > context switching between cores, because your network stack runs on a > different core or for any other reason, etc, which is very expensive > computationally, on top of which you have to spawn new threads and then kill > them. And on a say 4 requests per second system, you may win a few > miliseconds on parallelizing your data aggregation, but any real load will > see that benefit turn in a negative direction. > > Curl multi is not necessarily a hack, in context of soap, i can build my > soap queries, which is always a serial process anyways, and then use curl > multi to run the soap requests in parallel, so there, one part already > solved. > How is it solved when you can't monitor and actively maintain each individual requests within curl_multi? Since nothing is shared, you'll need some place store that information (ie memached or DB). With memached, you're already using extra memory and CPU cycles for that. How is that different than what you describe with extra CPU cycles and RAM? Other than using memcached for something that's not intended by design? If you're using DB, that's even worse because now you're relying on extra network traffic and disk IO (read slower performance). What about synchronizing the information between each calls in the sub-threads? If you got it solved with curl_multi, I'd love to see that pseudo code. I'm sure there are many here that would like to see that too. Anyway, this topic of threading in PHP has already been discussed heatedly. I'm sure it's already been submitted as feature request. As with all feature request, it's up to the dev. :) Cheers, Tommy > Database is even easier, since you are usually using a persistent > connection, you are already relying on the mysql driver to thread your calls > while maintaining a single instance of your connection (eliminating the need > for three way hand shakes every time you want to talk to your database, > which saves you at least 3 round trips, plus auth (which is 3 more round > trips and crypto on both sides)), so even there this problem is already > solved for you. And if you are saying that you can run multiple parallel > queries for the same PHP process, you really need to fix your database and > queries first :) > >> Then shouldn't that be fixed in PHP at the core rather than a hack after? > > > Nope, no need to needlessly complicate PHP especially if there is no need or > performance gain in doing it. There are plenty of other areas where PHP can > be fixed where it does matter, i mean have a look at a month of PHP bugs if > you want to get depressed :) > > -- > The trouble with programmers is that you can never tell what a programmer is > doing until it’s too late. ~Seymour Cray -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Multithreading for OOP PHP
> > > That's all understood but there are times when that one request from > the visitor requires many sub-requests like connection to DB and > making SOAP calls. I would say it's more than just "there are times", that's how a typical script lives, it imports libraries, queries the database, and talks to other systems. > Sure, it can much faster do you think the response > time for the visitor when the sub requests are done in child threads? > I am not so sure of that. Let's make it a mental exercise really quickly. So let's say we have a website, lets say that we want to query the database and make 2 soap calls at the same time, so for every request we spawn 3 threads to do this. Now, ofcourse for every single request, if they were not concurrent, we would run faster, but what happens when we add a little load to this, say 300 requests per second (and i have built wordpress instances that do 360 on a small ec2 instance). You have say 4 cores @ 1 thread/core, so your web server has 4 threads that are continuously running + 1 for dispatch, and then you have 900 threads that you now have to spawn, process, transfer execution to other threads (context switch in and out, maybe a few time) and terminate per second. The problem is that modern CPUs are not very good at doing this, you are context switching between threads, you are context switching between cores, because your network stack runs on a different core or for any other reason, etc, which is very expensive computationally, on top of which you have to spawn new threads and then kill them. And on a say 4 requests per second system, you may win a few miliseconds on parallelizing your data aggregation, but any real load will see that benefit turn in a negative direction. Curl multi is not necessarily a hack, in context of soap, i can build my soap queries, which is always a serial process anyways, and then use curl multi to run the soap requests in parallel, so there, one part already solved. Database is even easier, since you are usually using a persistent connection, you are already relying on the mysql driver to thread your calls while maintaining a single instance of your connection (eliminating the need for three way hand shakes every time you want to talk to your database, which saves you at least 3 round trips, plus auth (which is 3 more round trips and crypto on both sides)), so even there this problem is already solved for you. And if you are saying that you can run multiple parallel queries for the same PHP process, you really need to fix your database and queries first :) Then shouldn't that be fixed in PHP at the core rather than a hack after? Nope, no need to needlessly complicate PHP especially if there is no need or performance gain in doing it. There are plenty of other areas where PHP can be fixed where it does matter, i mean have a look at a month of PHP bugs if you want to get depressed :) -- The trouble with programmers is that you can never tell what a programmer is doing until it’s too late. ~Seymour Cray
Re: [PHP] Re: Multithreading for OOP PHP
On Wed, Oct 31, 2012 at 6:46 AM, Alex Nikitin wrote: > Hey guys (and/or gals), > > I have heard this question entirely too many times, I think at some point > Rasmus just stopped responding to it. The real reason that PHP is not > threaded has nothing to do with PHP internal or extension thread safety, > the reason is more to the extent that it doesn't make sense to add > threading to PHP, it will only increase code and model complexity and > create more points of failure, but again the reason is not this, the reason > is that it doesn't make sense in PHP's native environment to add threading > in the first place. Natively PHP is summoned by a web server, yes you can > call PHP in CLI, but that's not it's point market, PHP is first and > foremost a server-side language for the web and it is ran by a web server > such as Apache or Nginx or IIS(i wouldn't know why you would use IIS, but > it could be). All of these web servers (maybe with exception of IIS, i > wouldn't know) work pretty much on the same principal, you have the main > process that spawns a bunch of worker threads (this is adjustable in > configuration, but is typically 1 per cpu thread). These threads are what > actually process the requests and call PHP, meaning that if multiple > threads are processing multiple requests, multiple instances of PHP will be > called. This is why adding threading to PHP makes absolutely no sense, why > would you spawn threads in something that is already being called by a > thread? Don't get me wrong, threads spawning other threads is a solution, > but it is a solution on massively parallel architectures, such as the > GPGPUs that can handle over a thousand threads, and it is a solution for an > entirely different problem, namely costly conditional statements; PHP on > the other hand runs on a general purpose processor that already cache > thrashes and runs into issues with instruction pipelines in parallel > execution, adding more threads to it would do nothing for performance (or > make it worse), make for more complex code and introduce new issues, like > for example how do you test threaded code, debugging, messaging, etc, which > will introduce new places where php apps fail, new security concerns, etc, > and I think we are far from having current issues fixed... That's all understood but there are times when that one request from the visitor requires many sub-requests like connection to DB and making SOAP calls. Sure, it can much faster do you think the response time for the visitor when the sub requests are done in child threads? Sure, I could implement curl_multi as you state below. > > Want to parallelize your PHP execution? Learn to love curl_multi :) > > In this case, fix the program, not the programming language. Just my $0.02 > But how do you then manage those calls or sub-threads? What about synchronizing? Like you said, fix the program right? Then shouldn't that be fixed in PHP at the core rather than a hack after? Cheers, Tommy > > -- Alex > -- > The trouble with programmers is that you can never tell what a programmer > is doing until it’s too late. ~Seymour Cray -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Multithreading for OOP PHP
Hey guys (and/or gals), I have heard this question entirely too many times, I think at some point Rasmus just stopped responding to it. The real reason that PHP is not threaded has nothing to do with PHP internal or extension thread safety, the reason is more to the extent that it doesn't make sense to add threading to PHP, it will only increase code and model complexity and create more points of failure, but again the reason is not this, the reason is that it doesn't make sense in PHP's native environment to add threading in the first place. Natively PHP is summoned by a web server, yes you can call PHP in CLI, but that's not it's point market, PHP is first and foremost a server-side language for the web and it is ran by a web server such as Apache or Nginx or IIS(i wouldn't know why you would use IIS, but it could be). All of these web servers (maybe with exception of IIS, i wouldn't know) work pretty much on the same principal, you have the main process that spawns a bunch of worker threads (this is adjustable in configuration, but is typically 1 per cpu thread). These threads are what actually process the requests and call PHP, meaning that if multiple threads are processing multiple requests, multiple instances of PHP will be called. This is why adding threading to PHP makes absolutely no sense, why would you spawn threads in something that is already being called by a thread? Don't get me wrong, threads spawning other threads is a solution, but it is a solution on massively parallel architectures, such as the GPGPUs that can handle over a thousand threads, and it is a solution for an entirely different problem, namely costly conditional statements; PHP on the other hand runs on a general purpose processor that already cache thrashes and runs into issues with instruction pipelines in parallel execution, adding more threads to it would do nothing for performance (or make it worse), make for more complex code and introduce new issues, like for example how do you test threaded code, debugging, messaging, etc, which will introduce new places where php apps fail, new security concerns, etc, and I think we are far from having current issues fixed... Want to parallelize your PHP execution? Learn to love curl_multi :) In this case, fix the program, not the programming language. Just my $0.02 -- Alex -- The trouble with programmers is that you can never tell what a programmer is doing until it’s too late. ~Seymour Cray
[PHP] Re: Multithreading for OOP PHP
Il Wed, 31 Oct 2012 11:50:00 +0100, ma...@behnke.biz ha scritto: > The drawback of forking is the memory overhead. With every fork you take > the same amount of memory which is not the case if you could use real > threads. No, it is not. Forking in Linux uses COW (copy-on-write), so a freshly-forked process occupies maybe 3-400 bytes of RAM. Only when writing on a memory location, that location gets allocated. There are advantages (it is more safe, as you can't overwrite other processes' memory) and disadvantages (you can't simply read or write memory to communicate between threads, but must use IPC). But speed and memory consumptions are not an issue. Bye. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: Multithreading for OOP PHP
Il Wed, 31 Oct 2012 11:57:11 +0100, ma...@behnke.biz ha scritto: > But it if PHP would be threadsafe, you would be able to run the Apache > in a much faster and less memory using way. > There once was a configure option in PHP to compile it threadsafe, but > they dropped it for a reason. Because PHP is threadsafe, but a lot of extensions are not. Besides that, using fpm makes it fast enough. On Linux a thread is not much faster that a new process, and uses nearly the same memory, but multiprocessing is much safer than multithreading, and much simpler to code. So I don't think that thread safety is such a big deal. Florian is more interested in the Java abstraction of threading than in the multithreading itself. There are various ways to accomplish something similar, but it is not integrated in the language. For example, you could use gearman to distribute database-intensive tasks on a server, or pcntl_fork to parallelize computation. Bye. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
