1897 1669 1237 1187 1675 1831 1973 1076 1992 1049 1111 1665 1317 1568 1813 1291 1605 1908 1240 1424 1534 1039 1923 1161 1044 1557 1425 1076 1168 1346 1118 1885 1679 1060 1490 1719 1343 1435 1956 1937 1549 1892 1461 1149 1625 1172 1793 1760 1036 1955 1973 1688 1302 1483 1113 1589 1375 1680 1263 1314 1646 1818 1084 1244 1614 1134 1753 1476 1660 1765 1439 1247 1352 1041 1601 1522 1523 1913 1597 1913 1507 1236 1275 1029 1635 1208 1177 1461 1895 1509 1101 1825 1479 1193 1059 1677 1978 1927 1920 But, is it web scale ? | PHPnews.io

PHPnews.io

But, is it web scale ?

Written by Krakjoe / Original link on Oct. 5, 2014

Before we start to cover the topic of how to achieve parallel concurrency in PHP, we should first think about when it is appropriate.

You may hear veterans of programming say (and newbies parrot) things like:
Threading is not web scale.
 This is enough to write off parallelism as something we shouldn't do for our web applications, it seems obvious that there is simply no need to multi-thread the rendering of a template, the sending of email, or any other of the laborious tasks that a web application must carry out in order to be useful.

But rarely do you see an explanation of why this is the case: Why shouldn't your blog be able to multi-thread a response ?

The reasoning is simple: Threading at the front end of a web application doesn't make good sense; if a controller instructs the operating system to create even a reasonable number of threads, for example 8, and a small number of clients request the controller, for example 100, you are asking your hardware to execute 800 threads concurrently.

CPU's would have to look much different than they do today before anyone could say that is a good idea.

This is not how we make use of 1:1 parallel concurrency in any language that supports it.

† Some programming environments employ a N:1 (many-to-one) or N:N (many-to-many) model, whereby the kernel is not necessarily aware of every thread created, this is colloquially known as green threading. PHP uses a 1:1 (one-to-one) model whereby the kernel is aware of every thread created.


So, when is it appropriate ?

Take MySQL for an example; it uses parallelism to realize its extremely complex services, many other bits of software in the web stack do the same.

When we look at how they provide their services, we can see that MySQL's complex execution environment is isolated from the service that uses it by process boundaries; that is to say, services are provided by some sane form of IPC and or RPC.

This is how we make use of parallel concurrency; we separate and isolate those parts of our application that require what parallelism provides.

We keep our frontends simple, we keep them scalable.

Our backends can create and manipulate as many threads as they need to service the frontend of our applications, they can be responsible for all of the complexity in an isolated, controlled and well designed environment.

Can PHP really be used to write system services ?

Historically we have advised against writing long running scripts in PHP.

Today, PHP is suitable for such things, obviously there are pitfalls, there are things to think about, but there is no technical barrier to writing long-running scripts, even ones that run indefinitely.

Obviously, much like there is in Java, or any other language that might be used to write system services or long-running code, care must be taken to ensure that the code you write is logically able to run indefinitely; if you append an infinite amount of members to an array you will need an infinite amount of memory.

With great power ...

Parallelism is one of the most powerful tools in our toolbox, multicore and multiprocessor systems have changed computing forever.

But with great power comes great responsibility; don't abuse it, remember the story of the controller that created 800 threads with a tiny amount of traffic, whatever you do, ensure this can never happen.

web scale krakjoe frankdejonge krakjoe

« Monkeys and Humans - Signing Project Releases »