[FLOW3-general] FLOW3 Background Service / Daemon

[Thomas Fritz]

2010/8/8 Manuel Strausz <tminus at bitmap.co.at>

> Am 04.08.2010 11:59, schrieb Thomas Fritz:
>
>  What do you think about that idea?
>>
>> Kind regards
>>
>
> Hey,
>
> I think it's a pretty interesting idea. But there might be more problems to
> this approach than meets the eye; PHP has (by it's very nature) a
> share-nothing approach for every singular process that is started (by Apache
> or otherwise).
>
> By making background services you essentially share the data of any
> framework components that you chose to start in the background. With the
> obvious benefits of that approach come all the pitfalls of parallel
> programming.
>
> I guess if you could program it in such a way that the components get
> loaded once (by the first process), and all the data is stored as an
> invariant in memory after that, you shouldn't have too many problems. I can
> see this working very well for stuff like reflection.
>
> But: the reflection data is already cached. The only benefit I see right
> there is that you don't actually have to instantiate the cache manager, and
> the reflection service, since it's already running.
> But the big bottleneck would be more in actually performing the reflection,
> which only has to be done once at this point (until the class is changed
> anyway). So while this would indeed improve performance a bit, I'm not sure
> it's worth the effort right now.
>

Yes. You may be right with the reflection service. Perhaps the core
developers comes more useful parts of FLOW3 in mind.

I could think of multiple background services each one for a single purposes
OR - probably the better way - only one general global FLOW3 background
daemon where by default some main FLOW3 parts like Reflection, I18N, MVC,
CLI, Monitor, Log, ObjectManager, Persistance, and so on gets registered
automatically as services. Optionally a developer could register multiple of
his own services. If you want to retrieve a service you have to know the
socket to connect to and of course the name of the service. It could be
pretty much the same like in that
http://talks.php.net/show/srm-montreal/13 example
of SRM. I know that it is not that easy - but i definitely think that it can
be done and would be a real killer! ;) An Application built on top of FLOW3
would benefit from such a service or services especially on high load
applications.

With the new HTML5 features like WebSockets or Server Sent Dom Events such a
background service could be the base for a WebSockets Server for FLOW3.

As i said above i think the CLI could also be started as such a backgrund
process - optionally of course. I realized when i tried a patch from this
issue http://forge.typo3.org/issues/4426 that there is already a background
process for the CLI. The class for this whcih gets used is
\F3\FLOW3\CLI\Host
Here is the part how it gets used in Packages/FLOW3/Scripts/FLOW3CLI.php
<code>
do {
$host->output('Enter command: ');
 $input = $host->readLine();
try {
$host->parseInput($input);
 } catch(\F3\FLOW3\CLI\Exception\InvalidInput $e) {
$host->outputLine('Error: Could not find a matching command.');
 $host->outputLine('Enter \'help\' to get a list of available commands.');
} catch(\F3\FLOW3\CLI\Exception\MissingArgument $e) {
 $host->outputLine('Error: Not all required arguments were specified.');
$host->outputLine('Enter \'help\' to get a list of available commands.');
 }
} while(TRUE);
</code>
 As you can see it gets used in while loop and waits for user input. Once
started it is really fast.


> Since you can configure the cache to use in-memory storage e.g. with APC or
> memcached, which already is a background process, we're already half-way
> there anyway. It's all about caching with these modern approaches.
>

Of course. APC should (I read that it will be installed and activated by
default in a future release of PHP) also be configured for FLOW3 but it is
not the same like such a background service.


>
> By the way, slightly off-topic, but when testing serveral FLOW3 components
> with a rather big project (around 300 classes) I noticed that the reflection
> cache was actually getting so big that it would take almost a second just to
> unserialize the cache.
> One way to work around this problem (that I actually implemented as a test
> version) is to have one reflection cache per controller, which only caches
> the reflection for the classes used in that controller. I think FLOW3
> definitely needs to consider that when we finally see real-life projects
> with a lot of classes.
>
>

> So, as I said I think background services could have it's uses but I think
> caches solve much of the same problem domain. I could be wrong though since
> I never actually tried anything like that :)
>
Me too. ;) Caching is great and i think FLOW3 does caching very very well.
But i think performance is not the only benefit we would get from such a
"background service".
This is why i wrote to the list - hopefully core developers can answer what
they think.


>
> kind regards (und schöne grüße aus Wien ;)),
>

Hehe. Liebe Grüße.

Kind regards


---

*Thomas FRITZ*
*web* http://fritzthomas.com
*twitter* http://twitter.com/thomasf