![]() ![]() ![]() I'd be keen to help testing with the latest client, although testing the main platform may be another matter. Am I getting confused as to the definition of a "Line"? 20 doesn't seem to limit the maximum lines in the log window. (Also, the documentation misses the "owncloud.cfg" filename in the path listed for Mac.) On the Mac client 1.5.4 build 2580, Git revision af0d2d, OCsync 0.91.5, Qt 4.8.4 setting the maxLogLines variable to e.g. Putting it into, say, General won't work. By the way, your OC client documentation doesn't list the section this variable should be in. I suppose I could use bandwidth limiting, but that's a slightly different behaviour. I know the change detection machinery has been revised for the better, so local polling isn't necessary per se, but for clients with complex trees, a limit option might be a handy diagnostic feature. There used to be a localPollInterval variable, which would be handy to have back to limit the other side. I'm basically going to set the Mac ~/Library/Application Support/owncloud/owncloud.cfg remotePollInterval variable to 420000 from its default 30000 to reduce the load. Windows, Linux and, interestingly, iOS iPad clients don't have a problem, but OSX ones do. Adding the ServerName directive with your FQDN solves the problem, but, on my system at least, this can't be done in a default-ssl section, and must be done in /etc/apache2, which often isn't convenient as it's a device-wide setting here. Specifically, the Mac client doesn't seem to walk the certificate path correctly for self-signed certs, so even if host names match cert subject, you get the "Error: SSL handshake failed" error. It might be worth looking into that though as others on the Mirall/issues have pointed to a problem. There is nothing suspicious in the logs (which you're welcome to see if you'd like), except an item for untrusted certificates that is abrogated by a subsequent trusted notification to ignore the previous error this is a self-signed certificate issue, and harmless. Performance is excellent with two or three users. I have the polling frequency reduced to every two hours, hence any latency would be a function of the mysql database.īy meta operations I just mean the number of negotiations for file transfer, rather than the actual up/download file traffic which typically works well. There appear to be quite a lot of queries v/v LDAP, which may be a factor in response time, though Suggest the hardware acceptable for this number of users. What would you recommend as suitable values for these entries? Are there any other directives/factors/policies thatĭeserve inspection? I have reviewed the test cases mentioned at, and would Set worker MPM MaxClients/ThreadsPerChild/ServerLimit to 256/25/16 I have endeavoured to bump up the performance of the underlying system as follows: ![]() A given file transfer performs quiteĪdmirably, but the meta operations in-between are causing delays. ![]() Users suffer under the yoke ofĪpple Mavericks OS X 10.9.2, and both Mirall and webdav perform poorly (using ownCloud Mac OS X Client 1.5.4). Users all have sync clients which poll as default 30 seconds, with a typical cache of ~2GB (large sync jobs are infrequent). 'allow_user_to_change_display_name' => false, 'datadirectory' => '/apps/owncloud/web/data', I am interested in improving OwnCloud performance on a Netgear ReadyNAS RN2120. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |