# Single Point of Entry Apps.

- Thread: https://externals.io/message/95653
- Original archive: https://news-web.php.net/php.internals/95653
- Started by Michael Morris on 2016-09-05T16:03:22+00:00
- Messages: 5
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #95653 — Michael Morris — 2016-09-05T16:03:22+00:00

URL: https://externals.io/message/95653#95653

Something I was reminded of during the discussion of replacing pear with
composer that I thought was worthy of it's own thread.  Most PHP apps I've
seen that use composer are
single point of entry apps - that is there's one front controller, usually
index.php, and .htaccess rules are put in place that route all requests to
that file.

These apps then go through the process of initializing themselves and
sometimes there are thousands of lines of code that get parsed through
before the app is in ready state, the router finally loaded and a decision
is made concerning the user's request.

This is extremely inefficient

What can be done in PHP core to more effectively embrace this paradigm
without disturbing the current one?  That's what this thread is to
discuss.  Here's my stab at it.

Create an .htaccess directive that allows a php file to be a directory
handler.  When that directive is set the webserver will pass any
non-existent file request to PHP (in effect becoming a one line replacement
for a very common usage of mod_rewrite).

When this directive is used two statements will be looked for by the
runtime - first a ready statement (not necessarily named "ready"). When it
is reached PHP will save the application state, clone it and continue
working from the clone. On all all subsequent requests to the directory PHP
will start by creating a new clone and working from there.

The second statement instructs PHP to drop the saved state and load a new
one starting with the next request (graceful) or to kill any concurrent
workers (panic)

This isn't the same as opcode caching - this would be caching of the entire
application state including any data harvested from config file reads or
database calls.

It is possible to create this setup now using some PHP worker process
trickery, but it isn't easy.

Again, the above may not be a possible solution - but there's got to be a
better way than the current approach which amounts to installing the
application on every single request.

Thank you all for your time.

---

## #95654 — Christoph M. Becker — 2016-09-05T16:16:08+00:00

URL: https://externals.io/message/95653#95654 · In reply to: #95653

> Something I was reminded of during the discussion of replacing pear with
> composer that I thought was worthy of it's own thread.  Most PHP apps I've
> seen that use composer are
> single point of entry apps - that is there's one front controller, usually
> index.php, and .htaccess rules are put in place that route all requests to
> that file.
> 
> These apps then go through the process of initializing themselves and
> sometimes there are thousands of lines of code that get parsed through
> before the app is in ready state, the router finally loaded and a decision
> is made concerning the user's request.
> 
> This is extremely inefficient
> 
> What can be done in PHP core to more effectively embrace this paradigm
> without disturbing the current one?  That's what this thread is to
> discuss.  Here's my stab at it.
> 
> Create an .htaccess directive that allows a php file to be a directory
> handler.  When that directive is set the webserver will pass any
> non-existent file request to PHP (in effect becoming a one line replacement
> for a very common usage of mod_rewrite).
> 
> When this directive is used two statements will be looked for by the
> runtime - first a ready statement (not necessarily named "ready"). When it
> is reached PHP will save the application state, clone it and continue
> working from the clone. On all all subsequent requests to the directory PHP
> will start by creating a new clone and working from there.
> 
> The second statement instructs PHP to drop the saved state and load a new
> one starting with the next request (graceful) or to kill any concurrent
> workers (panic)
> 
> This isn't the same as opcode caching - this would be caching of the entire
> application state including any data harvested from config file reads or
> database calls.
> 
> It is possible to create this setup now using some PHP worker process
> trickery, but it isn't easy.
> 
> Again, the above may not be a possible solution - but there's got to be a
> better way than the current approach which amounts to installing the
> application on every single request.
> 
> Thank you all for your time.

Not long ago (something like) this has already been proposed, see
<http://news.php.net/php.internals/92249>ff.

-- 
Christoph M. Becker

---

## #95664 — Andrea Faulds — 2016-09-05T17:47:31+00:00

URL: https://externals.io/message/95653#95664 · In reply to: #95653

Hi Michael,

Have you looked into PHP application servers, where the PHP code itself 
acts as the web (or FastCGI) server, and so can keep the whole framework 
etc. initialised in memory between requests?

This is how other (non-PHP) web stacks avoid “installing the application 
on every single request”, and it can also be applied to PHP, it's just 
not very common.

One example is Aerys (https://github.com/amphp/aerys), but it's hardly 
the first or the last example of this approach.

Thanks.

-- 
Andrea Faulds
https://ajf.me/

---

## #95796 — Michael Morris — 2016-09-08T14:05:17+00:00

URL: https://externals.io/message/95653#95796 · In reply to: #95664

> Hi Michael,
>
> Have you looked into PHP application servers, where the PHP code itself
> acts as the web (or FastCGI) server, and so can keep the whole framework
> etc. initialised in memory between requests?
>

I have - it's what I was referring to when I mentioned PHP worker process
trickery. I know it can be done, but it isn't straightforward and it can't
be quickly applied to existing applications like Wordpress or Drupal.

>
> This is how other (non-PHP) web stacks avoid “installing the application
> on every single request”, and it can also be applied to PHP, it's just not
> very common.
>

I know. What I'm wondering though is, could there be a way to do this on
the PHP engine level that would avoid massive rewrites of existing PHP code.

Here's my current draft of a way to implement this using two statements.

require_bootstrap( [FILE] );

This statement loads and executes the code in question just as require
does. It saves the execution state before moving to the next code line
after this statement is called. If called without a file it saves the
execution state immediately.

The saved execution state is hostname aware for sites that use a multisite
configuration.  So if the statement is reached from
www.onesite.com/index.php and from www.twosite.com/index.php two different
bootstraps will be created. This is done on the assumption that the booting
process is going to make one or more decisions based on the hostname.
Drupal loads entirely different setting files, module lists, uses a
different Dependency Injector, all according to the hostname.

unload_bootstrap( [PATH] );

This unloads the bootstrap associated with the webpath given. If no
argument is given the current bootstrap image is dropped. Question - should
passing boolean `TRUE` unload all the bootstraps at once, or should that be
it's own function, or is it necessary?

Note that bootstraps will be unloaded automatically if the opcode cache for
the associated files changes.


Thoughts, suggestions, questions, complains, or flames?

---

## #95804 — Daniel Morris — 2016-09-08T15:11:03+00:00

URL: https://externals.io/message/95653#95804 · In reply to: #95664

> Hi Michael,
> 
> Have you looked into PHP application servers, where the PHP code itself 
> acts as the web (or FastCGI) server, and so can keep the whole framework 
> etc. initialised in memory between requests?
> 
> This is how other (non-PHP) web stacks avoid “installing the application 
> on every single request”, and it can also be applied to PHP, it's just 
> not very common.
> 
> One example is Aerys (https://github.com/amphp/aerys), but it's hardly 
> the first or the last example of this approach.
> 
> Thanks.

I'm sure I remember reading somewhere that fabpot was working on one in
Golang? Something similar to Unicorn or Puma from the Ruby ecosystem
would be a boon.

--
Daniel Morris
daniel@honestempire.com