Openfire and CentOS huge performance problems

Openfire
41

Openfire 4.4.3 is out the door now, please try it and report back your findings.

42

Hi!

I’ve tested 4.4.3-1 with LDAP Auth(same ldap server was in April) and 500 bots in jmeter - looks great. All 500 was online under 1 minute.

Group sharing works much faster now, on some groups of 10-20 users instantly, on groups of 100-150 users it was under a minute, but i need to test it a little bit more with more shared groups.

Tested on a fresh CentOS 7 VM with 2 VCPU and 4GB RAM with MariaDB 5.5.64.

I will test this version in production, but I don’t know exactly when I can do it.

Thanks for the release, support and feedback!

4 Likes
43

Thanks for the feedback! Note that things changed (have been optimized) in 4.4.4 - You might want to test using that, instead of 4.4.3!

3 Likes
44

Hi!

I’ll definitely try 4.4.4 version and give the feedback.

Thanks!

45

unbearable

1 Like
46

Hi!

I’ll try to test 4.4.4 this week, last week was very busy.

47

Hi @guus! Sorry for The Suspense.

Tried 4.4.4 with default settings, including caches.

  • 1000 bots with jmeter online under 1 minute, 4.4.3 took 3-5 minutes for 1000 and under 1 minute for 500 bots
  • Big groups(100+ users in each) shared in 5-10 seconds, small(10-20 users) - instantly, 4.4.3 shared big groups for 1-2 minutes(which is very fast already!)
  • Lower ram usage, 400 of 900MB was used (max 1GB is default for java process), 4.4.3 used max
  • Huge drop in database connections, from hundreds of thousands to 6-7K(6-7K after all 1000 bots were online), even less database connections than 4.4.3, on 4.4.3 - 10-12K

All stats while 1000 bots were online.

OS: CentOS 7
CPU: 2 cores
RAM: 4GB
DB: MySQL 8.0/MariaDB 5.5 on same server with openfire
Auth via LDAP. Same ldap server as in April, no changes.

Very impressive release, big improvement over 4.4.3 although 4.4.3 is very good release.

Going to test it with live users and migrate production after.

Thanks a lot!

3 Likes
48

Thanks for the elaborate tests! Happy to see things improved in the field!

1 Like
49

So i’ve migrated to 4.4.4 in production. Performance is good for two days.

I’ve adjusted caches and ram limit for java. With live users load and cache usage were higher.

1100 live users were online in 3-5 minutes after restart with tuned caches, tested multiple times.
Group sharing times with live users a little bit worse, 1-2 min, but it’s very fast comparing to all prev versions.

Current settings.
Java ram limit = 2GB

Mysql:
innodb_buffer_pool_size = 1024M
innodb_buffer_pool_instances = 4

Openfire cache:
group metadata = 10mb
ldap userdn = 100mb - will change to 10mb probably, but occasionaly it can get to 90-100mb in use, especially when all users logging in simultaneously, current usage - 1mb
roster = 400mb - current usage 300mb
vcard = 100mb - will change to 50mb, default size was small, 100mb too big, current usage 10-20mb

Thanks for your work!

1 Like
50

Thanks for sharing this information. Looks like things are under control.

As a side-note: I don’t think that there’s much of a downside to having caches that are ‘to big’. Having them ‘to small’ however can seriously affect performance. I suggest you err on the side of caution.