And i do not think it's a apache issue either, when i rsynced photos files to server, then refreshed my owncloud "files" page whole pictures directory 30GB was parsed by apache within couple of minutes.
Their are one other things could be relevant to this. And i know that version 1. Same errors are generated when akonadi owncloud service is configured to sync calendar and contacts with KDE desktop. PS some version facts of applications i'm using: Linux Fedora 17 with kernel 3. My setup: Mbps link between server and pc. No DNS resolution problems 0.
I have noticed a relatively high load on the mysql process on the server. Reports of performance increases when this is done. So it seems this still takes long. Is the add index executed immediately, or should I wait for the index to be built in background and then review the values? How big is your installation? I have been a lot faster than you seem to be, I think - do you have a lot of files or folders in your root ownCloud folder on the desktop?
Any other tables touched when the server is asked for an eTag? MTRichards for etag the filecache table is queried, this has been changed in OC5. The load on apache has dropped significantly due to the caching mechanism.
However, the put files request is still very long, and I assume this can be due to the mysql queries, in which I did not yet check the time needed for a file put.
So I would at least recommend to enable APC, since this already gives a nice performance boost. The remainder seems to be PHP, networking and client overhead, but is at this moment negligible imo.
So my advise for increased owncloud client performance is the following on top of enabling APC :. Indexing reduces the performance of these statements I believe.
I won't have as much time in the coming weeks as I have put in in the last few days, but I'm certainly willing to test updated code or give additional information. Especially since this turned out to be a core problem, and not a client problem. I looked into the core code somewhat, but it takes me way to long to grasp everything since I'm no php expert.
I hope someone of you could bring this to the attention of the core developers. I'm certainly willing to help testing, but I'm not able to make sufficient time to write code myself.
Lieven, thnx for you detailed explanation and your time you have put in this ticket Hopefully devs look in to this soon, it's hard to believe that we are the only ones having problem with this. I really wondering what are experiences of others who try to use owncloud to full extend.
You're not certainly the only one seeing this behavior. On my test case, there is around The last time I tested, it took around 3 full days to synchronize. Although this is far from optimal, I'm more concerned with possible data loss than performance at this point. There still exist some data loss bugs withstanding. After those are solved, people can take care of performance, IMHO. How I like to monitor the harware and see the following when copying a large file.
When copying many small files, I see a big difference. No difference whether Mirall and dolphin. I think it's a problem of remote. In essence it comes down to this: The file upload itself is relatively fast, even on a slower device. However, There is a lot of processing overhead per file. Thus a 1M or a 10M file take about equal time to be processed in a local network. I only did a quick check, but I believe it is due to the underlying sabredav. Again, not the transfer of the file takes time, it is the updating of the file information in the SQL database which takes time.
So it's most likely not sabredav itself, but the way the link is made to update the state information. It does to many requests for identical queries to the database. See my earlier comment including the mysql logfile for a single file upload by a client. Could you create issues with your suggestions in the core repo? And also for the documentation? Try running it without a database of some kind. SQLite is a low performance database backend.
If you want speed, use MySQL. If you have more than one person or sync client using ownCloud at the same time. SQLite is really only good as a data store for a single application which is why the sync client uses it for the journal. You can see the point moscicki makes from the stats I supplied further up this thread. While I was uploading a folder of about small files there was a query rate increase of approximately queries a second.
This lasted for a 6 minute period. That's an average of about queries to upload each file. Now there's folder structure in there to consider too. It had to discover that directories didn't exist, make them and so on. With the network round trip between the web and database servers running at about 0. This has been an area of continuous improvement with each major version.
But it's clear that there still room for more. Also nobody could explain to me what this means: "Beware that it means that the actual IO flush is only done every one second and no more at each commit see [1] , you may lose data so don't use this for critical systems".
What can be lost during this second and can this corrupt my files if mysql has a properly working recovery? Want to add that I set the variable to 2 a month ago and I did not lose any data until now. Better have some good power management in place. Setting it to 2 results in the log being written for every write query but the other write operations happening once a second at most.
There is only a marginal performance improvement between 2 and 1. But 0 doesn't change the results of the test I described above. While there is less disk io on our database nodes, it takes the same time to sync the same folder. This reinforces my opinion that in my case, the time is a function of network latency.
The latency is very, very small in our environment, about as small as you can possibly make it, but there are literally hundreds of queries for each file and it really adds up. No changes here. Also no changes here. The issue should be fixed in ownCloud 9.
Try an update, please. I'm sorry for my too late answer. With an installation of version 9. Problem on downloading large files Server.
When I download a large file, the download stops at 1GB. Any ideas? Thanks a lot for your answers! Regards Dirk. Do you get any error message during the download? I testet with browser and shell. Uploading is easy to fix in a php. Yeah, I saw something on this. I wonder why you are only one having this problem. Hold on I try to find solution quick. I think you will have to add something like this to the owncloud. Then restart apache. Those configs are in these folders. Anyway, I let you mess with that and give us feedback.
If it does not work I try to look at this later. Hah, you beat me. You are on right track. It is apache issue. Good Luck
0コメント