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 <[email protected]> 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 > [email protected] > https://mail.kde.org/mailman/listinfo/owncloud >
_______________________________________________ Owncloud mailing list [email protected] https://mail.kde.org/mailman/listinfo/owncloud
