- Posts: 110
- Thank you received: 3
The Kunena team has announce the arrival of Kunena 6.2.1 [K 6.2.1] which is now available for download as a native Joomla extension for J! 4.3.x/4.4.x/5.0.x. This version addresses most of the issues that were discovered in K 6.1.0 and issues discovered during the last development stages of K 6.1
Question performance: slow posting on hosting service
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,
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.
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.
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.
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.