[Owncloud] Session Handling

Victor Dubiniuk victor.dubiniuk at gmail.com
Mon Oct 15 10:46:04 UTC 2012


Hi,

In case of the webdav access session is not used hardly so the single
session_start won't have a great influence on the performance.
>From the other hand the webdav clients that are not pass the session id
while syncing. So one will get a new session on each request.
It might cause issues like this one
http://bugs.owncloud.org/thebuggenie/owncloud/issues/oc-1459

---
Victor

On Mon, Oct 15, 2012 at 1:30 PM, Arthur Schiwon <blizzz at owncloud.com> wrote:

> 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
> _______________________________________________
> Owncloud mailing list
> Owncloud at kde.org
> https://mail.kde.org/mailman/listinfo/owncloud
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/owncloud/attachments/20121015/238b8626/attachment.html>


More information about the Owncloud mailing list