Very basic life-cycle related question

[eluser]Hagbard[/eluser]
Hello there,

I'm a software developer coming from the Java and .NET world with no PHP experience, but a customer of my company required me to develop a PHP 4.3.11 (sic!) web frontend. Since I was already familiar and comfortable with the MVC pattern through J2EE/Struts development, I chose to use Codeigniter as a nifty helper to make it easier to do things "the right way" from the beginning.

Now there is a thing I find awkward.
Coming from Struts, I'm used to the way Tomcat handles the lifecycle of my Front Controller, a.k.a. ActionServlet, which basically means that the front controller, along with the framework's base classes, gets instantiated only once - e.g. when the web server is freshly started and the very first request is recieved. All subsequent requests are handled by the same servlet / front controller instance.

However, with Apache and CodeIgniter, it seems that all CI classes and custom controllers and "libraries" get instantiated again and again for every single request. Firstly, this is bound to be a great deal of performance overhead. But the biggest trouble I'm having is that I have to download some application resources from a remote SOAP web service (using the PEAR SOAP library), which I would like to do only for the very first request and keep it in the memory afterwards, rather than downloading the resources again and again for every single request. Is there any way to resolve these issues? Or am I just looking at it from the wrong direction?

Greetings (and Hail Eris ;-)),
Hagbard

[eluser]nmweb[/eluser]
Welcome to PHP, yes everything needs to be loaded on every request, that's the php way of doing things. You can use memcache to store stuff in memory but as I understand it it's just like a file cache only faster. Php just handles stuff very differently.

[eluser]Hagbard[/eluser]
Thanks for your reply, nmweb. At least this makes things clearer to me, and CI's architecture makes much more sense with that knowledge. So if I understand that correctly, it is impossible to keep application resources session information in the memory, which means that I have to persist it to the file system or a database. This has huge implications on my architecture.
Concerning memcache: What would be the advantages of it as opposed to CI's built-in caching mechanisms?

[eluser]Hagbard[/eluser]
Ok, I have to admit that my memcache question was a stupid one, a little reading quickly brings clarity here. Memcache could indeed become very handy for my application, so thanks a lot for the hint!

[eluser]mglinski[/eluser]
The Way non java webservers work is they don't keep the program in memory after you are done with the request. The memory is freed and Apache goes back to listen mode. Java is a very different animal, and this is the main feature of java i would love to see implemented in at least one webserver that supports php. Alas, most are content the way it is, and to be honest I'm not sure of the level of changes needed to make that happen.

So if you haven't yet, rethink what your webserver requirements are.
Just FYI ;D
-Matt

[eluser]Hagbard[/eluser]
Thanks a lot for the clarification, Matt. Concerning requirements: PHP4+Apache are requirements that were "dictated" by the customer, I pretty much didn't have a choice there. But I think I'm getting the grasp of it now, it seems I just have to abandon some of my old ways of thinking concerning web development.
Perhaps that's slightly off-topic now, but I was wondering if the same is true for Ruby on Rails / Mongrel. At least RoR seems to have built-in support for caching stuff in the memory, I wonder how it manages to do that if the program isn't kept in the memory after a request was finished.

[eluser]mglinski[/eluser]
ROR is one language to avoid for web development. It has a bad history(in my opinion) and is very hard to get working good for large applications. PHP or JAVA is the web language I would recommend. Not only that but you can get java like performance out of PHP by using a bytecode cache like APC. It eliminates the overhead of compiling on every request. Implementing APC had more then tripled my applications' performance with Apache. You might also want to look into the Nginx Web server for the best "static" performance like minimal php+file serving combined(using php to serve files, like a file hosting service).

My recommendation: PHP 5.2 + APC, Memcache for all database queries, and a skinning system(if you are using one) that caches output(like smarty). That will extract the most scalable and raw performance out of php.
-Matt

[eluser]Randy Casburn[/eluser]
@Hagbard -- Myopia abounds everywhere -- What drew me to this post was your use of the terms "life cycle". It sounds like you have enough experience to see past your own blinders and I applaud that. PHP+Apache will meet your performance needs regardless of any perceived caching dilemma that may or may not exist at this time. So if you're locked into PHP+Apache let's go solve your perceived performance problems. There are many ways to do that. You will find the life cycle issue will require a paradigm shift, but not a huge performance loss.

CI is not as pure OOP platform as you are accustomed to nor is it as pure an MVC pattern follower due to that case. You should be aware of that too.

Randy

p.s. I find it interesting that performance and caching be such an importance in one note, while at the same time the use of SOAP is mentioned too. It's almost like a teeter-totter ;-).

[eluser]Daniel Eriksson[/eluser]
The PHP way of persisting data is to use session variables. These are persisted to a file on the server between requests by default, but can be persisted to a database (very useful when using a session-unaware load balancer for example) or to a client-side cookie (CodeIgniter default).

[eluser]Colin Williams[/eluser]

Myopia abounds everywhere—What drew me to this post was your use of the terms “life cycle”. It sounds like you have enough experience to see past your own blinders and I applaud that.

Whew! Someone open a window because Randy's getting all hot and steamy with this CS talk. Ha! It's very interesting and informative to experience the perspective of someone like yourself, Hagbard, who is going from one environment to another--as opposed to some schmuck who went from PhotoShop to PHP, like myself!

Sounds like these guys have set you on the right path, too. Good luck!