<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/thebuggenie/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>