Touch of genius or insanity - take your pick

[448191]

I'm currently involved at work with a Java webapp, and recently I've been working on my CMS framework and a test implementation.

 

The latter is quickly becoming slower due to its complexity, so I'm looking at a variety of caching mechanisms including storing serialized objects, memcached, and using a generic socket server. Also I've been twisting my head around session and transaction management.

 

So, with Apache Tomcat in the back of my head, I'm thinking about designing the framework/app to run as a deamon instead. The bootstrap file (index.php usually) would simply connect to a socketserver, sending it all the request data, waiting for a response and copy it to the file's output.

 

What do you think: genius or insane?

 

 

[Jenk]

You're using php to stream to java? Why not just use jsp as that is it's purpose?

[448191]

Nah, this doesn't really have much to do with Java and/or Tomcat... It was just the concept of Tomcat that gave me the idea to use a socketserver deamon to maintain state of the application. The motivation is to save initialization time and do away with most of the persistence issues surrounding sessions, transactions and caching. Instead of complicating storing and retrieving semi-persistent data from some store, the data is simply made static.

 

The bootstrap is executed by Apache, after which it connects to the deamon, which processes the request in response to the request data passed and prepares a response. All data that is needed accross requests can be kept in memory. When the response is received, the bootstrap can ouput and die. The bootstrap will only include the most basic/lightweigth of socket clients.

 

One thing that bothers me though: memory consumption. Since there is no way to 'uninclude' a file, at some point most of the library will be in memory. But, another clear advantage is getting rid of parsing time. So potentially this saves massive amounts of response time, as long you have plenty of memory.

 

Gotchas?

 

 

 

[Jenk]

This is how Java is meant to be used - as a daemon.

 

As for mem issues, just remember to nullify pointers to any redundant objects and Java's own garbage collection will clean up.

[448191]

I know, that's what gave me the idea.

 

But I'm talking about applying the same principle to php. PHP socket servers have been running for quite some time, so I reckon there wont be too many issues. If the idea takes off, at some point I might port the simple socket client to C and write a simple Apache module.

[Jenk]

I wouldn't use PHP to do it, no point, it's not designed for that, and it certainly will not perform better than PHP/C/Smalltalk/etc. which have been doing it for years.

[448191]

I wouldn't use PHP to do it, no point, it's not designed for that, and it certainly will not perform better than PHP/C/Smalltalk/etc. which have been doing it for years.

 

I don't care if it performs better than a similar implementation in a different language.

 

I only care about the positive effect it will have on the performance of large PHP projects. And C certainly was not conjured up with the intent of running as web deamons. Neither was PHP, yet many socket server implementations exist. Granted not by far as efficient as their potential C or C++ counterparts, but that is completely besides the point.

 

And most definately NOT the intent of this thread.

[Jenk]

You asked for drawbacks.. and one of those drawbacks is that PHP is not designed for it. (Earlier mistake in mentioning that it is; wasn't meant to include it within the C/Java/Smalltalk/etc list.) The object model in PHP is not efficient at sustained activity.

 

I'm not sure what benefits it would have, I would post that it allows use of the familiar PHP syntax to PHP developers, but the differences in syntax between Java/C and PHP are minimal, and even against a different paradigm such as Smalltalk or Lisp it would be negligible learning curve to experienced developers.

 

However, for existing projects, this would pose a siginificant amount of refactoring - firstly, you'd need to ensure all objects are nulled to ensure garabage collecting (simply $object = null; when finished with it of course) and other trivial changes. If your applications use singletons, you're more than likely going to have to refactor those to use session identifiers; unless you decide to not use singletons, or haven't in the first place.

 

And for the record, C was conjured to run persistent applications - it's what OS's are made of after all.

[btherl]

Won't objects be garbage collected once they go out of scope?  I've used php for daemon style applications with no problems at all.  But I have not used OO style php for daemons.

 

I don't see how it would be easier to write a daemon in C than PHP.  And although there may be minimal differences in syntax between java, C and PHP, there are huge differences in semantics.  Memory management and strict vs loose typing are obvious examples.

[Jenk]

Java has no memory management, it is all automated.

 

In any daemon type application, there will always be a level of scope that will permanently exist - it is within this scope you must null pointers to redundant objects

 

Especially in PHP, where everything will be running in a while(true) loop. Also, PHP's garbage collection runs soley on reference pointer counting; i.e. it won't be collected until all reference pointers have been cleared (either out of scope as you say, or reassigned)

[448191]

Especially in PHP, where everything will be running in a while(true) loop. Also, PHP's garbage collection runs soley on reference pointer counting; i.e. it won't be collected until all reference pointers have been cleared (either out of scope as you say, or reassigned)

 

I think as long as you code with care, unsetting data that is not absolutely certain reset or reused, you will be fine. I'm also not a fan of cross-referencing objects, so that won't be an issue either. In the event that accumulating memory space can not be avoided, you can always implement a 'silent' restart. Basically that would just mean restarting the daemon when nobody is using it, most likely once a night. Seeing as how rarely used instructions will still be in memory, a periodical silent restart is a good idea. I might even use a gateway daemon, which can pool to several application instances. A simple cookie id can maintain a client's binding to an instance. If the gateway starts to exclude a certain daemon from the pool, the daemon itself can at some point determine it is no longer used and restart. A message can go back to the gateway as soon as the daemon is back up.

 

I really like the idea, and I'm going with it, although I will make it optional. I am moving focus from caching to this implementation though. Regardless, I'm still very interested in opinions and thoughts on the subject.

[Jenk]

Best of luck, but personally I think this is case of letting your favourite language dictate your direction, rather than letting the needs of the business/technology dictate your direction. A good developer does not depend on a particular language. Yeah, ok we all have our favourites, but we can all apply our knowledge to other languages.

 

PHP is not designed for running daemon's. It never has been, and is not looking likely in the future. It may have socket functionality, but even then they can/can't be argued that it was intended for daemon use. There are several other platforms/languages available which are much, much more suited to this type of scenario, and any experienced developer can pick up another language within a few days.

[448191]

Maybe so.

 

In any case, PHP is what I know best, and although I agree that anyone with some universal understanding of programming can pickup practically any other higher level language in a relatively short time, it takes time to discover a language's quirks, APIs etc. I know Java syntax (because it is really easy to pick up, and most books on patterns and such include Java examples), but to write a comprehensive Java framework when you're relatively new to the language is something else.

 

I've already started writing this, and initial test show a definite performance increase, and I haven't even done any optimizing. Would Java be the more obvious choice? Definitely. But I'm not writing a Java framework, I'm writing a PHP framework. End of discussion as far I'm concerned.

 

If anyone has any comments on this that don't involve suggestions to switch to a different language, I'd be pleased to read them.

 

This is a PHP forum after all

[448191]

For anyone curious, here's some code (it still has some temp code in there, but just to give you an idea):

 

appserver.php

 

<?php
include 'Backbone/Core/Settings.php';
Backbone_Core_Settings::init('E:\John\Sites\bbkm\App\Config\config.local.xml');

class Backbone_ApplicationServer extends Backbone_Sockets_Server {

public function handleRequest($clientSocket, $requestString){
	try {
		$httpRequestTransferObject = unserialize($requestString);
		if($httpRequestTransferObject !== null && $httpRequestTransferObject instanceof Backbone_Controller_Request_Http_TransferObject) {
			$response = Backbone_Controller_Front::run($httpRequestTransferObject->getRequest());
			$this->write($clientSocket, serialize($response->getTransferObject()));
		}
			else {
			$this->write($clientSocket, false);
		}
	}
	catch (Backbone_Exception $e){
		$this->write($clientSocket, $e->getMessage());
	}

}
}
include 'appconnection.php';
$server = new Backbone_ApplicationServer(HOST, PORT);
$server->maxRunTime = 15;
$server->socketReadTimeout = 3;
$server->serve();
?> 

 

appclient.php

 

<?php
include 'Backbone\Sockets\Common.php';
include 'Backbone\Sockets\Client.php';
include 'Backbone\Controller\Request\Http\TransferObject.php';
include 'Backbone\Controller\Response\Http\TransferObject.php';

class Backbone_ApplicationClient extends Backbone_Sockets_Client {

public function execute(){
	$this->socket = $this->createSocket();
	$this->connect();
	$response = $this->sendRequest(serialize(new Backbone_Controller_Request_Http_TransferObject));
	return unserialize($response);
}
}
$st = microtime(true);
include 'appconnection.php';
$client = new Backbone_ApplicationClient(HOST, PORT);
$client->socketReadTimeout = 3;

$response = $client->execute();
$response->sendOutput();
echo microtime(true) - $st;
?>

[Jenk]

You have a very blinkered view, if all you want is advice/opinions that agree with yours. If all everyone did is offer "positive" feedback to every idea; we'd get flooded with garbage (if there isn't enough already.)

 

P.S. I'd be willing to bet you'd not need write a framework for Java; there will be one already in existance and will have better support than any PHP framework.

[btherl]

Jenk, I think what 448191 is asking is that you restrict any further discussion to php daemons only, as he has already chosen PHP as the language to use.

 

I get that you think Java or C would be a much better choice.  448191 gets that too.  I don't think he disagrees with you either.  He's just asking you to stop discussing other languages in this topic.  He's not saying "PHP is better for daemons than Java".

[448191]

Jenk, I think what 448191 is asking is that you restrict any further discussion to php daemons only, as he has already chosen PHP as the language to use.

 

I get that you think Java or C would be a much better choice.  448191 gets that too.  I don't think he disagrees with you either.  He's just asking you to stop discussing other languages in this topic.  He's not saying "PHP is better for daemons than Java".

 

True. In fact, if my primary goal was to make an application that retains state in memory across requests, I WOULD be using Java, since it would be the easiest, proven solution. But it's not: my primary goal is make a framework for PHP applications. Running an application build on it as a daemon is just one way to improve performance. And it works very nicely too, especially when you have expensive initialization and lots of data to maintain state. It sweeps the floor with memcached caching.