[Owncloud] Session Handling

[Arthur Schiwon]

On Saturday, October 13, 2012 01:01:39 PM Jörn Friedrich Dreyer wrote:
> On 13.10.2012 11:52, Frank Karlitschek wrote:
> > Hi Arthur,
> > 
> > first of all. Thanks for looking into performance. This is very important.
> 
> +1
> 
> > I think it´s a myth that session creation is a significant performance
> > factor in our case. 
In fact,  I have seen it using the fast majority of the time using xcache and 
kchachgrind, but a) it's quite some time ago and b) i did not investigate 
further, might have been some local thing as well.
However, in this case Danimo asked me about it, because they see sessions 
created on every request. With a lot of small files or a lot of users it could 
make some difference to optimize here. 
@Danimo, if you have some data about this, please share :)

> > I worked on PHP systems with 100.000 times more hits
> > than a normal ownCloud installation without problems in the session
> > management. And a working session is a essential part of a modern web
> > application.
> I very much need a session to cache user information like the home dir
> which I fetch via a custom API.
Georg implemented OC_User::getHome for User Backends, LDAP e.g. is also making 
use of it. It does not save the home folder in a session. Either it works 
different, or we do have two parallel solutions?

> I imagine the same would be the case if
> the user hame was resolved via LDAP. You don't want to make an extra
> trip to the API for each request. 
A valid point, i think it tried it only with local accounts the other night, 
but I am not sure.
> The problem is annoying enough with
> webdav clients that dont send the session id on subsequent requests ...
The ownCloud Client sends the Session Cookie back, but there is some strang 
behaviour, ending up in multiple Session Cookies. 
@danimo: can you provide details, please?

> > I would like to see performance measurements that show a performance
> > impact in our case before we change the current behavior. [...] I suggest
> > to do the following:
> > 
> > Create a new "PROFILING" switch in config.php similar to "DEBUG"
> > 
> > Add a "ProfilingEvent" call that takes an event ann writes it into a local
> > profiling logfile together with an event type and a timestamp. Add this
> > ProfilingEvent call to OC_DB and OC_Hook.
> > 
> > Then just do a tail -f to the profiling log and do stuff like syncing a
> > folder or mounting an external filesystem. There are things that we have
> > to improve that have a magnitude more impact than a php session.
> I suggest using xdebug and profiling the bottlenecks. 
+1

> Or maybe first
> make a list of suspected bottlenecks and send a request for profiling
> them on the mailing list. Or even better: create a "performance
> analysis" page on owncloud.org
+1 for extending documentation in general

> and show in "in the public" that we are
> working on performance and how people can help (by profiling owncloud
> with a howto describing cdebug setup and how to read profiling logs, as
> well as common profiling results explained) ...
Some basic setup  yes, however for reading the stuff there should be plenty 
pages in the web, it's enough to link to them, we don't need to rewrite 
everyting. 

> I don't want to open a
> can of worms: a wiki comes to mind. But thats a topic for the dev meeting ;)
Why? Or just to allow people adding it? Then it's on the Agenda, yes.

Cheers
Arthur

> 
> so long
> 
> Jörn