You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For both people following this and for my own documentation purposes, here's a little background:
If you start the server with 12 threads, you'll get 24 PHP worker processes. Each one has a copy of the application state. That is, if you bootstrap the framework in the server, you get 24 copies of the framework stack running in memory waiting to handle requests. The first available will handle a request.
In the example in the readme:
class MyApplication implements \Aphplication\Aphplication {
//Application state. This will be kept in memory when the application is closed//This can even be MySQL connections and other resourcesprivate$num;
publicfunctionaccept(): string {
$this->num++;
//return the response to send back to the browser, e.g. some HTML codereturn$this->num;
}
}
There would actually be 24 $num variables, one in each thread. What that means is, if you load the page and Worker 1 handles the request, the $num variable in Worker 1 is incremented. Of course when you view the page again, if Worker 2 handles the request you see 0 instead of 1 because you're seeing Worker 2's $num variable.
Until the recent changes this was worked around using sessions a bit like a load balancer: When you connected to the application for the first time you were allocated a worker ID stored in your client's session. Each time you view the page, only your assigned worker process will handle your request.
This works well for demonstration purposes but it's not really very practical. You wouldn't store $num like that because everyone viewing the site sees the same thing. If two users are allocated to Worker 3, they'll both be incrementing the same counter.
There are also performance considerations: It requires session_start() and some logic in the client. Opening the session is quite slow and should only be done when necessary.
The whole "assigning a user to a worker process" concept has now been dropped. If you connect to a page, the first available worker process handles the request. By doing that it gives two substantial performance increases:
A session does not need to be started, written or closed in the client script
You never have to wait for your worker process to become available, the first available will handle your request.
I'll do some benchmarks soon. This was already fast, it should now be even faster.
I've also made global variables and sessions work as-is. You should be able to use this app server on any website that has a single entry point (e.g. everything routed through index.php).
The text was updated successfully, but these errors were encountered:
For both people following this and for my own documentation purposes, here's a little background:
If you start the server with 12 threads, you'll get 24 PHP worker processes. Each one has a copy of the application state. That is, if you bootstrap the framework in the server, you get 24 copies of the framework stack running in memory waiting to handle requests. The first available will handle a request.
In the example in the readme:
There would actually be 24
$num
variables, one in each thread. What that means is, if you load the page and Worker 1 handles the request, the$num
variable in Worker 1 is incremented. Of course when you view the page again, if Worker 2 handles the request you see0
instead of1
because you're seeing Worker 2's$num
variable.Until the recent changes this was worked around using sessions a bit like a load balancer: When you connected to the application for the first time you were allocated a worker ID stored in your client's session. Each time you view the page, only your assigned worker process will handle your request.
This works well for demonstration purposes but it's not really very practical. You wouldn't store
$num
like that because everyone viewing the site sees the same thing. If two users are allocated to Worker 3, they'll both be incrementing the same counter.There are also performance considerations: It requires
session_start()
and some logic in the client. Opening the session is quite slow and should only be done when necessary.The whole "assigning a user to a worker process" concept has now been dropped. If you connect to a page, the first available worker process handles the request. By doing that it gives two substantial performance increases:
I'll do some benchmarks soon. This was already fast, it should now be even faster.
I've also made global variables and sessions work as-is. You should be able to use this app server on any website that has a single entry point (e.g. everything routed through index.php).
The text was updated successfully, but these errors were encountered: