One common point of feedback from users on my primary site is that its slow. But the question is, why. Their point of reference is Dolphin. People thought it was slow, but the feedback is they see Una as slower - and not competitive in terms of performance to other community style applications. Google page speed ranking is quite poor. In terms of bottlenecks, I have CPU and network headroom. The primary causes as far as I can tell are the large number of SQL queries. To make sure it was not just my deployment, I ran the same analysis against the Una community server. Results below.
Can we look at starting an initiative to examine how we can improve performance for the stats below?
Comments
Hello @gkuhnert !
Could you please share your Studio->Dashboard->Server Audit area? And please specify what caches did you enable?
G
The screenshot I shared was from your website... so 100% not just my site... But for sake of argument, see below. As per the screenshot, my bet is on the sheer number of sql aueries. It feels like it is inherrently doing a whole lot of stuff thats causing the poor performance.
For the record, GZ compression is on, and local cache options are 100% correct.
Host Tools Requirements PHP: version = 8.3.23 - OK allow_url_fopen = On - OK allow_url_include = Off - OK magic_quotes_gpc = Off - OK memory_limit = 128 MB - OK post_max_size = 64 MB - OK upload_max_filesize = 64 MB - OK register_globals = Off - OK safe_mode = Off - OK disable_functions = exec,system,passthru,proc_open,proc_nice,ini_restore - OK php module: curl = curl - OK php module: gd = gd - OK php module: mbstring = mbstring - OK php module: json = json - OK php module: fileinfo = fileinfo - OK php module: zip = zip - OK php module: openssl = openssl - OK php module: exif = exif - OK MySQL: version = 10.5.27 - OK Web-server: Apache rewrite_module - OK (mod_rewrite is active: request reached PHP (even if 404 status)) OS: Linux 5.14.0-503.16.1.el9_5.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Dec 13 01:47:05 EST 2024 x86_64 Hardware: Hardware requirements can not be determined automatically - manual server audit may be required. Site setup UNA version = 14.0.0 - OK Files and folders permissions - please click here to find out if permissions are correct. ffmpeg - ffmpeg version 4.4-static ffmpeg-url Copyright (c) 2000-2021 the FFmpeg developers built with gcc 8 (Debian 8.3.0-6) configuration: --enable-gpl --enable-version3 --enable-static --disable-debug --disable-ffplay --disable-indev=sndio --disable-outdev=sndio --cc=gcc --enable-fontconfig --enable-frei0r --enable-gnutls --enable-gmp --enable-libgme --enable-gray --enable-libaom --enable-libfribidi --enable-libass --enable-libvmaf --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-librubberband --enable-libsoxr --enable-libspeex --enable-libsrt --enable-libvorbis --enable-libopus --enable-libtheora --enable-libvidstab --enable-libvo-amrwbenc --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libdav1d --enable-libxvid --enable-libzvbi --enable-libzimg libavutil 56. 70.100 / 56. 70.100 libavcodec 58.134.100 / 58.134.100 libavformat 58. 76.100 / 58. 76.100 libavdevice 58. 13.100 / 58. 13.100 libavfilter 7.110.100 / 7.110.100 libswscale 5. 9.100 / 5. 9.100 libswresample 3. 9.100 / 3. 9.100 libpostproc 55. 9.100 / 55. 9.100 Hyper fast Audio and Video encoder usage: ffmpeg [options] [[infile options] -i infile]... {[outfile options] outfile}... Use -h to get full help or, even better, run 'man ffmpeg' if you dont know if output is correct then manual server audit may be required. Mail sending - click here to send test email Cron jobs - no crontab for una if you are unsure if output is correct then manual server audit may be required Last cron jobs execution - 3 Aug 2025 9:56:01 pm Site optimization PHP: PHP accelerator = ZendOPcache - OK PHP setup = fpm-fcgi - OK MySQL: key_buffer_size = 128 MB - OK max_heap_table_size = 16 MB - OK tmp_table_size = 16 MB - OK thread_cache_size = 151 - OK Web-server: User-side caching for static content - click here to check it in Google Page Speed If it is not enabled then please consider implement this optimization, since it improve perceived site speed and save the bandwidth. To apply this optimization you need to have expires_module - OK (Detected Expires or Cache-Control header via HTTP on static asset) Server-side content compression - can be checked manually or in "Page Speed" tool build-in into browser. If it is not enabled then please consider implement this optimization, since it improve perceived site speed and save the bandwidth. To apply this optimization you need to have deflate_module - OK (Detected compression (gzip/deflate) via HTTP headers on static asset) UNA: DB cache = On (Memcached based cache engine) - OK Pages cache = On (Memcached based cache engine) - OK Page blocks cache = On (Memcached based cache engine) - OK Templates Cache = On (Memcached based cache engine) - OK CSS files cache = On - OK JS files cache = On - OK Compression for CSS/JS cache = On - OK Manual Server Audit Some things can not be determined automatically, manual server audit is required to check it. If you dont know how to do it by yourself you can submit Server Audit Request.Thnx for the details. Well, from the provided server audit I may see that the memory_limit param's value is too low. It would be good to have the 512Mb at least.
G
Changed it, and it made exactly 0% improvement. I monitor server logs, and there were no pages getting tripped by the memory_limit value. As said before, the root cause appears to be the sheer volume of SQL queries (and associated data processing). Why do we need literally thousands of queries to render a page? Something inherrently wrong in that part of Una.
G
Back to this question - The stats on the your own domain itself reflect problems. What can be done to make some gains here?
1000's of queries? Why?
Exactly which UNA page were you refering to? Home page? Discussions?
G
Home page: (Discussion feed)
Discussions-home:
3461 sql queries beside everything else! No wonder my cell phone heats up. Haha. Seems impossible to need so many data points.
No doubt the Devs try to reduce unnecessary code at every step. Wonder how other CMS's compare.
Thank you for the reply.
G
I spent 5 minutes to turn on query log and get some real data. To keep the data clean, I blocked all web page access to my server other than from my IP address. I did one single load of the home page on my site. 3199 queries were logged. By eyeballing the data, i saw that many queries were being executed over and over again. For example
SELECT `tmo`.`value` AS `value` FROM `sys_options_mixes2options` AS `tmo` INNER JOIN `sys_options_mixes` AS `tm` ON `tmo`.`mix_id`=`tm`.`id` AND `tm`.`active`='1' WHERE `tmo`.`option`='bx_artificer_default_mix' LIMIT 1This query was executed 136 times for one page load. Is this intentional?
Very interesting findings. Please keep a spotlight on this important matter. Somewhere out there, the answer is apparent to someone. SQL has been around for quite a while.
While we are on this steady course toward a more perfect platform, it would be nice to get rid of the dark mode for code. It is completely illegible on my screen. We already know that it is code because of it's boxed format.
Hello,
Possibly your notification settings are pulling from way back in time.
Here is my own results.
Go to Studio Notifications and set everything like this:
Notification lifetime is very important make it 2 days only.
G
If you go back to my earlier comment, UNA is doing a query of a parameter value 136 times. The same identical query looking for "bx_artificer_default_mix" ... As for notifications, the table is indexed and would only be one query (regardless of how many days), so I would not expect that to have any significant impact.
G
Actually, let me add one more thought on your comment. Even your data shows 1319 queries. Why so many? Are there opportunities to improve at that layer? Still sounds like a lot!
there are: you may reduce the modules that you use in the page and for the modules that show several results you may adjust them to get balanced results, for instance timeline to show 10 posts each time the page is scrolled or posts module to show 4-5 latest posts each time. these will lighten the query and computation load accordingly.But applying the notification settings trick will create the most effective result for page speed.
PS: my recommendations here are for getting the optimum result from the current UNA code base. To do changes to it is a discussion with the developers.
I think there is something more to notice in my sample. the loading time is less then half second, so there must be something else to steal time isnt it :)
Thank you for sharing Profiler screenshot.
As I can see longest part is in Pages Blocks row, please try to expand "Pages Block" row to see what is the exact block which cause the most delay.
Also MySQL isn't optimized, max_heap_table_size and tmp_table_size have default value of 16M, so custom tune up could help. Also it looks like you are using MariaDB 10.5, it includes a query cache setting, it could help with repetitive queries a lot!
G
MariaDB Tuning complete
The modules table is quite big - too big to include a screenshot... so a ChatGPT summary analysis of the data is below. But before getting tothat, let me share some thoughts on what we have.
This is the Discussions home page. Within the data, we see the popular discussions list That should be a single count by category SQL query, that should be almost zero seconds to render. Instead, almost 2 seconds. Then the full discussions list. While I ahve 1727 posts, the app only displays 12 entries with associated profile icons, and count of replies and topic images. Render of that data if the SQL is well optimised should be very low.
The data here is on the discussions-home .... My home page has similar issues. But it would be good to focus here for now - since its worse...
Modules Breakdown (7.869 sec total)
1. Discussions Module
2. Persons Module
3. Everything Else
Key Observations
G
Yes. There is something to notice. Scale. How many users do you have? What is the magnitude of your content?
As I write this email, I have 66006 accounts and 1727 discussion topics - some with hundreds of replies/comments. At that scale, we already know there are repeated queries being executed. Sure, a query cache can help, but that is not advisable according to the MariaDB developers. They prefer other solutions, and have deprecated the query cache in recent MariaDB versions.
At this scale, the repeated queries are indicitive of code that could be optimised to avoid the external calls for something that could be stored in memory. Additionally, the potential scale issues could be something to explore.
G
Tested small notifications number - Zero difference. Exactly the same, so thats not it.
The number of entries per page? Its already low. 12 per page.
This is an architectural problem that 100% needs developer input. The problem here is that I am operating at scale, with a pretty large data set. Even with reasonable settings, its still slow. I would also argue - if there WAS something wrong with the current settings, that the default "out of the box" values would need tuning to help new users. I have intentionally avoided changing very much to allow elimination of custom setup as a contributing factor
my system has 15K+ users. If your site is new yes notification setting will not effect that much but if it is a few years old with many pooled user activity it will create a big change. also mariadb and UNA 12.1
G
I think I found a clue.
This SQL query is repeated multiple times per page requeat. What is probably causing issues is the fact we've now had 246 records (countries) loaded into memory or a hash - and then we only use one record from that hash to display some country data. But take that a step deeper, we're loading this table multiple times on each page load. Is that once per user that has their icon displayed on the screen? This is the only query that returns more than 12 records (my pagination value for most pages)... and it sticks out as an outlier. Cant this be cached, or at the very least, if we're going to query the table once per user, lets include the country in the query to improve performance?
EDIT: I spoke too soon. Thats only on the homepage. That query does not appear frequently on the discussions-home page request (which is slower). Still a possible optimisation opportunity, but something else causing issues.
tmp tables size can be increased more, depending on your RAM availability.
what is paginate number in discussions ? also some blocks can be loaded asynchronously, especially the blocks which are outside of the initial screen, so the page will load quickly and then some blocks will be loaded after page is loaded, you can set it in page block params - "Asynchronous Mode":
G
One more idea, could you please try to switch to file based cache instead of Memcached ? to see if it makes any difference
G
Hi Alex. Yes, already tried that. I only investigated memcached in an attempt to speed things up. Not a significant improvement, but not really any benefit or gain other than reduced disk IO. But I'll swap back for testing and validate any performance change one way or the other. I am also doubling RAM to eliminate this as well, although I dont expect any change there either. RAM usage is not getting close to the line.
G
No significant difference or improvement memcached versus file cache - other than a little less disk IO of course with memcached.
I tested UNA 14 on a high-performance server equipped with 256 GB of RAM and 36 processors 2 NVMe in raid 1, with only a single user online. The results remained THE SAME. Regardless of the available computing power, UNA 14 is still in development, and until the development team optimizes the script, no significant performance improvements can be expected.
By comparison, UNA 12 operates roughly five times faster, achieving sub 1 second loading times. UNA 14, however, consistently underperforms and appears fundamentally flawed by design.
I also experimented with various caching and optimization solutions, including Memcache, Dragonfly as a front-end, and Redis, but none produced measurable improvements. In practice, it is comparable to trying to tow a Fiat with a Ferrari raw power cannot compensate for an inefficient design.
In addition, UNA 14 contains numerous errors, and the official mobile applications for Android and iOS (GitHub repository) have not been updated in over a year. Until the much-publicized UNA 14.1 with Neo is officially released, I do not expect any meaningful improvements.
Therefore, if you are considering building a project with UNA, the only realistic options are to wait, as the rest of the community is doing, or to use version 12.X,X. However, it is important to note that UNA 12.X,X also has known security vulnerabilities. At this point, the platform offers limited practical use beyond testing or experimenting for learning purposes . Time will ultimately reveal whether future releases can deliver real progress.
A slow-loading site quickly frustrates users and drives them away. Performance is critical no matter how good your content or features are, if pages take too long to load, user retention drops dramatically. Therefore, I do not see any real commercial use for this script right now. It’s only good for kids to play around with.
However, if you have sufficient resources, you should deploy each component separately for example, databases on one server, the messenger service on another, caching on a dedicated server or cluster, and media files stored on a dedicated storage cluster (e.g., Ceph, GlusterFS, or MinIO). Each application can also run on its own cluster, allowing you to scale and optimize every component individually.
To achieve high performance, interconnect the servers or clusters with a high-speed backend network (10–100 Gb/s) and manage the deployment with orchestration platforms such as Docker Swarm or Kubernetes. Splitting each application is essential to optimize performance; installing everything on a single server will inevitably lead to slow performance.
Additionally, implement an Edge CDN for caching to reduce latency and offload traffic from the backend, ensuring faster content delivery to end users.
The problem, however, remains the same: you still need to deliver the same amount of data to the end user. Since the current script is not optimized, these measures alone are insufficient, making the setup largely ineffective for real-world use.
NOTE: This is my personal opinion.
I concur with much. We see extreme slow load times especially on pages with many blocks. However, if you have web design skills, you can optimize the php files to resolve the page loading times. Fortunately the Studio dashboard provides a Google site speed test that identifies for you the coding errors. If you deploy as an off the shelf solution, you will experience these inadequate user load times. We are taking it upon ourselves in September to fix the php code as we are committed to an October beta release.
The users have a limit on data transfer for their gadgets their phones, computers etc. Each page should be built based on the user’s target device. Una is not properly designed for the end user. A new frontend is necessary, but in this case I prefer to build my site from scratch using another framework more quickly. I see no point in fixing myself Una when the UNA team hides updates through their users, Two years ago, they announced NEO, but it’s still not available it’s being sold behind the counter.
Not debating one's preference. Just offering a point of view for those the flaws that you have highlighted that they are correctable if someone has the skills. Another reason for slow load times is the number of objects a page layout calls. On pages with fewer blocks calling fewer objects the pages load relative quickly. On pages with many blocks, calling many objects the load time is slow. A developer with strong skills is capable of reducing the load times considerably by editing and restructuring how UNA loads the pages. For the cost of the license UNA is an incredible value. And their support is mostly excellent, especially @LeonidS My biggest critique is they put the horse in front of the cart by announcing big advancements and then we wait a year or two. A great example outside of NEO is the stories module. They announce it is done and then never deploy. They are not perfect but I am thankful for their product.
G
I dont think this is the root cause. Different devices will have different layout for rendering, but usually the same content. Even on a high capacity endpoint with fast internet, it still struggles. My belief is that v14.x contains inherrent architectural flaws.
I've shown for example already the same query being executed multiple times. The proposed solution was to use query cache as a way of mitigating that problem. But as I pointed out, thats contrary to the advice of the MariaDB dev team. There is absolutely no reason to have thousands of database queries to render a single page.
The total database query time is low, but the number of queries is high. Even if the queries are cached, the application layer is still processing thousands of queries. Thats where the inefficiency lives. All of those loops that are doing repetative redundant queries. No amount of tuning will make up for architectural flaws.
Async block handling helps from a pure "visual" perspective, but it still does not reduce page load time. It just helps get the top bit visible sooner. No real solutions without a bigger architectural review.
@Romulus UNA is big ecosystem, we are making UNA to be scaled, it means that generally it will be slower, but for high load with proper setup it will work better. Old Dolphin isn't scaling good, it means that it looks fast on a single server with several users registered, but to make it scaleable and making it work fast for a lot of users will be difficult.
Latest UNA is already working in some production use cases in a cluster mode.
Also almost any other site (and UNA as well) is usually faster on a single server, when you put all parts apart into different servers, containers, implement load balancers etc, in the result it will be some time overhead, but it will behave better under the higher load than on a single server.
Also we added a lot of advanced features past few years, we'll try to consider to turn off some of the options to make it faster by default (already doing it actually).
Normally you should have server response time around 0.5-1.5 sec, all above isn't normal and need to be addressed. The example is the situation with @gkuhnert site isn't normal, even for big high load site, usually it's much faster.
When is NEO coming out?
G
Hi @Alex T⚜️
Hypothetically, if I did a test with no other users on the platform, would i expect the faster times you indicated? I previously tested by isolating the server using iptables to block all access other than myself, and it was no different.
The other comment i will make is regarding dolphin. My feedback and that of my users is that dolphin was much faster. And i am hearing from others that Una 12 is faster.
Can you comment on both of these observations regarding Una 14?
I think in your case it should be much difference.
Yes, because UNA has more features, but in long term UNA will serve better, Dolphin will have performance degraded with more users and traffic, also Dolphin is not scaling well.
UNA 14 has more features, however it shouldn't be much slower, I will check...
G
I've done this test before. I'll do it again sometime soon when I get some bandwidth... to provide some clear data.
Sorry, I mean:
I think in your case it should NOT be much difference.
G
So, what is the answer? What is the missing ingredient?
If possible, could you please provide access to your UNA and server along with the DB to investigate the problem ?
G
Your team already have an operator login. Were you asking for shell as well? Or just a sql dump? For the purpose of testing, I can build a new server and migrate a copy of the dump over there - so its is totally isolated if that is helpful.
If it will have exactly the same problem with the page loading speed then - yes.