Page 1 of 1

Opening sessions too much?

Posted: Sun Feb 18, 2007 6:31 pm
by seodevhead
You know, I have been building some large web applications over the past 2 years and have never given this much thought, but now I am not sure if I did something that is "taboo" in the php professional world. Perhaps someone could tell me if what I did is perfectly acceptable without ill-effect.

For most of the pages throughout these applications, I have a header file that is included in each and every php file. That header file includes:

Code: Select all

ob_start();
session_start();
And of course, each page has a footer file included that says (amongst some other things):

Code: Select all

ob_end_flush();
Is this a bad thing to start a session on every page? Some of the pages use the sessions and that is why I have it in there, but for the most part I'd say 70%+ of all the pages don't utilize any sessions. Does it hurt to have the session opened in all these "non-session using" php pages? Or does it not make a difference one way or another? I just don't want to unnecessarily make my server work harder than it has too, even though my server is more beefy than I need.

Any advice or suggestions on this would be greatly appreciated! Thanks!

Posted: Sun Feb 18, 2007 6:41 pm
by onion2k
start_session() doesn't start a new session every time you call it. It checks to see if the user has a session (by seeing if there's a file in the sessions directory that matches the user's session cookie), and if there is it opens the file and puts all the variables into $_SESSION (or the main scope if you've got register_session_vars turned on). If there isn't a file there it creates one and saves anything registered to the users session to it ready for the next time the user loads a page. I guess you could only put session_start() into pages that you know need session variables, but I wouldn't myself. It's much handier to have the session data available everywhere.

ob_start() doesn't work in the same way as sessions at all. Instead it simply switches PHP's output from being sent straight to the user to being saved in memory until the page is completed and then it's sent to the user. It's much more of a problem in a busy application than sessions. If your server is getting hit a lot, or if pages take a long time to build you'll run into memory issues. You'll also find that users feel pages take a long time to load because their browser can't render anything until it gets data, and it won't get data until the page is finished running. Personally I switch output buffering off unless it's absolutely necessary. Most of the time it isn't.

Posted: Sun Feb 18, 2007 7:15 pm
by Kieran Huggins
You seem to be doing fine seo.

Check out the following INI options in http://ca3.php.net/manual/en/ini.php#ini.list :

output_buffering
output_handler
session.auto_start

Ok, so am I the one doing something naughty?

Posted: Mon Feb 19, 2007 12:13 am
by speedmonk
I too have a template that includes a session start on each page.

But I DON"T have the flushing object do-hickey in my footer.

Will my server melt?

Re: Ok, so am I the one doing something naughty?

Posted: Mon Feb 19, 2007 12:25 am
by Kieran Huggins
speedmonk wrote:Will my server melt?
Sadly, yes :(

Posted: Mon Feb 19, 2007 1:59 am
by RobertGonzalez
I have made session enabled apps that call session_start() on each page. I have never used output buffering and I still see no reason to.

Posted: Mon Feb 19, 2007 6:39 am
by seodevhead
Output buffering is only necessary if you use any header() calls within your script, correct? I use header responses within PHP quite frequently, mostly for 301 redirects and to serve up 404's when users submit wrong parameters in the URL (purely for search engine reasons).

Posted: Mon Feb 19, 2007 6:54 am
by onion2k
seodevhead wrote:Output buffering is only necessary if you use any header() calls within your script, correct? I use header responses within PHP quite frequently, mostly for 301 redirects and to serve up 404's when users submit wrong parameters in the URL (purely for search engine reasons).
Actually I would say that if you're using out buffering because you're trying to add headers after sending something to the user then your code isn't very logically structured. You should have done all the requisite checks to see if you want to bounce the user somewhere else or change the content type or something before you've started doing anything with HTML.

There are other reasons to use it though. For example, if you want to save some output rather than using fputs() with a file handle you can start the output buffering and save the content at the end. You can also do things like replacing content using a regular expression once the page is generated ... handy if you you need a quick hack to change the output of a number of different functions.

It's never the best solution to any problem, but it can get you out of a bind if you're in a hurry.

Posted: Mon Feb 19, 2007 6:59 am
by Jenk
Everah wrote:I have made session enabled apps that call session_start() on each page. I have never used output buffering and I still see no reason to.
Following a somewhat heated discussion on a different forum, "stress tests" proved that using the OB reduces server load and response times. (!)

Negligible difference, but the key to it I guess is that the php engine doesn't need to break out of processing to output until ob_end_flush() or ob_get_contents() is called.

Posted: Mon Feb 19, 2007 8:54 am
by jmut
Kieran Huggins wrote:>
session.auto_start
I think this one should not be relied on. If I remember correctly there were some problems with IE or something.

Posted: Mon Feb 19, 2007 9:36 am
by RobertGonzalez
onion2k wrote:
seodevhead wrote:Output buffering is only necessary if you use any header() calls within your script, correct? I use header responses within PHP quite frequently, mostly for 301 redirects and to serve up 404's when users submit wrong parameters in the URL (purely for search engine reasons).
Actually I would say that if you're using out buffering because you're trying to add headers after sending something to the user then your code isn't very logically structured. You should have done all the requisite checks to see if you want to bounce the user somewhere else or change the content type or something before you've started doing anything with HTML.
++. Often times developers use output buffering as a bandaid to illogical code flow, in that they cannot start a session, set a cookie or use header() because headers have already been sent. The fact is, it is pretty easy to handle all processing of the application and literally output/parse the HTML at the very last step of the script.

Output buffering does have a place (why else would it be in PHP?). I should probably have qualified my earlier statement a bit by saying that outside the scope of the need to buffer output, there is no need to use it. Especially as a crutch to allow bad coding practice. Just my $0.02.

Posted: Mon Feb 19, 2007 9:43 am
by Kieran Huggins
really? does it do any more or less that just calling session_start() in the header?

Posted: Mon Feb 19, 2007 11:57 am
by jmut
Kieran Huggins wrote:really? does it do any more or less that just calling session_start() in the header?
well, it should be. Seems it is buggy somehow.
Recently a friend of mine had a problem with it. All worked smooth with FF but not with IE. He disabled it, made session_start() within the script
not relying on this php.ini setting and it went smoothly.

Weird, never really tried to figure out why this is so and what might cause it. Just know, that I would rather not use it.

Posted: Mon Feb 19, 2007 12:29 pm
by Kieran Huggins
8O good to know! Thanks!