Just like I said earlier folks....
Confused the hell out of me, and proberly a lot of other developers as well ?
Umm....
IMO do we actually need .NET ? Nope...
| SitePoint Sponsor |
Just like I said earlier folks....
Confused the hell out of me, and proberly a lot of other developers as well ?
Umm....
IMO do we actually need .NET ? Nope...
The central theme behind a front controller seems to be A single object dispatches all requests and this is a good place to put a bunch of common behavior
So for reasons I mentioned earlier, having a single dispatch object works better in Java than PHP (because Java can maintain state between requests and PHP has to serialize/unserialize to simulate maintaining state.)
I think I agree with HarryF and Codezilla that the auto_prepend_file is a good mechanism for centralizing common behaviour in PHP.
In my benchmarks, auto_prepend_file is exactly the same speed as an include. This means that if you really do need the behavior in every request, there is no performance penalty for using auto_prepend_file.
My main problem with the front controller implementations in PHP that I have seen so far has been the overhead cost of the dispatch.
The microsoft literature on front controllers warns about performance overhead as one of the liabilities of this pattern while the sun literature does not. I wonder if this is a reflection of Java having a cheaper implementation of this particular feature than ASP or PHP?
Java has an API to hook into the webservers request dispatch mechanism that PHP Does not yet have
Until then, I think we are better off leaving the dispatch to Apache. I think this is equivelent to the Physical Resource Mapping Strategy mentioned in Core J2EE Front Controller Pattern
I wonder what the PHP developers would say regarding this topic, ie. how they would handle it...
This application uses http authentication in .htaccess files.Originally Posted by HarryF
For other applications with finer grained access control, I have added a security check as the first executable line of code in the file (at the add.php level):
or security checks before certain resources are accessed:PHP Code:CheckPagePermissions('Gallery','Create');
The config.inc file includes a security.inc file into every file that checks a user cookie and initializes some global data structures that these two functions use.PHP Code:hasPermission('Gallery', 'View', $Gallery)
Other way that I've added global behavior is by routing all template printing through an application level function:
Instead of
I would doPHP Code:$View->print();
DisplayPage would be defined in the config.inc file and be specific to the application. It would print the page view, add global site elements like dynamically generated global site menus.PHP Code:DisplayPage($View)
I have been moving many of things that I used to put in the DisplayPage function into the Page Controllers and into the templates.
In light of this thread, though, I think I might revisit the concept from a front controller/mediator perspective
In light of this thread, I definately think I will start using auto_prepend_file for my config.inc.
Yes. The template represents a complete page.
I will typically have one standalone template per page. (galleryform.html). A few templates per resource type (gallerydetail.html, gallerysummary.html) that only get used in other templates and a handful of shared global site layout templates.
I am a big fan of being able to use WYSIWYG editors on templates. (well, dreamweaver at least.) If you refactor your html to eliminate all duplication, you end up losing the ability to see what your site is going to look like while you are editing it in dream weaver. (a good example of losing the big picture is the smarty templates in x-cart.)
Its not necessarily good to think like a programmer when doing web design. (or force your own style of thought on them.) Web designers have their own types of tools for dealing with duplication (CSS).
I was want to make sure I understand the theory behind this:
Physical Resource Mapping:
//www.myserver.com/path/to/gallery/add.php
(as in your example above)
Whereas, Logical Resource Mapping:
//www.myserver.com/?process=GalleryAdd
Am I write in this assumption?
And you would prefer the Physical Resource Mapping?
right.
Here is an example of the Logical Resource Mapping Strategy as implemented by struts:
This tells the web server to pass any request that ends in .do to an instance of the servlet called ActionServlet. ActionServlet is the name of Struts front controler.Code:<servlet-name>action</servlet-name> <servlet-class>org.apache.struts.action.ActionServlet</servlet-class> ... <!-- Action Servlet Mapping --> <servlet-mapping> <servlet-name>action</servlet-name> <url-pattern>*.do</url-pattern> </servlet-mapping>
ActionServlet uses a struts-config.xml file to hold a mapping between url paths and the objects that should service requests
Here is a portion of the struts-config.xml file from the example that comes with struts:
So, when then web server receives a requestCode:<!-- Process a user logoff --> <action path="/logoff" type="org.apache.struts.webapp.example.LogoffAction"> <forward name="success" path="/index.jsp"/> </action>
http://www.myserver.com/logoff.do
It passes the request to the struts front controller.
The front controller then maps the request to the java object LogOffAction, and then sends the request to an instance of that object.
/jakarta-struts-1.0.2-src/src/example/org/apache/struts/webapp/example/LogoffAction.java
After the LogOffAction object processes the request, the front controller will redirect the browser to
http://www.myserver.com/index.jsp
The equivelent of the above servlet-mapping in Apache/PHP might be the following .htaccess file:
Now ActionServlet.php will receive any request that ends in .do and can dispatch the request as it pleases.Code:#untested RewriteRule ^(.*)\.do$ /ActionServlet.php?requestpath=$1 [L,qsa]
Here is another PHP framework that implements the front controller pattern. It uses auto_prepend_file and an empty place holder in the documentroot for dispatch. I wonder why they didn't use a RewriteRule like the one above?
I would like to let you know an in depth example of a PHP MVC implementation (using Phrame) is available as the sample article for the June issue of PHP|Architect.
http://www.phparch.com/issuedata/2003/jun/sample.php
Smarty is used as a template layer for the application, but this topic has veered a little off of the original subject and more towards MVC in general, so I thought you may find the article useful.
Regards.
I read that article just yesterday and I must say that it's much better than the first one. Jason Sweat has refactored some important elements and the framework looks indeed very neat now. Just have a look at the PhpDoc documentation package that's included with the sample code. It looks wonderfully clean and understandable.
sorry for reviving an old thread. i just wanted to say thanks to selkirk. with all this talk of MVC i thought i was doing something horribly wrong.
on re-evaluation i think i prefer the approach you describe. i've been developing (with smarty) in the same vein, and a typical page would look something like this:
in this sense, only the needed files (SomeClass 1 and 2) are being called, which i think MVC tends to (as you mentioned) have an all in one kinda approach to.PHP Code:<?
// class.Template.php is a wrapper around Smarty to provide basic application specific functionality. at the moment in sort of implies that i don't use a lot of smarty specific stuff
require_once('config.inc');
include_once('class.Template.php');
include_once('class.SomeClass.php');
include_once('class.SomeClass2.php');
include_once('class.AuthHandler.php');
AuthHandler::authenticate("required_permission");
$obj = new SomeClass();
$obj2 = new SomeClass2();
$data = $obj->getData;
$data2 = $obj->getMoreData;
$tpl = new Template()
$tpl->display(array($data, $data2), "template.tpl");
?>
i think it's important to use the web server to provide that extra little bit of navigational information, in that
http://domain.com/gallery/add.php (and)
http://domain.com/gallery/view.php?id=4
is preferable to
http://domain.com/index.php?resource...w&gallery_id=4
or whatever...
although i am finding i use an MVC approach for things like database updates (deletes, edits, inserts) where the above script would be modified with perhaps a quick switch statement
i think that's a decent tradeoff between URL readability, and having one big front controller (opting for the many little ones instead)PHP Code:$option = $_POST['option'];
switch ($option) {
case "add":
$obj->add($data);
break;
case "delete":
$obj->delete($data);
break;
case "update":
$obj->update($data);
break;
default:
trigger_error("Not a valid option");
break;
}
however, i'm still not convinced at the moment it's the best way for me to go about things, i'd like to simplify it a bit if possible, and am not sure if perhaps moving to a bit more of an MVC design with it is the right thing to do.. as to what that would look like i'm not entirely sure... (ie, what's between this and a front controller?)
Tough issue.
The filesystem. Think a front controller in PHP, that doesn't require a massive array which maps out your site has to work on the basis of "guess work".what's between this and a front controller?
An interesting study is ISMO (thanks to lastcraft for finally getting me to take interest) which is a nice lightweight framework.
The front controller (a script called do.php in examples) is not the name of a directory (the states directory) within which it can find page controllers. Then, depending on the URL, it attempts to include a file and execute the class in it (which has the same name as the file i.e. same name as the URL).
Filesystem
A URL like http://www.site.com/do.php/gallery gets do.php to load the correct file.Code:www/do.php www/states/gallery.php
With the file gallery.php there's a class called gallery (the page controller) which basically does the same thing as your switch statement above e.g.;
Methods starting with exec_ can be executed as a result of the URL e.g. those above would be executed by the following URLs;PHP Code:class gallery extends ismostate {
function gallery(& $request) {
parent::ismostate($request);
}
function exec_default() {
echo ( 'This is the default action' );
}
function exec_add() {
echo ( 'Adding something here' );
}
function exec_delete() {
echo ( 'Deleting something here' );
}
function exec_update() {
echo ( 'Updating something here' );
}
functoin foo() {
echo ( 'This is not executed' );
}
}
http://www.site.com/do.php/gallery <<< exec_default
http://www.site.com/do.php/gallery/blah <<< exec_default
http://www.site.com/do.php/gallery/add <<< exec_add
http://www.site.com/do.php/gallery/delete <<< exec_delete
http://www.site.com/do.php/gallery/update <<< exec_update
Another study is eZpublish 2.x where index.php is the front controller. Requests to a module lead to index.php looking for a file datasupplier.php in the module directory which contains a switch statement as to what to do next. Pretty simple but effective.
ah thanks for the link harry, good stuff. i'm not really a programmer so all this is quite new to me. hadn't been on sitepoint since a number of years ago and it's quite different(i just discovered your great site a few days ago through php architect in a round about way)
i like what they're doing, i took a quick look at the code but found it a bit over much for what i was doing, and as a result rolled a quick front controller to cover the basics (ie, parse the request and execute the action within the state, etc..). the only "change" i made (which i don't believe ismocore does... correct me if i'm wrong) is to allow for the data dir to be above the webtree, so we don't need to worry about setting an .htaccess to prevent accidental web access.
i still have (partial, very minimal) issue with making php simulate the error pages (page not found, etc...) as that seems like a task the webserver should be doing. but as a result of the default (at least in my code) any unknown request which is valid will end up in the default state anyhow (which seems either like a feature or a limitation depending on how you look at it)
when i get a bit more time i'd like to study the ismo code a bit more to see what else i'm missing
Hello,
I have read with interests your comments on MVC and PHP, and also the issues about object persistence, and I have to agree that I have the exact same opinion about PHP and object instantiation.
That is why OOP programming is PHP is pretty dumb, as OOP is designed to "keep the data and the procedures that process this data together", while in PHP the data is *always* loaded from a database.
We have met the exact same problem in Krysalis. (http://www.interakt.ro/products/Krysalis). Krysalis is a complete MVC implementation in PHP, and we think that we have solved most of the problems related with the overhead brought by MVC. Let me explain more:
"Why MVC" - because it's extremely flexible, and allows you to define with extreme ease rules of serving requests. While the default "serve from disk" method for PHP pages is pretty straight forward, it will not allow you to do enterprise level things. Like having 10 installed applications that share the same kernel, and that serves slightly different pages in logic or layout depending on the current application state. Maintanability increases exponentially.
"How"- we have chosen to create an XML structure to define our Controller. While this might seem "overheading" at the beggining, we've optimized this to a level that it is compiled to a pure PHP file that is written much better than the average coder will write it. What we have in our sitemap.xml file are description like below:
Which are compiled to a large switch loop that does dynamic requires of the compiled pipelines. This means that the overhead added by the controller is extremely minimal, as the file is pretty small and the code is loaded dynamically - and only the needed code:Code:<map:pipeline> <map:match pattern="language.xml" type="exact" internal="yes"> <map:cache type="xml" src="./admin/resources/descriptors/cache/desc.xml" time="360"/> <map:generate src="modules/core/language/front/index.pxp" type="pxp"/> <map:transform src="modules/core/language/front/{skin}.xsl"/> <map:serialize type="xml" remap="no" header="no"/> </map:match> </map:pipeline> <map:pipeline> <map:match pattern="search.xml" type="exact" internal="yes"> <map:cache type="xml" src="./admin/resources/descriptors/cache/desc.xml" time="360"/> <map:generate src="modules/core/search/front/layout/index.pxp" type="pxp"/> <map:transform src="modules/core/search/front/layout/{skin}.xsl"/> <map:serialize type="xml" remap="no" header="no"/> </map:match> </map:pipeline>
This is the generated code for the case where the Controller rules are simple (direct association between URL and pipeline that serves an URL), but optimized code is also generated for more complex cases.PHP Code:switch ($KTURL) {
case ("language.xml"):
$found = true;
require("/iakt/www/htdocs/www/prod/komplete/2.5.0beta4/krysalis/webapps/komplete/cache/0.cache");
break;
case ("search.xml"):
$found = true;
require("/iakt/www/htdocs/www/prod/komplete/2.5.0beta4/krysalis/webapps/komplete/cache/1.cache");
break;
Should we consider then our smart compilation a "front page controller"?
I think that a central approach has its advantages, and code reuse can be extremely well achieved if you wisely use the controller.
Of course, alternative approaches exist, and final decision should be made regarding your familiarity with OOP, XML or with your exact project goals.
Alexandru
Hi.
OO is about the development stage. It says next to nothing, as far as I know, about what happens at runtime. Can you explain the above comment?
I was wondering when code generation was going to be mentioned. Using XSLT to generate PHP code has proved a very effective combination in my experience. It allows a lot of preprocessing and PHP code can be "unrolled" (a'la loops) for efficiency. The thing is, this has no bearing on whether to use a front controller or not. You could just as easily generate the large number of script controllers as you could a single complex front controller.
To focus the debate again, it seems to me that front controllers work better with forms and can better cope with sudden switches of context. Examples include a form taking you to different locations or a permissions failure dropping you into an error page. Scripts either force ugly redirects or, slightly better, a PHP include(). Scripts lead to more natural page navigation and can mix easily with static pages. In the rough and tumble of web development this almost always ends up the preferred option for better or worse it seems.
Code generation can alleviate both of these with orthogonal tradeoffs such as greater developer expertise and the difficulty of refactoring XSLT code (for me at least).
A fascinating and overdue debate. More, more,...
yours, Marcus
Marcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
OO is not only about the development stage. Actually, to get more close to "semantics", a class represents the description of an object, that is something with sense only at runtime. While a class is a definition of some properties and methods (a.k.a. the data and the procedures to process it under the same roof), the object represents the existence in memory of a data structure that includes the object type and the object properties.
What I'm saying is that, for PHP, the object constructor and properties are executed/loaded each time for the persistent storage, and even if this stateless approach adds a lot to round-robin load balancing, it seems to me that objects are just hype in PHP (actually, they are very good when coding to structure your code better, and maybe to add some encapsulation, but not for many other reasons - as loose coupling can be achieved easily in other ways).
As we know it, PHP is a language mostly used for 2 reasons - loop through recordsets to display data in a tabular form, and process HTML forms to store records in the database. I think this represents over 80% of the web development out there. As both those usages involve simple application logic and complex presentation logic, it is a pain in the *** to include the presentation logic INSIDE the obejects that are design to include the application logic. I've seen postnuke with a lot of echo "<tr><td>".$content."</td></tr>" and it was enough for me.
Used wisely, loop unrolling is nice. Used without brains this can become a real pain in the *** - we've left some of our developers take this to the edge, and reached PHP unlooped code of about 800 KB for a simple form. However, after a small and effective optimization (moved the repetitive things into some old-fashioned procedures), we've ended up with less than 50 KB code for the same thing.
Actually Krysalis is a mix between a front controller and the page controller - that are both described in the sitemap.xml file. However, we will probably use something like a Cocoon2 FlowScript in the future to simplfy the definition of simple "flow" rules in the controllers.
[/QUOTE]
Alexandru
Orthogonal issues. Yes, in PHP data meant to persist between requests must always be reloaded. This has nothing to do with objects. You still have to reload the data even if you don't use objects.
Preaching to the converted about the benefits of MVC, although exponentially is a strong statement. However, I have to point out that MVC != FrontController."Why MVC" ... Maintainability increases exponentially.
Another strong statement. Encapsulating data into PHP code is one of the slowest ways of importing data into a running program. Have you considered something like this instead of your switch statement:"How"- we have chosen to create an XML structure to define our Controller. While this might seem "overheading" at the beginning, we've optimized this to a level that it is compiled to a pure PHP file that is written much better than the average coder will write it.
I suspect that you will find this dramatically faster for dispatch when not using a bytecode cache. I also suspect that it will be faster when you are.PHP Code:$Mapping = unserialize(file_get_contents($SerializedSiteMapFileName));
$Destination = $Mapping[$KTURL];
if ($Destination) {
$Found=TRUE;
require $Destination;
}
It also has its disadvantages. Many of them only show up in large projects. (Remember, MVC does not imply centralization.)I think that a central approach has its advantages, and code reuse can be extremely well achieved if you wisely use the controller.
I talked a little bit about centralization in my previous post. I have since learned that Struts 1.1 has added the feature to break up their single configuration files into multiple configuration files. They did this because they found that it was difficult for multiple team members to work on different parts of an application while having to share a centralized configuration file.
I expect further versions of struts will endorse further decentralization. I see that the xdoclet projects provides a decentralized way to specify a struts configuration file.
Another problem with a centralized configuration file that has to be compiled (ala Krysalis) is that as your application size increase, your compilation time increases. This represents an ever increasing drag on the code-compile-test cycle. I've noticed a trend towards quick feedback in this cycle driven by the growing popularity of extreme programming.
One thing about maintainability is that locality of reference in code is important.
JavaDoc style comments are more maintainable because the documentation is stored with code being documented.
Objects are more maintainable because the data is stored with the code that manipulates it.
My earlier file system example shows how the meta data is more robust on the macintosh file system because it is stored with the file that it describes.
Apache uses .htaccess files to decentralize configuration. There is nothing you can do in a .htaccess file that you can't do in httpd.conf. So why you need .htaccess?
This link talks about how XML is a more extensible and robust file format than binary formats because the meaning of a data item is stored with the data item itself as markup.
I see successful modern programming trends moving away from centralized structures in large scale development.
Something is wrong with this statement. Are we saying that data members in PHP objects must be made up of data taken from a database? That doesn't make sense. Perhaps you're talking about the non persistent nature of PHP from one page request to the next? This has nothing to do with OO in PHP or Java.
Cheers,
BDKR
If you're not on the gas, you're off the gas!
What's interesting about all of this MVC cacophony is that when I really look at it, it seems a bit like event-driven programming. The other funny thing is that I've been using an MVC like approach for a long time and didn't know it.
Anyways, please do note that I say it seems. I know it's not. First off, with event-driven stuff, there IS a persistence. There is something that never stops running/listening for an event of some sort then it runs off to process a bit of code that corresponds to that event. Also, there isn't the risk of event cascade.
But it is similar if you imagine the entire process of a page with various options or links being shown (the GUI), the following of one of those links (the event), and the process of responding to that event (the event handler or callback function or method). That's how I ended up with what is essentially an MVC pattern.
Just rambling....
Cheers,
BDKR
If you're not on the gas, you're off the gas!
Yes - but unfortunately you don't have to do this in Java (and I've also heard that .NET objects are persistent and reused using (guess what) class-id names). I'm not too deep in this, and frankly I have a good experience in Java and OOP architectures, but I think that the impossibility of doing this in PHP (yes, I know about SRM but never got to use it right) is one of the most annoying misses. Something like a "server-side" cursor, shared between pages when navigating a recordset, is not possible in the today/tomorrow PHP. And because of the process nature of Apache1 (as compared with the threaded approach in apache2), persistent objects that could be shared between requests will not be a reality soon. One could serialize to the disk or SHM, but this is a platform specific hack and still does not elimitate the constructors being called on deserialization, or the query of being recreated, etc.
Have to learn more about this indeed. Being caught up in the commercial world more than I would like, I have to admit that my research time has been "exponentially" decreasing in favor of some "marketing" activities. Actually, lately we've just bought two books based on a Slashdot post and on an Amazon recommendation. Martin Flower - "Patterns of Enterprise Application Architecture" and "Beyond software architecture - Creating winning solutions" - I have read the marketecture book first.
Maybe I'll find some time to read the other book this fall.
Actually we've done a lot of benchmarks about serialization and other techniques of optimizing the Controller part of Krysalis. We've started with PEAR Cache (based on smart serialization, but pretty sensitive on race conditions, also unable to effectively use a bytecode cache for the compiled PHP code), and then we've decided to create a simple cache layer for ourselves. Having the generated PHP code on disk and dynamically requiring it brought a lot of performance to the controller.
As for using a pipeline lookup table as your example suggest, it is doable of course, we've thought of it but never investigated as our goal was to "generate PHP code as similar as possible with the code written by a programmer" - to ease debugging. However, thanks for the tip, we'll investigate this as we are always looking to minimize the time spent in the controller.
The idea is that fixed url requests are just a subset of the Krysalis sitemap, as we also have dynamic pipelines like "mod_(page|article|gallery).html" that are served in the same pipeline and for which a lookup table will not do as we process the incoming URL with the pipeline regular expression to see if it matches.
We have indeed met this problem and it's quite annoying - we have a file lock procedure in the IDE (we have an IDE for Krysalis), but it's not the best way of handle this.
I'm really glad we've opened this conversation, as those are the exact problems we're confronting with, and with no time to research alternative open platform, we were doomed to search inside the team to find the solution.
Going descentralized with the Krysalis sitemap.xml file is a very doable thing, and we will look inside the Struts approach to see how they do this.
It seems that descentralization is the key for a maintanable architecture, and we have tried to implement this in the Krysalis by using aggregation. We define in the sitemap the possibility of merging resulted XML trees for the menu, the content and the nuggets, and then we aggregate them in a single output XML file.
Thinking at your comments, it really make sense now to redesign the Krysalis sitemap, to define the notion of module that comes with it's own sitemap and that is only integrated in the Krysalis main sitemap for future aggregation (right now we do this using copy/paste in the sitemap when we include a new module).
I think that Krysalis 3.0 will have this descentralized view in terms of sitemap.
Looking forward to other comments.
Alexandru
Hi,
Maybe because I am Romanian
No, we are not saying this, but most of the data members of a dynamic PHP website objects are usually information from the database.
Exceptions are the OOP hierarchies that include a lot of custom application logic or that are an independent API - think PEAR, or JpGraph.
The idea is that you can use PHP and OOP very beatifully to create a library that does something, but finally when you get to a dynamic website - everything goes to : interogate the database - mix the HTML code. At least for what we've done mostly in the last 3 years.
This is about it. When thinking of OOP in Java (for example), it was all about "live" objects, multiple threads running various objects, messages sent between the objects (few messages as Demeter might say).
Doing this in PHP is simply not possible - so the only way to write OOP in PHP (IMHO) would be to better structure your code.
I know that (see Zend survey about this) most PHP programmers use OOP to create websites, and I must admit that they can't be all wrong
I don't want to create a flame-war from the OOP purists, I think OOP has it's advantages and disadvantages, but until we'll have persitent objects we'll never be able to reach the elegance of Java (even if I understand that PHP is NOT Java and that it will never be). Also our non-OOP techologies have advantages and a lot of disadvantages but this is the open diversity that should fit all the programmers preferences
Alexandru
You are wearing Java colored glasses.
Those who know me know that I'm not an OO purist at the implementation level. It's good stuff, but it's not the solution to the software crisis.I know that (see Zend survey about this) most PHP programmers use OOP to create websites, and I must admit that they can't be all wrong
'...but until we'll have persitent objects...' is telling me that you are taking a Java centric view. Additionally, you probably feel that there is some concern of how this affects the creation of enterprise solutions in PHP.I don't want to create a flame-war from the OOP purists, I think OOP has it's advantages and disadvantages, but until we'll have persitent objects we'll never be able to reach the elegance of Java (even if I understand that PHP is NOT Java and that it will never be). Also our non-OOP techologies have advantages and a lot of disadvantages but this is the open diversity that should fit all the programmers preferences
Two points:
1) The persistence of objects is not part of the OO paradigm. The idea of OO predates Java (believe it or not) and the wide spread use of the internet which is why data persistence is even a question in this conversation.
2) The concept of shared nothing is an alternative to issues concerning persistence of state in PHP enterprise solutions.
As for elegance in regards to scaling a Java solution,
The Java approach encourages not just more complexity, but additional purchases to accomodate that complexity. Grabbing a JVM and notepad, you'll have a harder time setting up a webfarm than you would with a LAMP system. Many companies have a lot riding on 'enterprise' Java, and to make things *easier* runs counter to everything those companies have built the past few years.
I've run in to a few people who've claimed that in memory sessions can be distributed *instantly* between dozens of machines in a webfarm with no latency. I've asked for clarification on this point several times, and I've yet to see/read any. I've been hearing this claim since '99 when a colleague was raving on about weblogic (I think that was it). It was something like $25,000 per CPU at the time. Yes, even if that's faster, that's nifty and all, but building a 10 node cluster can easily put you in the $500,000+ (with hardware). I was also told that one machine running weblogic could have 50,000+ concurrent users with no noticeable lag time. Of course, no one ever gave the *hardware* specs to support that claim.
I wrote a good number of administrative utilities (in PHP) that needed to maintain state from page view to page view. These were deployed in a cluster (or web farm). I had the ability (as the cluster administrator) to route a visitor to the same machine in the cluster that he or she may have started a session on. If he/she/it started the session on Web_2, then the cluster manager (ATM in Turbo Cluster speak) would continue to route he/she/it to Web_2. However, it didn't matter if it managed to do this or not as the session information was stored in the database. All of the web servers in the cluster had the database in common.
The reason I state this is because PHP is not Java so we shouldn't feel the need to look at PHP through Java colored glasses. The route or solutions taken by the Java community can't be mapped onto PHP for a good number of obvious reason. Therefore, we shouldn't even try.
If you're curious what is meant by 'shared nothing', check the link below.
http://php.weblogs.com/discuss/msgReader$2677
Cheers,
BDKR
If you're not on the gas, you're off the gas!
Nice said
I actually don't think that persistent objects are the solution to the software crisis, but theu will surely make a lot of things easier/faster.
I see, and I completely agree with you - as persistence has it's advantages and also has its drawbacks.
I have proposed (but actually never implemented) this clustering solution to some of our clients, and indeed I've found it very easy to setup and maintain.
Why haven't you used msession to keep the sessions together and decided to use a database?
Alexandru
Hi...
Not really the problem. You still get one click testing if the appropriate test case invokes the necessary make command. With things being built on demand the developer impact is zero. We are only talking about a few thousand lines of code after all, not building a major C++ project.
This is the problem.
yours, Marcus
Marcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
A number of reasons. At the time, I wasn't doing any development as such. My sole job was to build the back end and assist the head developer with migration to a different database. I decided that this was the most cost effective solution. At the ATM (let's call it cluster manager from now on as ATM means at least three different things in my head) level, I could maintain sessions, but none of what the head developer was doing required it. There are two reasons for this.
1) It wasn't needed for the transaction servers.
2) He had no concept of security (for the web based admin stuff).
Additionally, I didn't have a complete understanding of what msession was. However, I saw an easy solution to the problem by using the database.
Having looked at the msessions page just a little while ago, it seems pretty cool. However, I'm curious how this is worked into a system where there can be no single point of failure. One of the things I strived to do with the system was make sure a failure somewhere in the system was a non-event to the user. No more than a 2-3 minute (5 at most) interval before the system was aware of a failure somewhere and could adjust. Based on my understanding so far of the msession solution, I would need at least two seperate machines running the daemon to provide fault tolerance. One would be a slave that is also somehow monitoring availability of the first and replicating (synchronous) the state data maintained by the first. If the first one goes boom, the second one could easily step in and start doing battle.
This is something that is worth exploring for the most part. As much as this may take care of maintenance of state better than a db, it seems at this point to be more expensive and complicated.
Cheers,
BDKR
If you're not on the gas, you're off the gas!
Posting Permissions
Bookmarks