Kunena 5.2 Beta 1 Released (24 Sep 2020)

The Kunena team is thrilled to announce the first public beta release of Kunena 5.2, a native Joomla extension for Joomla 3.9. This is a development release and should be only be used for testing; this version is not recommended for live websites at this stage.

The purpose of this release is to encourage testing by downloading, installing and identifying any problems or shortcomings that people may discover. K 5.2.0 B1 is stable and we are aware that people will discover defects. We encourage you to use the forum to report defects, as soon as they are discovered, so that the development team can work through the problems before the release of K 5.1 as a stable product. Reporting defects does not mean that the problems can or will be fixed. The Kunena team is looking forward to hearing your feedback on how well we have achieved our design goals.

× This is for users to help other users, to discuss topics that are related to forum administration in general or problems in running Joomla. This is not the place to ask for Joomla support. If you want assistance with Joomla please ask at forum.joomla.org

Question performance: slow posting on hosting service

10 years 1 month ago #1 by cbrace
Hi all,

One of the improvements mentioned for 1.6 was performance. I noticed it right away in posting speed, both here and on my desktop testing environment.

However, on my host server, on which I have also installed 1.6. for testing purposes (closed test among five or six people), both me and my users are seeing very long posting times, sometimes upwards of 20 seconds to post a message.

I can't really complain to the hosting service support unless I have some kind of very specific request. The question is: how would one determine where the bottleneck is and how would one go about fixing it? Any ideas?

In general performance on this host server seems acceptable (measured subjectively), only Kunena posting speeds are slow.

FWIW: At the moment Joomla caching is disabled on this site.

Thanks for any ideas,


Please Log in or Create an account to join the conversation.

10 years 1 month ago #2 by snilloconator
Who is your host....? Reason I ask is I have been having issues the last few days and my host is having problems coming out of Dallas.

Please Log in or Create an account to join the conversation.

10 years 1 month ago - 10 years 1 month ago #3 by LittleJohn

Since its working in a closed enviroment, it should work in production too.
You didnt mention any statistics (users, pageviews, postings, etc).
What are these?

Also, Im thinking about what more is happening in Kunena & Joomla on post?

Maybe Kunena sends an email to a subscription and the mailrelay is slow?
Maybe there is some dns lookup which is slow? (i dont think there is lookups though Edit: maybe spamfilters doing external checking http checking)

Can you somehow turn emails off? If it cant be done globally, you'd have to remove all the fun features like moderators/complaints/subscriptions/etc.
Last edit: 10 years 1 month ago by LittleJohn.
The following user(s) said Thank You: cbrace

Please Log in or Create an account to join the conversation.

10 years 1 month ago #4 by cbrace
Thanks to your comments, I think I have found the bottleneck.

For some reason, PHP mailer function isn't working properly on my webhost server, so I am using SMTP under Joomla's global configuration.

If I switch to the PHP mailer, the submit time on the Kunena noticeably improves, but the notification messages don't get delivered. :( :( :(

I am no expert in these matters, but it would appear that the PHP mailer serves to buffer outgoing mail, so the response improves. At the same time, I suspect smtp server is has some performance issues; maybe they are running Spamassassin and/or Clam AV, or some other Perl spam/virus software, which tend to be CPU intensive, and/or doing DNS lookups. On my desktop test system, I am also using a local smtp server, but the response is very fast, partly because it simply serves as a relay to Postfix running on my LAN gateway machine.

So, from what I understand from your reply, when a user posts a reply, the generation and sending of subscription notifications takes place within the posting process. Just curious: is there additional overhead associated with additional subscribers? IOW, the more subscribers, the longer it takes? Currently our test forum has five or six subscribers for various categories, but in due time when we introduce our Kunena forum to a larger group, this could easily be several hundred.

I will ask my webhost support about smtp performance and the PHP mailer issue.


Please Log in or Create an account to join the conversation.

10 years 1 month ago #5 by LittleJohn
It sounds like you nailed it.

In my oppinion smtp is the prefered way since they are delivered fast and the php scripts can get on with other things.

Subscriptions have not been a problem for Kunena so far. Even kunena.com here has really many subscription, but runs smooth at one server.
However, an regular email queue for all outbound email have been proposed for the next version, so this might solve the potential problems once and for all.
The following user(s) said Thank You: cbrace

Please Log in or Create an account to join the conversation.

10 years 1 month ago #6 by cbrace
I am quite sure now it is the host's smtp that is causing the problem.

If I send a mail to myself using a mailing form, it takes around twelve seconds for the form to be processed. When I do this on my local machine (my Joomla test installation, also configured for smtp), the processing time is around a second.

Obviously there is more latency with the remote host than with the local desktop, but difference isn't that great. I am also not talking about time to refresh the screen; just the time the POST or whatever takes to be accepted.

I'll ask the webhosting support about this tomorrow.

Please Log in or Create an account to join the conversation.

  • Not Allowed: to create new topic.
  • Not Allowed: to reply.
  • Not Allowed: to edit your message.
Time to create page: 0.100 seconds