I have LDAP Directory as a user source and authentication vault. Working with Web Console I found that every time I’m clicking on “Users/Groups” tab, a lot of time needed to render that page. LDAP Directory trace showing every time that all users are getting by Openfire.
Why Openfire doesn’t store initial request result in something like a Cache? If you have a lot users (in my case it’s about 2K+), that’s very inconvenient to wait when such a request will be finished. Anyway such requests provide high workload for both LDAP and Openfire server.
That’s the everlasting trade-off between getting an accurate view of data, or getting it fast. If I recall correctly, groups are actually already being cached. Users are assumed to be more likely to change often, which is why they are retrieved every time from the back-end storage.
To alleviate the load, the user manager paginates through all users. It should not retrieve all users, but just those that are being displayed on that page. Try and see if the pages load faster when you have less users-per-page (that’s configurable via a drop-down box).
From my experience User object isn’t something so frequently changed to not cache it - at least attributes which are really interested to be used with Openfire (Name, Phone Number etc.)
I’ve checked how much it takes to render Users page in case of default “100 users per page”: almost 6 minutes. That’s too much, isn’t it? I also checked difference between “25 per page” and “100 per page” - up to 10 second vs. 6 minutes (360 seconds, 36 times faster), but bad point here is that I have 111 pages full of users.
Again from my experience User object is the primary point of administration, Group is good (and in case is better than User of course) - so default behaviour (“do not cache”) and “100 per page” is really something which we cannot call convenient.
Even User Search takes a lot of time as Openfire didn’t use ldapsearch filtering but load ALL users from LDAP and only then trying to search something here… I’ve checked that as well by using LDAP trace tool. Later search running faster - but it’s not because of Openfire itself, it’s because my LDAP server cached previous request and provide same amount of information much faster. I also got it from LDAP trace.
Your solution looks like a workaround, this cannot be solution. Solution (in my understanding of course) is to cache User object initially and to sync it later. This is a common way as far as I know for many other products - good point in case if we don’t cache anything about User is that we have all User changes in sync right now, but the bad point here is LDAP server overload (every time you click on Users Openfire getting ALL users from LDAP which provide high load on the LDAP server side) and real inconvenience if you have more than 10 users in LDAP. In some cases such LDAP request flooding might be just a DoS-attack for the server (I’ve seen such cases). So if it is possible - that will be good if Development might think about User data cache and regular sync for it.
Of course that’s another trade-off - but it looks better than one described by you.
I think they page results are cached, as I’m able to retrieve the user list very faster after the initial load. If you look at your cache screen, what does the panel report for your user cache usage?
although it doesn’t directly address your issue, what ldap are you running? Are you connected to ldap using ssl? Do you have connection pooling enabled? If Microsoft AD, have you made any changes to your pagesize? What are you using for your search filters?
I’m in doubt any results are cached here: I see LDAP output in LDAP trace and Guus mentioned before that users are not cached (but groups are). I’m not sure I know openfire well enough to recognize which “cache screen” you’re talking about, could you please tell me how to find it?
Regarding my LDAP: it’s a NetIQ eDirectory server (you probably know it as “Novell eDIrectory”). This connection isn’t secured with SSL as I was too lazy connecting it to sort all this mess with certificate storage (that’s a bad idea, I know that ). Using of SSL cannot be the root cause as SSL add some delays but not of such size (when getting first results taking up to 6 minutes) - even theoretically.
Connection pooling is Enabed by default and I have it Enabled. I’m not using MS AD at all and there is nothing to do with pagesize in eDirectory, default settings good enough (but similar settings exist for eDirectory as well). For my search filter I’m using complex enough thing: as there are a lot of service account of “User” class, I have to filter it out as some OU and CN as well. It looks like damn crazy thing but works - I’m sure because I’ve been testing it in LDAP Browser before applying it to Openfire.
I’m Novell support engineer by myself so believe me I have some expertise and knowledge of LDAP. Problem I’m talking about isn’t LDAP-realted at all: even in your case I’d rather say you have good and fast cache on the LDAP server side, I see nothing cached on the Openfire side (but can’t be sure as my knowledge of Openfire isn’t perfect until now). In my case if I repeat the same request it’s running much faster because of LDAP cache, so I think you have the same.
Regarding hardware - it’s not a problem of hardware as it’s 2 VM’s running on 2xQuad Xeon Server Class CPU with enough amount of memory (4Gb for Openfire and there is nothing except Openfire which isn’t loaded in fact, now it’s just a toy, and 16 Gb for LDAP server - which is more than just enough). No heavy processes running on LDAP server side (which might be root cause of delays).
So all of this is just a question of architecture. If it’s not possible to get any cache for LDAP - I think I’ll go to DB backend and add some LDAP import scripts for DB, that way will be much faster than taking a lot of info from LDAP again and again.
Thanks for your advice. I’ve checked Cache Summary and results looks like nothing for me: for instance, User Cache is 0,5 Mb in size, Percent Used is 0,0% but Effectiveness is 59,1%! What does it means? How these settings was measured and what is the common sense of every parameter?
Regarding “6 min” problem - as I said before, I see all records from LDAP source being downloaded when I click on Users. So I’d rather say User objects are not caching at all. I also checked DB tables and found nothing about user records - there are only records for admin group and that’s all. Probably these tables will be populated later during normal use of the system, will see. So nothing surprising here - as we have JSP as the server backend logic (which is well known as a “resource eater” and “slow going thing”) and thousands of objects (every one needs to be processed by the engine), as a result we have real slow motion process. That’s why I started this topic.