Should dispatcher always start/resume session? #885

Prior to #828, index.php contained:

if(!session_id()) {
    session_start();
}

However, session_start() was always called because session_id() returns a string; even an empty string (""), would mean the conditional evaluated to true.

This isn't necessarily wrong as it either starts or resumes an existing session. In fact, it masks a problem where MySQL is configured with a low limit on concurrent connections. By calling session_start() in index.php, requests associated with the same session are funneled in serial fashion.

See comments:

• http://ca.php.net/manual/en/function.session-start.php#90968
• http://ca.php.net/manual/en/function.session-start.php#31262

Following #828, the session_start() call was removed. We are starting to see reports of "SQLSTATE![ User xxxxxx already has more than 'max_user_connections' active connections" appearing in some dashboard widgets.

Proposed patch:

Index: index.php
===================================================================
--- index.php   (revision 1329)
+++ index.php   (working copy)
@@ -37,6 +37,7 @@
 session_cache_limiter('nocache');
 <a class='mention' href='https://github.com/date_default_timezone_set'>@date_default_timezone_set</a>(date_default_timezone_get());
 require_once PIWIK_INCLUDE_PATH .'/core/Loader.php';
+Zend_Session::start();

 if(!defined('PIWIK_ENABLE_ERROR_HANDLER') || PIWIK_ENABLE_ERROR_HANDLER)
 {

This duplicates the functionality of "session.auto_start=On" (see #881), but is Zend Framework-friendly.

Pros:

• Mitigates the connection limit problem.
• Potentially lowers peak load on the server.

Cons:

• A long-loading widget delays the loading of other widgets. This gives the appearance that the dashboard is taking longer to load.

(In [1339]) fixes #885 - dispatcher starts/resumes session unless PIWIK_ENABLE_SESSION_START=0

vipsoft, if I read the comment on the php site, it says that the session_start is blocking all other http requests trying to load concurrently that are also doing session_start, until the session has been committed.

It sounds to me like this would indeed slow down significantly the dashboard, and is probably not a good thing.

Was it the behavior prior to the session changes (for example in 0.2.x ?)

or is the slowness a regression?

[1339] restores the functionality prior to #828.

#886 will give sites with higher mysql max_connections to set PIWIK_ENABLE_SESSION_START=0 and get parallel requests for potentially faster (certainly more responsive in appearance) dashboard loading.