Duplicate Sessions

[niccol]

I know that this has been covered in detail before. However, I am involved in a busy store ( by which I mean tens of thousands of page views and hundreds of sales a day ). On that store we get about one or two duplicate session errors each day. Obviously, there is no problem with the majority of sessions. The store has been running on the current server for over a year.

I am just a bit puzzled about why there are this smattering of duplicate sessions being created.

PHP Version: 5.3.3 (Zend: 2.3.0)

And

Cookie Domain True
Force Cookie Use False
Check SSL Session ID False
Check User Agent False
Check IP Address False
Prevent Spider Sessions True
Recreate Session True
IP to Host Conversion Status true
Use root path for cookie path False
Add period prefix to cookie domain False

Has anybody got any ideas? And if you want any other setting then let me know.

[mc12345678]

I know that this has been covered in detail before. However, I am involved in a busy store ( by which I mean tens of thousands of page views and hundreds of sales a day ). On that store we get about one or two duplicate session errors each day. Obviously, there is no problem with the majority of sessions. The store has been running on the current server for over a year.

I am just a bit puzzled about why there are this smattering of duplicate sessions being created.

PHP Version: 5.3.3 (Zend: 2.3.0)

And

Cookie Domain True
Force Cookie Use False
Check SSL Session ID False
Check User Agent False
Check IP Address False
Prevent Spider Sessions True
Recreate Session True
IP to Host Conversion Status true
Use root path for cookie path False
Add period prefix to cookie domain False

Has anybody got any ideas? And if you want any other setting then let me know.

In includes/configure.php, what is the setting for your cache? Database? Try none... Should go away. Did on mine. Congratulations on the activity of your store.

[RodG]

In includes/configure.php, what is the setting for your cache? Database? Try none... Should go away. Did on mine. Congratulations on the activity of your store.

Setting to 'none' may resolve the problem, but it comes at the cost of reduced performance.

Just thought I'd mention that.

Cheers
RodG

[mc12345678]

Setting to 'none' may resolve the problem, but it comes at the cost of reduced performance.

Just thought I'd mention that.

Cheers
RodG

I was thinking the same, "battled" this for more than a year, I finally changed the setting to none, and though I haven't run much of a thorough system response test, it does seem to respond faster now than it did... :/ if you have any other suggestions of how to deal with the "situation" I'm certainly game. (Ie, just ignore the existence of those errors, change something to match some value, etc...) I think at one time I had changed a timing value in the php.ini file and was able to reduce the periodicity of receiving them, but I also don't know at what cost.

[lat9]

... Has anybody got any ideas? And if you want any other setting then let me know.

No ideas, but the length of the session ID is controlled by two php.ini values: session.hash_function and session.hash_bits_per_character. Posting those values (and your PHP version, which you did) will help to isolate the issue.

[mc12345678]

No ideas, but the length of the session ID is controlled by two php.ini values: session.hash_function and session.hash_bits_per_character. Posting those values (and your PHP version, which you did) will help to isolate the issue.

Php version: 5.3.13
Session.hash_function = 0
Session.hash_bits_per_character = 4
Anything else need to be provided to help isolate the issue?

[lat9]

I don't know if there are additional settings that would help isolate, but my thinking is that if everyone that has experienced this issue would "chime in" with these settings that a pattern might develop.

[mc12345678]

I did notice that the bits_per_character was set at the "default" setting as stated in the notes of the php.ini file instead of the recommended value for production and development versions. That meaning the recommended setting for production/development was 5, while the default was 4.

Also reason I asked about additional information, was if there was any value in knowing the lengthy "code" that is "clashing".

[niccol]

Yes, we do use database caching. I'll try and change that in the next few days and see the result and also try and benchmark the speeds out of interest.

settings are
session.hash_bits_per_character 5 5
session.hash_function 0 0

Personally, I don't think it can be an issue with php session creation. But that is only a gut feeling. It doesn't happen often enough for that. So, then it makes me think that there is a possibility of a browser issue similar to chrome's tendency in the past to submit data twice. But I can't repeat that on any of the browsers that I test on. But maybe on some older version...

I haven't seen this on any other store but maybe the volume on this one is showing something that goes unnoticed on others I have worked on.

:-) wish it was my own store!

[mc12345678]

Yes, we do use database caching. I'll try and change that in the next few days and see the result and also try and benchmark the speeds out of interest.

settings are
session.hash_bits_per_character 5 5
session.hash_function 0 0

Personally, I don't think it can be an issue with php session creation. But that is only a gut feeling. It doesn't happen often enough for that. So, then it makes me think that there is a possibility of a browser issue similar to chrome's tendency in the past to submit data twice. But I can't repeat that on any of the browsers that I test on. But maybe on some older version...

I haven't seen this on any other store but maybe the volume on this one is showing something that goes unnoticed on others I have worked on.

:-) wish it was my own store!

Pairs of numbers? Is that what is really present or was something mistyped when entered here?