[prev in list] [next in list] [prev in thread] [next in thread]
List: owncloud
Subject: Re: [Owncloud] Session Handling
From: Victor Dubiniuk <victor.dubiniuk () gmail ! com>
Date: 2012-10-15 10:46:04
Message-ID: CA+UHsBtP1HNxSi5D4bp4iyzKaJTD8bg_GJ=DyHJxaeT6=EmozQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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@owncloud.com> wrote=
:
> On Saturday, October 13, 2012 01:01:39 PM J=F6rn 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=B4s a myth that session creation is a significant performa=
nce
> > > 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 stra=
ng
> 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 th=
is
> > > 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 plen=
ty
> 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=F6rn
> _______________________________________________
> Owncloud mailing list
> Owncloud@kde.org
> https://mail.kde.org/mailman/listinfo/owncloud
>
[Attachment #5 (text/html)]
<div>Hi,</div><div><br></div><div>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.</div>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.<div> It might cause issues like this one <a \
href="http://bugs.owncloud.org/thebuggenie/owncloud/issues/oc-1459">http://bugs.owncloud.org/the \
buggenie/owncloud/issues/oc-1459</a></div><div><br></div><div>---</div><div>Victor <br> \
<div><br><div class="gmail_quote">On Mon, Oct 15, 2012 at 1:30 PM, Arthur Schiwon <span \
dir="ltr"><<a href="mailto:blizzz@owncloud.com" \
target="_blank">blizzz@owncloud.com</a>></span> wrote:<br><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class="im">On \
Saturday, October 13, 2012 01:01:39 PM Jörn Friedrich Dreyer wrote:<br> > On <a \
href="tel:13.10.2012" value="+13102012">13.10.2012</a> 11:52, Frank Karlitschek wrote:<br> > \
> Hi Arthur,<br> > ><br>
> > first of all. Thanks for looking into performance. This is very important.<br>
><br>
> +1<br>
><br>
> > I think it´s a myth that session creation is a significant performance<br>
> > factor in our case.<br>
</div>In fact, I have seen it using the fast majority of the time using xcache and<br>
kchachgrind, but a) it's quite some time ago and b) i did not investigate<br>
further, might have been some local thing as well.<br>
However, in this case Danimo asked me about it, because they see sessions<br>
created on every request. With a lot of small files or a lot of users it could<br>
make some difference to optimize here.<br>
@Danimo, if you have some data about this, please share :)<br>
<div class="im"><br>
> > I worked on PHP systems with 100.000 times more hits<br>
> > than a normal ownCloud installation without problems in the session<br>
> > management. And a working session is a essential part of a modern web<br>
> > application.<br>
> I very much need a session to cache user information like the home dir<br>
> which I fetch via a custom API.<br>
</div>Georg implemented OC_User::getHome for User Backends, LDAP e.g. is also making<br>
use of it. It does not save the home folder in a session. Either it works<br>
different, or we do have two parallel solutions?<br>
<div class="im"><br>
> I imagine the same would be the case if<br>
> the user hame was resolved via LDAP. You don't want to make an extra<br>
> trip to the API for each request.<br>
</div>A valid point, i think it tried it only with local accounts the other night,<br>
but I am not sure.<br>
<div class="im">> The problem is annoying enough with<br>
> webdav clients that dont send the session id on subsequent requests ...<br>
</div>The ownCloud Client sends the Session Cookie back, but there is some strang<br>
behaviour, ending up in multiple Session Cookies.<br>
@danimo: can you provide details, please?<br>
<div class="im"><br>
> > I would like to see performance measurements that show a performance<br>
> > impact in our case before we change the current behavior. [...] I suggest<br>
> > to do the following:<br>
> ><br>
> > Create a new "PROFILING" switch in config.php similar to \
"DEBUG"<br> > ><br>
> > Add a "ProfilingEvent" call that takes an event ann writes it into a \
local<br> > > profiling logfile together with an event type and a timestamp. Add this<br>
> > ProfilingEvent call to OC_DB and OC_Hook.<br>
> ><br>
> > Then just do a tail -f to the profiling log and do stuff like syncing a<br>
> > folder or mounting an external filesystem. There are things that we have<br>
> > to improve that have a magnitude more impact than a php session.<br>
> I suggest using xdebug and profiling the bottlenecks.<br>
</div>+1<br>
<div class="im"><br>
> Or maybe first<br>
> make a list of suspected bottlenecks and send a request for profiling<br>
> them on the mailing list. Or even better: create a "performance<br>
> analysis" page on <a href="http://owncloud.org" target="_blank">owncloud.org</a><br>
</div>+1 for extending documentation in general<br>
<div class="im"><br>
> and show in "in the public" that we are<br>
> working on performance and how people can help (by profiling owncloud<br>
> with a howto describing cdebug setup and how to read profiling logs, as<br>
> well as common profiling results explained) ...<br>
</div>Some basic setup yes, however for reading the stuff there should be plenty<br>
pages in the web, it's enough to link to them, we don't need to rewrite<br>
everyting.<br>
<div class="im"><br>
> I don't want to open a<br>
> can of worms: a wiki comes to mind. But thats a topic for the dev meeting ;)<br>
</div>Why? Or just to allow people adding it? Then it's on the Agenda, yes.<br>
<br>
Cheers<br>
Arthur<br>
<br>
><br>
> so long<br>
><br>
> Jörn<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
Owncloud mailing list<br>
<a href="mailto:Owncloud@kde.org">Owncloud@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/owncloud" \
target="_blank">https://mail.kde.org/mailman/listinfo/owncloud</a><br> \
</div></div></blockquote></div><br></div></div>
_______________________________________________
Owncloud mailing list
Owncloud@kde.org
https://mail.kde.org/mailman/listinfo/owncloud
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic