Now if I call a page with a few code snippets, I think that the server calls up the page, parses it, generates the output and then serves it up. So, this process is repeated everytime that page is called. This would seem to add significant processor overhead, since the script needs to be loaded into memory anew with each call. Not an issue on a small site, but could become fairly significant on a lerger site with a significant amount of traffic.
Do I understand the process so far?
If so, it would seem more efficient to call a script once that stayed resident in memory until it was exited. Such a script would generate pages on the fly from a central user interface, simply calling itself over and over, but presenting different content on each call.
But, my question is, does this model hold up, or will the server reload the entire script every time the page is called by a browser, thuse creating that same overhead?
I suspect the answer is yes.
So, when it comes to scalability, what is the best approach? Should one keep the code on each page to the absolute minimum for that page to function? A complex dynamic site might have several thousand lines of code. It would seem a waste of resources to reload all of this with each call to the server.
Am I rambling? Is this a real issue, or have I taken myself off on a strange tangent?
To date I have worked on fairly small projects, but I am in the middle of one that promises to dwarf anything I have done to date. And, it may need to be scalable to fairly busy sites.
Can anyone give a understandable explanation of what is going on server side when my scripts are called?
WBF
I often see people overusing PHP's internal copression functions (that is ob_start('ob_gzhandler')) for that. While this is a handy option to start with, this will bite you when the traffic increases, because it recompresses the output with every request.
The mod_module gzip indeed is far more advanced, can cache compressed results, and more. It's potential is often overlooked. Another cool thing is Apache::Dynagzip, which is the only module I've found so far that can provide 'streaming' compression. I mean sending compressed output 'on the fly', before the generation is even completed. Unfortunately, using it with PHP requires CGI version and tricky setup. But for mod_perl it works wonders in terms of the site responsiveness with large recordsets.
daisho.
I think that the server calls up the page, parses it, generates the output and then serves it up. So, this process is repeated everytime that page is called.
If you are using PHP, use The Smarty Template Engine [smarty.php.net], it can cache the db's output and only query the db IF it's cache has expired. Very, very neat!
Nick
[edited by: jatar_k at 5:21 pm (utc) on May 30, 2003]
[edit reason] fixed link [/edit]
You may be interested in:
The Seven Deadly Sins of Templating:
www.thephpguy.com/modules/news/article.php?storyid=30
arrgh ;)
asp
[edited by: jatar_k at 5:20 pm (utc) on May 30, 2003]
[edit reason] delinked [/edit]
This sort of discussion has raged for some time now. I think the discussions in the forum section of smarty's website show a more balanced view. i.e. smarty.php.net then go to "discussion forums"/"article discussions"/"The logic of templates".
In the end it will come down to different people having different preferences, and purposes. There isn't a right and a wrong, I think.
I agree with the sensationalist sentiment, though a similar sentiment is expressed here at Zend:
One pro(ish): [zend.com...]
One against: [zend.com...]
- though again perhaps not that surprising ;)
asp
[edited by: jatar_k at 1:07 am (utc) on May 31, 2003]
[edit reason] see sticky [/edit]
