<div>Handling a session is quite expensive operation for PHP in general. You know it stores the session data in ordinary files. </div><div><br></div><div>As Sam  has written in his letter the problem for the uploaded archives originates from  OC_FileCache post_write hook and definitely related to  cache OC_FileCache::scan. Since there are several operations  involving OC_FilesystemView there any call to OC_FilesystemView::basicOperation   can be responsible fot triggering another post_write hook.</div>
<div><br></div><div>I just would like to stress the great opportunity of increasing general performance for *.tgz and *.bz2 files.</div><div><br></div><div>---</div><div>Victor</div><div><br></div><div>On Wed, Sep 19, 2012 at 10:14 PM, Michael Gapczynski <span dir="ltr"><<a href="mailto:mtgap@owncloud.com" target="_blank">mtgap@owncloud.com</a>></span> wrote:</div>
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I see the long session_start call on there as well. I was investigating this<br>
issue a while back, but I didn't have the experience or knowledge to improve<br>
it. I'm hoping we can take a look at our session handling before ownCloud 5,<br>
because half of page load time is just the basic 'are we logged in?'.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
Michael<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
On Wednesday, September 19, 2012 10:06:12 PM Victor Dubiniuk wrote:<br>
> Hi Sam,<br>
><br>
> the bottleneck of the OC_Archive_TAR is [1]. Caching $headers to a<br>
> protected member of OC_Archive_TAR class reduced CPU load by half while<br>
> browsing tar.gz.<br>
> Here is a call graph for browsing the tar archive [2]. As you see<br>
> tar->listContent() is called twice for eache file in the archive: firstly<br>
> to get the size and secondary to get the mime.<br>
><br>
> [1] <a href="https://github.com/owncloud/core/blob/master/lib/archive/tar.php#L122" target="_blank">https://github.com/owncloud/core/blob/master/lib/archive/tar.php#L122</a><br>
> [2]<br>
> <a href="https://owncube.com/public.php?service=files&token=e2a65ae1442997590c77e6eab" target="_blank">https://owncube.com/public.php?service=files&token=e2a65ae1442997590c77e6eab</a><br>
> 72370cdce41e98d&file=/callgraph2.png<br>
><br>
> Hope will be helpful,<br>
> Victor<br>
><br>
> On Wed, Sep 19, 2012 at 9:08 PM, Sam Tuke <<a href="mailto:samtuke@owncloud.com">samtuke@owncloud.com</a>> wrote:<br>
> > Here's a status update on bug oc-1224 that I've been working on.<br>
> ><br>
> > When files_archive is enabled, and a new archive is added to ownCloud, all<br>
> > subfiles and directories are opened on the server and added to the<br>
> > filecache.<br>
> > This hogs resources to a show-stopping extent.<br>
> ><br>
> > As far as I can see it's not necessary to do this. With gzipped files, if<br>
> > only<br>
> > the archive file itself is read into the cache when it is first uploaded,<br>
> > then<br>
> > you can browse through the archive in the web interface quite happily, as<br>
> > each<br>
> > time you open a subdirectory, the contents of that directory are read into<br>
> > the<br>
> > cache. I have used path regexes to prevent recursive scanning of archives,<br>
> > and<br>
> > this works for gzip files.<br>
> ><br>
> > Zip files however don't work the same way however. Unless the whole<br>
> > archive is<br>
> > scanned into the file cache when it's first added, the archive is not<br>
> > browsable<br>
> > via web interface. I'm not sure why rescans are triggered for gzip<br>
> > archives<br>
> > and not for zip archives.<br>
> ><br>
> > However, even when recursive scanning of gzip archives is prohibited, the<br>
> > resources required to scan even a few files within an archive are<br>
> > impractical.<br>
> > On my dual core machine, a gzip file with only three subfiles (small<br>
> > images) and<br>
> > three subdirectories takes about 30 seconds to scan. Scanning the contents<br>
> > of<br>
> > the top level of any real world web app archive (like tinymce or phplist),<br>
> > which has about ten files / directories in its root folder, takes more<br>
> > than 5<br>
> > minutes.<br>
> ><br>
> > I'm currently trying to identify exactly where the bottleneck is -<br>
> > commenting<br>
> > out all of scanfile() (in filecache.php) doesn't ease things, so the issue<br>
> > must<br>
> > presumably lay somewhere in scan(). I think I need to get xdebug working<br>
> > again<br>
> > to investigate further.<br>
> ><br>
> > That's it from me for this week.<br>
> ><br>
> > Best,<br>
> ><br>
> > Sam.<br>
> > _______________________________________________<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>
_______________________________________________<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>