- Posts: 18
- Thank you received: 0
Kunena 6.3.0 released
The Kunena team has announce the arrival of Kunena 6.3.0 [K 6.3.0] in stable which is now available for download as a native Joomla extension for J! 4.4.x/5.0.x/5.1.x. This version addresses most of the issues that were discovered in K 6.2 and issues discovered during the last development stages of K 6.3
Topics that are moved into this category are generally considered to be closed. Users may want to add additional information but these topics should not be resurrected in order to discuss new problems or unrelated matters.
Question Kunena 1.5.9 performance
14 years 2 months ago #12
by fxstein
We love stars on the Joomla Extension Directory .
Replied by fxstein on topic Re:Kunena 1.5.9 performance
Hi,
Sorry for my late reply, have been busy working on K1.6
Can you provide some more details on your setup and website? How much traffic are you running?
We are running Kunena 1.5.9 for two significant sites (kunena.com and starvmax.com) on the same single server and we are getting load numbers of 0.2 - 0.5 on a similar system like yours.
If I run a load test like: ab -n 1024 -c 32 www.kunena.com/forum locally from our server, I get about 35 requests per second and the load goes up to about 30 after 5+ min of back to back repeat runs. That is with Joomla caching disabled - so every request builds the full kunena.com Index (Categories) page - the most expensive page in Kunena 1.5.9.
That is the equivalent of about 2.5M page views per day or about 77M per month. That is definitely a big site and about as much as you can get a single server to scale with Kunena 1.5.x.
Kunena 1.6 makes significant improvements with 1/10th of the queries and newly optimized queries. Since SQL is only part of the performance, that should translate to 2-3x faster page creation times. e.g. our current Index page takes about 350ms on Kunena 1.5.x and can be tuned as fast as 140ms on Kunena 1.6
With your configuration you are either running more then 50M page views on a single server like yours, or there is something else that needs to be looked at.
fxstein
Sorry for my late reply, have been busy working on K1.6
Can you provide some more details on your setup and website? How much traffic are you running?
We are running Kunena 1.5.9 for two significant sites (kunena.com and starvmax.com) on the same single server and we are getting load numbers of 0.2 - 0.5 on a similar system like yours.
If I run a load test like: ab -n 1024 -c 32 www.kunena.com/forum locally from our server, I get about 35 requests per second and the load goes up to about 30 after 5+ min of back to back repeat runs. That is with Joomla caching disabled - so every request builds the full kunena.com Index (Categories) page - the most expensive page in Kunena 1.5.9.
That is the equivalent of about 2.5M page views per day or about 77M per month. That is definitely a big site and about as much as you can get a single server to scale with Kunena 1.5.x.
Kunena 1.6 makes significant improvements with 1/10th of the queries and newly optimized queries. Since SQL is only part of the performance, that should translate to 2-3x faster page creation times. e.g. our current Index page takes about 350ms on Kunena 1.5.x and can be tuned as fast as 140ms on Kunena 1.6
With your configuration you are either running more then 50M page views on a single server like yours, or there is something else that needs to be looked at.
fxstein
We love stars on the Joomla Extension Directory .
Please Log in or Create an account to join the conversation.
14 years 2 months ago #13
by fxstein
We love stars on the Joomla Extension Directory .
Replied by fxstein on topic Re:Kunena 1.5.9 performance
FYI
Here is the output of the last run:
This was run in addition to the regular traffic both kunena.com and starvmax.com receive
Here is the output of the last run:
Code:
Finished 1024 requests
Server Software: Apache/2.2.0
Server Hostname: www.kunena.com
Server Port: 80
Document Path: /forum
Document Length: 126574 bytes
Concurrency Level: 32
Time taken for tests: 30.968880 seconds
Complete requests: 1024
Failed requests: 0
Write errors: 0
Total transferred: 130115584 bytes
HTML transferred: 129611776 bytes
Requests per second: 33.07 [#/sec] (mean)
Time per request: 967.777 [ms] (mean)
Time per request: 30.243 [ms] (mean, across all concurrent requests)
Transfer rate: 4103.02 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.1 0 1
Processing: 536 958 191.1 938 1655
Waiting: 516 914 187.2 892 1538
Total: 536 958 191.1 938 1655
Percentage of the requests served within a certain time (ms)
50% 938
66% 1023
75% 1074
80% 1109
90% 1211
95% 1330
98% 1422
99% 1489
100% 1655 (longest request)
This was run in addition to the regular traffic both kunena.com and starvmax.com receive
We love stars on the Joomla Extension Directory .
Please Log in or Create an account to join the conversation.
14 years 2 months ago #16
by octet
Replied by octet on topic Re:Kunena 1.5.9 performance
What is strange as well, memcached seem to have 97% misses and only over 2% hits.\\
Any ideas?
Any ideas?
Please Log in or Create an account to join the conversation.
14 years 2 months ago - 14 years 2 months ago #17
by fxstein
We love stars on the Joomla Extension Directory .
Replied by fxstein on topic Re:Kunena 1.5.9 performance
Thanks for the additional information. As I thought, your forum is way too small to cause this kind of server loads.
I would go back to the basics. You have a whole list of extensions for various things.
We don't use as single one of them. If you are running on a dedicated server with your own mysql instance, there is no need for memcached either. Please disable it for now - your memcached setup certainly has issues by itself.
Also make sure you do NOT run any third party SEF components like sh404SEF on your site. Work with Joomla SEF if at all possible. The caching of sh404SEF on a site with 50,000+ unique urls would cause the same issue. Most 3rd party SEFs wort great on fairly limited sites, but not when combined with a forum that creates thousands and throusands of unique urls (like for every page of every thread.
You just want to make sure the mysql instance is setup correctly. There are a few tools out there that are very helpful.
Here are two we use all the time to check if our mysql settings are optimal:
www.unix.com/web-programming-web-2-0-mas...uning-primer-sh.html
Both tools should show mainly green for all major setting, with the exceptions of certain joins that will not use indexes.
For example: Our long_query_time log setting is at 1 sec (the lowest mysql allows)
Out of the last 66M queries 16 queries exceeded that
Make sure you run the InnoDB storage engine. It is a myth that MyISAM is faster on larger sites, especially if you need concurrent reads an writes.
With InnoDB, set the query cache to 64-128MB to start with and check with the two scripts after a day or two.
Now - there will always be some queries that cannot use a proper index (in K1.5.9) for joins. The number of those should be relatively low. In our case 4k queries out of 66M (6 days since the last mysql restart), only 39 are doing record by record lookup - these are the ones we focus on to eliminate. The majority of our queries in that category are LIKE %searchterm% search queries. It is certainly a limitation of Kunena and most other forums that certain searches are expensive and will bypass all usage of indices. That is why we are working with JXtended to integrate Kunena into Finder 2.0 that builds a true search engine style index of all content.
Next check your php installation. You should be running either apc or eaccelerator (both open source php accelerators). This can drop the php induced load on a sever to 1/3 or even less.
Since your test returns similar results, I am suspecting one of the Joomla plugins/components to be the reason for the issues. That CSS compressor sounds like it could be a CPU hog if it does realtime CSS compression on every page load. Disable as many as you can afford and check the load on the system.
There is a million things that can be wrong. You can only get there by elimination.
PS: Please update your Joomla install - you are running an outdated version with security issues.
I would go back to the basics. You have a whole list of extensions for various things.
We don't use as single one of them. If you are running on a dedicated server with your own mysql instance, there is no need for memcached either. Please disable it for now - your memcached setup certainly has issues by itself.
Also make sure you do NOT run any third party SEF components like sh404SEF on your site. Work with Joomla SEF if at all possible. The caching of sh404SEF on a site with 50,000+ unique urls would cause the same issue. Most 3rd party SEFs wort great on fairly limited sites, but not when combined with a forum that creates thousands and throusands of unique urls (like for every page of every thread.
You just want to make sure the mysql instance is setup correctly. There are a few tools out there that are very helpful.
Here are two we use all the time to check if our mysql settings are optimal:
www.unix.com/web-programming-web-2-0-mas...uning-primer-sh.html
Both tools should show mainly green for all major setting, with the exceptions of certain joins that will not use indexes.
For example: Our long_query_time log setting is at 1 sec (the lowest mysql allows)
Out of the last 66M queries 16 queries exceeded that
Make sure you run the InnoDB storage engine. It is a myth that MyISAM is faster on larger sites, especially if you need concurrent reads an writes.
With InnoDB, set the query cache to 64-128MB to start with and check with the two scripts after a day or two.
Now - there will always be some queries that cannot use a proper index (in K1.5.9) for joins. The number of those should be relatively low. In our case 4k queries out of 66M (6 days since the last mysql restart), only 39 are doing record by record lookup - these are the ones we focus on to eliminate. The majority of our queries in that category are LIKE %searchterm% search queries. It is certainly a limitation of Kunena and most other forums that certain searches are expensive and will bypass all usage of indices. That is why we are working with JXtended to integrate Kunena into Finder 2.0 that builds a true search engine style index of all content.
Next check your php installation. You should be running either apc or eaccelerator (both open source php accelerators). This can drop the php induced load on a sever to 1/3 or even less.
Since your test returns similar results, I am suspecting one of the Joomla plugins/components to be the reason for the issues. That CSS compressor sounds like it could be a CPU hog if it does realtime CSS compression on every page load. Disable as many as you can afford and check the load on the system.
There is a million things that can be wrong. You can only get there by elimination.
PS: Please update your Joomla install - you are running an outdated version with security issues.
We love stars on the Joomla Extension Directory .
Last edit: 14 years 2 months ago by fxstein.
Please Log in or Create an account to join the conversation.
14 years 2 months ago #18
by fxstein
We love stars on the Joomla Extension Directory .
Replied by fxstein on topic Re:Kunena 1.5.9 performance
To be clear:
I would get rid of ALL of these to start with:
Joomla setup:
Cache settings:
Handler: Memcached
Persistent Memory Cache YES
Memory Cache Compression YES
Gzip compression ON.
JRE Query Cached 3.2 installed and active
CSSJSCompress installed and active.
NO memcached
NO JRE Query Cache
NO CSSJSCompress
uninstall all of them. Then make sure your mysql database is setup correctly (see my prior post).
Once you have confirmed that to work, then and only then you can try APC or eAccelerator of PHP
I would get rid of ALL of these to start with:
Joomla setup:
Cache settings:
Handler: Memcached
Persistent Memory Cache YES
Memory Cache Compression YES
Gzip compression ON.
JRE Query Cached 3.2 installed and active
CSSJSCompress installed and active.
NO memcached
NO JRE Query Cache
NO CSSJSCompress
uninstall all of them. Then make sure your mysql database is setup correctly (see my prior post).
Once you have confirmed that to work, then and only then you can try APC or eAccelerator of PHP
We love stars on the Joomla Extension Directory .
Please Log in or Create an account to join the conversation.
14 years 2 months ago - 14 years 2 months ago #20
by fxstein
We love stars on the Joomla Extension Directory .
Replied by fxstein on topic Re:Kunena 1.5.9 performance
Our new mod_security setup is catching some of the settings and blocking the upload attempt. Need to look into that.
As for your settings:
As I tried to say before: Please limit changes. Make a few changes - test - test - test and once you know what it does, go to the next step. Get rid of apc and eaccelerator for now - again this is for later - once the real problem has been fixed in your config. You seem to like throwing everything you can find at a problem. That is not helpful and will make root cause analysis a pain.
As for MySQL settings
You should avoid going overboard on everything but you ignore the important facts. You seem to have 50MB of data and some 8GB of memory thrown at it for caching. Not only a waste - it will slow things down.
I am pretty sure your entire site and traffic could run really fast on a server with 1-2GB of memory. Sometimes having too much of it makes you do wrong things.
1.) Make sure all you joomla and component tables are InnodDB. Pleas confirm this - the locking ratio says otherwise
2.) join_buffer_size = 2M anything more is a huge waste
3.) the number of queries taking more than 5 sec is way out of control. As I said before on a clean Kunena install we are seeing 16 (exceeding 1 sec) out of 66M
4.) Given the amount of MySQL tables and open file it looks like you have a ton of other Joomla extensions installed. How many mysql databases do you have and how many tables are in the joomla database?
Lets start with those 4 - turning other things off is ok but please don't add any new settings or 'things' to your server.
As for your settings:
As I tried to say before: Please limit changes. Make a few changes - test - test - test and once you know what it does, go to the next step. Get rid of apc and eaccelerator for now - again this is for later - once the real problem has been fixed in your config. You seem to like throwing everything you can find at a problem. That is not helpful and will make root cause analysis a pain.
As for MySQL settings
You should avoid going overboard on everything but you ignore the important facts. You seem to have 50MB of data and some 8GB of memory thrown at it for caching. Not only a waste - it will slow things down.
I am pretty sure your entire site and traffic could run really fast on a server with 1-2GB of memory. Sometimes having too much of it makes you do wrong things.
1.) Make sure all you joomla and component tables are InnodDB. Pleas confirm this - the locking ratio says otherwise
2.) join_buffer_size = 2M anything more is a huge waste
3.) the number of queries taking more than 5 sec is way out of control. As I said before on a clean Kunena install we are seeing 16 (exceeding 1 sec) out of 66M
4.) Given the amount of MySQL tables and open file it looks like you have a ton of other Joomla extensions installed. How many mysql databases do you have and how many tables are in the joomla database?
Lets start with those 4 - turning other things off is ok but please don't add any new settings or 'things' to your server.
We love stars on the Joomla Extension Directory .
Last edit: 14 years 2 months ago by fxstein.
Please Log in or Create an account to join the conversation.
Time to create page: 0.642 seconds