I know this question as come up before but I am still stuck. This weekend I upgraded from owncloud 8 to 10. (I did screw up the upgrade so I ended up doing a clean install, re-creating the config, and then using occ to scan the files. Myself and several other people have noticed that the performance has got worse. Logging in as admin seems quick. If I login as myself (which is an LDAP account) the login takes about 15-20 seconds. Browsing and sharing files seems much slower as well and the iphone app is effectively unusable.
In the ldap config, under groups I can click âverify settings and count groupsâ and get a count of the number of ldap groups. The ldap search filter is â(&(|(objectclass=posixGroup))).â For users , if I click âverify settings and count usersâ it shows 0 users found. The ldap search filter is â(objectclass=*).â
âverify settings and count groupsâ and âverify settings and count usersâ functions are both working. I also refined the search paths to specify ou=people,o=mycompany and ou=groups,o=my company instead o=mycompany.
I can share folder with users and also notify users that the folder is available. If I share with a group, members of that group do NOT get access. If I notify the group when sharing a folder, I get a message that e-mail could not be sent to the members of that group - and it does show the group members so it clearly extracting the group list from the group.
@voyager45 Well, I assume youâre right. I did a similar observation when I upgraded from 8 to 9 a few years ago. I didnât measure anything, it just felt significant slower. However, I think nowadays ownCloud is much smarter and does much more interior jobs as 8.x did.
maybe itâs just me but i canât find a relation between the initial posting about âowncloud much slowerâ and the text about some LDAP configuration later?
I am not sure if LDAP is directly related to this issue. It seems a little odd that owncloud LDAP logins did get slower with the upgrade. But LDAP logins are working. There is only one local user (the administrator.) The local administrator account doesnât have many files but it does seem like sharing out files is faster for the local administrator than for LDAP users (even if sharing to LDAP users.)
There seems to be an LDAP caching issue. I copied a 96GB folder to the local admin users, and browsing/sharing seems quite fast.
ldap caching is enabled with default of 600 sec (10 min)
The âocc user:listâ command takes about 1 sec to return 120 users. The âocc group:listâ command waits for about 15 seconds until it returns the list of groups . There are 30 groups.
Packet capture does not see LDAP traffic on âocc user:list.â It does show traffic with âocc group:list.â The ldapsearch takes about 15 seconds to retrieve users or groups which again points to LDAP cache being a factor. I enabled APCu and redis caching but didnât help (although not sure how to verify APCu and redis is working.)
I used the ldapsearch command from the command line. It took about 15 seconds. Which does seem slower than it should be. However the LDAP server has not changed and this was not a problem with Owncloud 8. Which is why I suspect groups are not being cached. Owncloud LDAP caching should allow owncloud to function even if the LDAP server is briefly offline as well as compensate for a slow LDAP server.
On the ldap server itself âldapsearch -vvv -h ldap.mycompany.comâŚâ took about 7 seconds to initialize the connection then 7 seconds to display data. However âldapsearch -vvv -h localhostâŚâ or "ldapsearch -vvv -h ip_address ⌠" was much faster. It looked like the delay was with setting up the connection. The /etc/hosts file did NOT have an entry for the its self. I added âipaddress ldap.mycompany.com ldapâ to /etc/hosts which fixed the ldap search time.
I have noticed that before. For example if you change your hostname and donât add the new hostname to the â/etc/hostsâ file, Iâve had it happen that every sudo command takes ages, and I think that was on Ubuntu.
Not sure why they need to resolve their own hostname in order to run sudo, almost seems like a bug to me.
You should check how the system is resolving the names. Usually, the system should check the local â/etc/hostsâ file first and then the dns or other services.
In any case, it seems the problem isnât caused by ownCloud.