Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #6944 > unrolled thread

database-based sessions for 3rd party php app

Back to article view | Back to comp.lang.php

Contents

  database-based sessions for 3rd party php app Axel <axel.bock.ba@gmail.com> - 2012-09-05 04:21 -0700
    Re: database-based sessions for 3rd party php app The Natural Philosopher <tnp@invalid.invalid> - 2012-09-05 12:37 +0100
      Re: database-based sessions for 3rd party php app Axel <axel.bock.ba@gmail.com> - 2012-09-05 04:58 -0700
        Re: database-based sessions for 3rd party php app The Natural Philosopher <tnp@invalid.invalid> - 2012-09-05 13:45 +0100
      Re: database-based sessions for 3rd party php app Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-09-05 14:26 +0200
        Re: database-based sessions for 3rd party php app The Natural Philosopher <tnp@invalid.invalid> - 2012-09-05 13:46 +0100
        Re: database-based sessions for 3rd party php app The Natural Philosopher <tnp@invalid.invalid> - 2012-09-05 14:01 +0100
    Re: database-based sessions for 3rd party php app Jerry Stuckle <jstucklex@attglobal.net> - 2012-09-05 08:11 -0400
      Re: database-based sessions for 3rd party php app Axel <axel.bock.ba@gmail.com> - 2012-09-05 05:39 -0700
        Re: database-based sessions for 3rd party php app The Natural Philosopher <tnp@invalid.invalid> - 2012-09-05 13:51 +0100
          Re: database-based sessions for 3rd party php app Axel <axel.bock.ba@gmail.com> - 2012-09-05 06:13 -0700
          Re: database-based sessions for 3rd party php app "Peter H. Coffin" <hellsop@ninehells.com> - 2012-09-05 10:21 -0500
        Re: database-based sessions for 3rd party php app Jerry Stuckle <jstucklex@attglobal.net> - 2012-09-05 10:21 -0400
    Re: database-based sessions for 3rd party php app Jonathan Stein <jstein@image.dk> - 2012-09-05 22:27 +0200

#6944 — database-based sessions for 3rd party php app

Hi readers, 

I am currently trying to increase the performance of a 3rd party learning platform web app we are (still) using. The current setup is to store the PHP sessions on an NFS share, which I personally find not-so-good.

Now I don't want to touch the code of this app, for various reasons. 

But I want database sessions. 

Is there a good, proven and solid way to move the session management to the database _without_ modyfying the app's code?


Grateful for any tips, thanks in advance & greetings, 
Axel.

[toc] | [next] | [standalone]

#6945

Axel wrote:
> Hi readers, 
> 
> I am currently trying to increase the performance of a 3rd party learning platform web app we are (still) using. The current setup is to store the PHP sessions on an NFS share, which I personally find not-so-good.
> 
> Now I don't want to touch the code of this app, for various reasons. 
> 
> But I want database sessions. 
> 
> Is there a good, proven and solid way to move the session management to the database _without_ modyfying the app's code?
> 
> 

How could there be?

In order to write something into a *database* in preference to a file or 
directory, requires application level changes. Or an entire rewrite of 
part of PHP.



> Grateful for any tips, thanks in advance & greetings, 
> Axel.


-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to 
lead are elected by the least capable of producing, and where the 
members of society least likely to sustain themselves or succeed, are 
rewarded with goods and services paid for by the confiscated wealth of a 
diminishing number of producers.

[toc] | [prev] | [next] | [standalone]

#6946

Am Mittwoch, 5. September 2012 13:37:37 UTC+2 schrieb The Natural Philosopher:
> > Is there a good, proven and solid way to move the session management to the database _without_ modyfying the app's code?
> 
> How could there be?
> 

Well. The usual way seems to be to call session_set_save_handler(...).

My hope was there was some kind of "hook" I could use to inject that before the app's PHP stuff gets executed, and to configure this in the php.ini or so.

That's how this could be. But isn't, I get it.

[toc] | [prev] | [next] | [standalone]

#6950

Axel wrote:
> Am Mittwoch, 5. September 2012 13:37:37 UTC+2 schrieb The Natural Philosopher:
>>> Is there a good, proven and solid way to move the session management to the database _without_ modyfying the app's code?
>> How could there be?
>>
> 
> Well. The usual way seems to be to call session_set_save_handler(...).

For you maybe.

I simply took one look at sessions and rolled my own interface to mysql 
and cookies..

> 
> My hope was there was some kind of "hook" I could use to inject that before the app's PHP stuff gets executed, and to configure this in the php.ini or so.
> 
> That's how this could be. But isn't, I get it.

I don't think so. the session_set_handler class is too complex really to 
be expressed in an config file alone.



-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to 
lead are elected by the least capable of producing, and where the 
members of society least likely to sustain themselves or succeed, are 
rewarded with goods and services paid for by the confiscated wealth of a 
diminishing number of producers.

[toc] | [prev] | [next] | [standalone]

#6948

On 9/5/2012 1:37 PM, The Natural Philosopher wrote:
> Axel wrote:
>> Hi readers,
>> I am currently trying to increase the performance of a 3rd party
>> learning platform web app we are (still) using. The current setup is
>> to store the PHP sessions on an NFS share, which I personally find
>> not-so-good.
>>
>> Now I don't want to touch the code of this app, for various reasons.
>> But I want database sessions.
>> Is there a good, proven and solid way to move the session management
>> to the database _without_ modyfying the app's code?
>>
>>
>
> How could there be?
>
> In order to write something into a *database* in preference to a file or
> directory, requires application level changes. Or an entire rewrite of
> part of PHP.
>
>


No, not in this case, TNP, at least it won't be anything rigorous.
Session handling can be changed for an existing application without 
breaking it.

You have to do the following:
1) Change for this application the session storage
session_set_save_handler will take care of that.

The easiest way to do this is by adding a file of yourself somewhere 
where you define the settings and call session_set_save_handler.
Maybe the existing application has a file that is included everywhere 
(which is very common), then simply add you file to it (via another 
include, use full path to your session-definition-file to avoid 
complexities with include from other directories)

2) Write the appropriate functions you name in the above function

3) Of course, add a table to the database for storage.

There are a few examples on the net to be found to do this.

If memory serves me well, adodb abstraction layer has one ready-to-go 
build in.

 From the application point-of-view, there will be no change.

Good luck,
Erwin Moller

-- 
"That which can be asserted without evidence, can be dismissed without 
evidence."
-- Christopher Hitchens

[toc] | [prev] | [next] | [standalone]

#6951

Erwin Moller wrote:
> On 9/5/2012 1:37 PM, The Natural Philosopher wrote:
>> Axel wrote:
>>> Hi readers,
>>> I am currently trying to increase the performance of a 3rd party
>>> learning platform web app we are (still) using. The current setup is
>>> to store the PHP sessions on an NFS share, which I personally find
>>> not-so-good.
>>>
>>> Now I don't want to touch the code of this app, for various reasons.
>>> But I want database sessions.
>>> Is there a good, proven and solid way to move the session management
>>> to the database _without_ modyfying the app's code?
>>>
>>>
>>
>> How could there be?
>>
>> In order to write something into a *database* in preference to a file or
>> directory, requires application level changes. Or an entire rewrite of
>> part of PHP.
>>
>>
> 
> 
> No, not in this case, TNP, at least it won't be anything rigorous.
> Session handling can be changed for an existing application without 
> breaking it.
> 
> You have to do the following:
> 1) Change for this application the session storage
> session_set_save_handler will take care of that.

that's an application change Erwin.

> 
> The easiest way to do this is by adding a file of yourself somewhere 
> where you define the settings and call session_set_save_handler.
> Maybe the existing application has a file that is included everywhere 
> (which is very common), then simply add you file to it (via another 
> include, use full path to your session-definition-file to avoid 
> complexities with include from other directories)
> 
> 2) Write the appropriate functions you name in the above function
> 
> 3) Of course, add a table to the database for storage.
> 
> There are a few examples on the net to be found to do this.
> 
> If memory serves me well, adodb abstraction layer has one ready-to-go 
> build in.
> 
>  From the application point-of-view, there will be no change.
> 
> Good luck,
> Erwin Moller
> 


-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to 
lead are elected by the least capable of producing, and where the 
members of society least likely to sustain themselves or succeed, are 
rewarded with goods and services paid for by the confiscated wealth of a 
diminishing number of producers.

[toc] | [prev] | [next] | [standalone]

#6953

Axel wrote:
> Am Mittwoch, 5. September 2012 14:27:03 UTC+2 schrieb Erwin Moller:
>> On 9/5/2012 1:37 PM, The Natural Philosopher wrote:
> 
>> You have to do the following:
> 
>> The easiest way to do this is by adding a file of yourself
>> somewhere where you define the settings and call
>> session_set_save_handler. Maybe the existing application has a file
>> that is included everywhere (which is very common), then simply add
>> you file to it (via another include, use full path to your
>> session-definition-file to avoid complexities with include from
>> other directories)
> 
> That would be a perfect solution, IF I didn't have to modify a file
> of the app (even if only one). One reason is development is done
> elsewhere, and if we use self-applied modifications ... well, you
> probably know the dance ("not our fault, not a vanilla install, but
> cannot be reproduced, has to do with your mods, we need more hours to
> debug, ....."). Yes, they would do that ;)
> 

Arguably the fault lies with their app which should have used a database 
to start with.

You can of course do the simpler thing  and use the php.ini file setting 
to move the sessions off NFS into local storage.

Its not possible to say whether that will improve speed however. A lot 
depends on how the NFS is set up and the speed and congestion of the LAN 
over which it runs.



> 
> Thanks for your help! Axel.


-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to
lead are elected by the least capable of producing, and where the
members of society least likely to sustain themselves or succeed, are
rewarded with goods and services paid for by the confiscated wealth of a
diminishing number of producers.

[toc] | [prev] | [next] | [standalone]

#6947

On 9/5/2012 7:21 AM, Axel wrote:
> Hi readers,
>
> I am currently trying to increase the performance of a 3rd party learning platform web app we are (still) using. The current setup is to store the PHP sessions on an NFS share, which I personally find not-so-good.
>
> Now I don't want to touch the code of this app, for various reasons.
>
> But I want database sessions.
>
> Is there a good, proven and solid way to move the session management to the database _without_ modyfying the app's code?
>
>
> Grateful for any tips, thanks in advance & greetings,
> Axel.
>

You can set session.save_handler in the php.ini file to point at a 
different handler.  Define your handler and write the data to the 
database.  Instructions are in the PHP doc.

Alternatively, you can also set an auto prepend file to include your 
session handler code in every file.

However, are you sure this will help performance?  Why do you think your 
current session handling is causing performance problems?  Not that I 
like using NFS shares, but they're typically faster than remote databases.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#6949

Am Mittwoch, 5. September 2012 14:11:11 UTC+2 schrieb Jerry Stuckle:

> You can set session.save_handler in the php.ini file to point at a 
> different handler.  Define your handler and write the data to the 
> database.  Instructions are in the PHP doc.

really? I found just a bunch of stuff describing the general principle. I'll have another look, thanks.

> Alternatively, you can also set an auto prepend file to include your 
> session handler code in every file.

ah! That's kind of what I had in mind :) . I didn't know that - I'm not a php developer.

> However, are you sure this will help performance?  Why do you think your 
> current session handling is causing performance problems?  Not that I 
> like using NFS shares, but they're typically faster than remote databases.

Hm. That's a good question. _Right Now_ we have 57000 active sessions, and a "dir" on the directory with them takes 20+ seconds. Also the NFS serves most of our content, so bottom line - I have no clue, but I think this might improve performance - which is kind of neccessary. So basically I wanted to change and have a look. 


thanks for your help!
Axel.

[toc] | [prev] | [next] | [standalone]

#6952

Axel wrote:
> Am Mittwoch, 5. September 2012 14:11:11 UTC+2 schrieb Jerry Stuckle:
> 
>> You can set session.save_handler in the php.ini file to point at a 
>> different handler.  Define your handler and write the data to the 
>> database.  Instructions are in the PHP doc.
> 
> really? I found just a bunch of stuff describing the general principle. I'll have another look, thanks.
> 

Remember you still have to write the handler and make sure its included 
in your app.

>> Alternatively, you can also set an auto prepend file to include your 
>> session handler code in every file.
> 
> ah! That's kind of what I had in mind :) . I didn't know that - I'm not a php developer.
> 
That has some performance downsides on scripts that dont need it.

>> However, are you sure this will help performance?  Why do you think your 
>> current session handling is causing performance problems?  Not that I 
>> like using NFS shares, but they're typically faster than remote databases.
> 
> Hm. That's a good question. _Right Now_ we have 57000 active sessions, and a "dir" on the directory with them takes 20+ seconds. Also the NFS serves most of our content, so bottom line - I have no clue, but I think this might improve performance - which is kind of neccessary. So basically I wanted to change and have a look. 
> 
Hmm. yes. at that level a database with appropriate indexing should be 
faster than a file system

> 
> thanks for your help!
> Axel.
> 
> 


-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to 
lead are elected by the least capable of producing, and where the 
members of society least likely to sustain themselves or succeed, are 
rewarded with goods and services paid for by the confiscated wealth of a 
diminishing number of producers.

[toc] | [prev] | [next] | [standalone]

#6954

Am Mittwoch, 5. September 2012 14:51:15 UTC+2 schrieb The Natural Philosopher:

> Remember you still have to write the handler and make sure its included 
> in your app.

eeh, of course. the critical point is how to inject that handler without touching the application's files.

Although I still haven't found a usable example (still not a php dev, me here).


> Arguably the fault lies with their app which should have used a 
> database to start with. 

well, life's a b*tch :) 


Thanks,
Axel.

[toc] | [prev] | [next] | [standalone]

#6956

On Wed, 05 Sep 2012 13:51:14 +0100, The Natural Philosopher wrote:

> Axel wrote:
>
>> Am Mittwoch, 5. September 2012 14:11:11 UTC+2 schrieb Jerry Stuckle:
>>
>>> You can set session.save_handler in the php.ini file to point at a
>>> different handler. Define your handler and write the data to the
>>> database. Instructions are in the PHP doc.
>>
>> really? I found just a bunch of stuff describing the general
>> principle. I'll have another look, thanks.
>
>
> Remember you still have to write the handler and make sure its
> included in your app.

Defining the handler in php.ini takes care of the "make sure it's
included in your app" part.

>
>>> Alternatively, you can also set an auto prepend file to include your
>>> session handler code in every file.
>>
>> ah! That's kind of what I had in mind :) . I didn't know that - I'm
>> not a php developer.
>
> That has some performance downsides on scripts that dont need it.

Yup. Which points back to custom handler set in php.ini.

-- 
Because of the diverse conditions of humans, it happens that some acts 
are virtuous to some people, as appropriate and suitable to them, while 
the same acts are immoral for others, as inappropriate to them.
			    -- Saint Thomas Aquinas

[toc] | [prev] | [next] | [standalone]

#6955

On 9/5/2012 8:39 AM, Axel wrote:
> Am Mittwoch, 5. September 2012 14:11:11 UTC+2 schrieb Jerry Stuckle:
>
>> You can set session.save_handler in the php.ini file to point at a
>> different handler.  Define your handler and write the data to the
>> database.  Instructions are in the PHP doc.
>
> really? I found just a bunch of stuff describing the general principle. I'll have another look, thanks.
>
>> Alternatively, you can also set an auto prepend file to include your
>> session handler code in every file.
>
> ah! That's kind of what I had in mind :) . I didn't know that - I'm not a php developer.
>
>> However, are you sure this will help performance?  Why do you think your
>> current session handling is causing performance problems?  Not that I
>> like using NFS shares, but they're typically faster than remote databases.
>
> Hm. That's a good question. _Right Now_ we have 57000 active sessions, and a "dir" on the directory with them takes 20+ seconds. Also the NFS serves most of our content, so bottom line - I have no clue, but I think this might improve performance - which is kind of neccessary. So basically I wanted to change and have a look.
>
>
> thanks for your help!
> Axel.
>
>

The other question is - why do you have 57K sessions?  What's your 
session expiration time?  Too long, maybe?

Or is your garbage collection set too low so it's not cleaning up 
expired sessions?

57K concurrent sessions would be a *very busy* website - probably tens 
of millions of hits per day.

But if they are valid, then using a database *might* speed things up. 
But remember - most of the time spent with the dir will be in 
transferring the entire directory listing over the network and 
displaying it - neither of which needs to be done by a session handler.

The real test would be how long it takes to open a session file in the code.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#6957

On 05-09-2012 13:21, Axel wrote:

> But I want database sessions.

Database sessions could easily be slower than your current solution.

Is it possible to move the session storage to a local disk - or even a 
RAM disk?
If you're lucky, that's both easier and faster.

If you have a distributed setup, where you need a central session 
storage, take a look at Memcache:
http://php.net/manual/en/memcached.sessions.php

   Regards

     Jonathan

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.php

csiph-web