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:
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:
Cons:
(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?