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
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.
G
I've sent you a message to discuss further. Look forward to finding how to improve here.
G
Hi @Alex T⚜️
I have not heard back from ypu in messaging to provide you credentials to login... But as a side topic, I've done other research in terms of improving performance ... I've replaced some hardware (some SSD volumes). Improvement in OS, but no significant impact to Una.
Hello @gkuhnert
There is one message from you in public channel, but there are no messages with access info, could you please PM access info ?
G
Hey Alex.
I had sent you a PM back on 10-September, maybe it was missed. I've followed up today.
Thanks.
The only viable solution would be to distribute tasks across different servers or Docker containers in a swarm cluster, which essentially means modularizing the UNA applications. Although UNA is partly modular, this alone is not enough to accelerate UNA to the level required for a truly professional solution. Not yet.
If NEO weren’t kept behind the scenes, perhaps every community member could contribute with ideas and code. However, even though this has been promised several times over the past two years, it still hasn’t happened or at least, not in any visible way, so that anyone can contribute.
The frontend interface is a vital part of UNA, and I believe the entire community should contribute to this project as an open-source initiative. But if it’s not open-source, I don’t see how that would be possible.
Anything great can only be achieved when the community is united. With limited resources, it’s difficult to build something truly significant and even if something is built, development often moves slower than global technology trends. By the time new features are put into practice, competing technologies may already have advanced so far that what has been built is outdated by the time it reaches the market.
G
Your thoughts are valid, but not always. There is an assumption in there that the load constraint is based on CPU, disk, or memory. If it is an inherrent design flaw, no amount of load sharing will fix the problem.
In my own case, CPU load on the server is negligible during testing with everything else turned off. Memory capacity is not a problem either. That leaves storage bottlenecks. I did actually find a problem there, which I have subsequently fixed, but there are still other architectural problems in the code base that dont get fixed with horizontal scaling.
As a side reference - the storage issue I found was poor write speed performance via a Raid controller. Replaced some drives, and now screaming fast storage.
You're right. What I mean is that building a social network assumes a massive and scalable number of users and content. For UNA to be viable, it must run quickly whether it's handling just a few users on a single cloud server or millions of users across one or multiple server clusters. The modularized applications need to be optimized to ensure performance at any scale.
The real problem, however, is loading time. As I mentioned, it doesn’t matter which server is tested even a single user experiences around five seconds of loading, which is far too long. With a five-second load time, the abandonment rate increases exponentially, starting after just one second. Nowadays, everyone is in a hurry. A site that takes five seconds to load is perceived either as non-functional or as low-quality and people are right.
As an investor, I wouldn’t put money into such a site. I expect to see this script fully functional before I commit. Investments in time, resources, and people are significant, and I have no reason to support a slow site in the age of speed. We’re no longer in the 1990s, when the internet was born and networks were slow. My perception is that UNA has potential, but there is a significant “but.”
It’s like I want to buy a tanker truck for my transport business, but the one being offered is full of holes. I would lose countless potential clients every second because it leaks or moves too slowly it’s exactly the same problem.
G
Yep. We're in agremeent. For my testing as I explained before, I've tested with zero other load on. (Firewall blocked all traffic except for my computer at home). Everything else was unchanged. Load was zero, Disk IO was zero. Network was zero. Even under those ideal conditions, it was performing like a dog. But let me give one more really concrete piece of information. I had migrated from Dolphin. Same data set, same hardware, same everyghing - but it just ground to a halt with Una.
Assuming the only thing that changed was Una, its pretty clear where the problem is. Dont get me wrong, it looks nice and has some nice features, but under the hood needs a little work.
I’m hoping the new NEO application, which was promised to also improve frontend speed, will be released soon. I have a Dolphin site that I’d like to migrate to UNA, but if performance stays this slow, it won’t make sense to move it. I’ll wait to test whether NEO brings real improvements, and then decide.
UNA 15 (packing the first alpha now) will be addressing performance in multiple ways (updated dependencies, optimised queries, improved caching, etc... Some pages up to 3x faster. You can already test on https://ci.una.io/test and more details will be published in the release post.
Wow, this looks amazing! This is the biggest news of the year! It’s almost perfect I’m genuinely impressed this time. It really feels like UNA is finally on the right path to success! This means that UNA has truly become a professional platform with which we can start a real social media business.
G
Looking good. Let me ask. Are there any changes to the database under the hood? If not, I would gladly throw this test code on a private domain name that points to my existing dataset for A/B testing if that is helpful.
Perf improvements:
We also updated all dependencies, extended profiler, added more monitoring tools. So, by the time 15 final is out it'll be even faster.
G
That sounds like a good candidate for an A/B test on a different domain with the same database. I can create a virtual domain for install fairly easily. Happy to assist if this is helpful.
Hello @Andrey Yasko ,
It would be great if you could share a recommended recipe for
mysqld.cnfhttps://github.com/unacms/UNA/blob/master/scripts/docker-compose/mysqld.cnf Is this configuration sufficient, or are additional settings required? How can we best reproduce the same performance results?Is the database server running as a cluster or within Docker? Are the volumes managed by Docker, or are you using OS-managed disks? What filesystem do you recommend for SSDs? Do you use RAID, and if so, is it software or hardware RAID? Are you relying on SAN or another storage architecture? A complete optimization recipe would be incredibly useful.
In addition, it would help to have configuration guidelines not only for MySQL but also for the other components for example, storage of files under the
storagedirectory. Is this running on a separate server and mounted as a network filesystem, or do you recommend a different setup? Ideally, storage should function independently from the main system could you share your preferred solution?Also, is UNA typically deployed in Docker containers, a custom cluster, or Kubernetes? Any guidance or best practices here would be very helpful for the whole community.
Could you also clarify whether UNA currently uses file cache or memcached? I would like to experiment with DragonflyDB and Redis, and I have a working recipe with the Valkey fork using both a Caddy proxy and Nginx reverse proxy. My results have been 100%, 100%, 100%, 100% in Lighthouse across all four categories for my main site: https://www.coozila.com/plus/view-video/coozila-screencast-from-20-06-25
Of course, my main site is not UNA I’m using nodejs for the backend, with Vite for the frontend. Initially, my intention was to build a Vite-based interface for UNA that would connect via API to the UNA backend. However, since learning that NEO will be released, I decided to stop this work especially considering that UNA is also integrated with mobile applications, so my approach could turn into redundant effort in the wrong direction. Instead, I’m waiting for NEO to become available, as I believe it will be much more effective to align with it and contribute to the NEO frontend at that point.
I am now preparing a recipe to reproduce and further improve performance for UNA. For this purpose, I’ll be forking UNA on GitHub and suggesting patches. There is still quite a bit of work ahead, but we’re not far I believe I can contribute substantial improvements to help UNA fronted achieve 100% across all Lighthouse categories. I’m also involved in other projects, but I’ll dedicate part of my time to UNA within the time available, as I feel the platform is now very close to being fully polished.
One more question: does this recipe include NEO, or is it designed to work without NEO as UNA standard?
Thank you! and congratulations for your performance.
G
I've created a new virtual site ready for testing. If anyone at Una wants to let me know an install process for the test code - I'll get it up and running. Alternatively, AlexT has a login to that server - can SCP it up... but we'd need to discuss to confirm location for upload.
Thanks.
@Alex T⚜️ will comment on the recipe and server setup, but to be more specific it would help if you share what kind of workload you're setting up for? Depending on scale, we've done setups with Kubernetes, custom cluster and simple monoliths with just basic DB server isolation and remove storage. It really only gets tricky when you're configuring to 500K+ concurrent users.
As for NEO - we're only just preparing combined deployment now. We'll first release UAN 15a1, then NEO as UI for Core and Spacenook starter kit. Once we get some feedback we'll publish docs and release the React/RN SDK (all the NEO tooling) so you can build your own kits.
H
On the same machine, can we have the result with 14.0 ?
Hello @Alex T⚜️ and @Andrey Yasko , thank you for clarifying.
To make it more concrete, I believe it would be extremely valuable for the community if UNA could publish a minimal “reference recipe” for a profesional scalable architecture for self hosted. Specifically, we are interested in what you would recommend as the starting point for a professional deployment that can later scale without requiring a complete re-architecture.
For example, what would you suggest as a baseline Docker Swarm/Kubernetes (or cluster) setup that includes:
The idea is not necessarily to handle 500K concurrent users from the start, but to have a foundation that can grow towards that without major restructuring. A documented minimal but scalable stack would be very useful for startups adopting UNA in production.
Would you be able to share such a recommended “minimal scalable architecture” so we can all use it as a reference?
Additionally, it would be extremely helpful if the recipe could include concrete sizing and storage recommendations, for example:
storagefolder) whether you local storage SAN or NAS and recommend S3-compatible object storage, MinIO, network filesystem, or dedicated block volumes, and how to place CDN in front of media.Any concrete numbers, config snippets, or reference
mysqld.cnftuned for those profiles would be extremely valuable for operators who want to deploy UNA professionally and scale it later with minimal rework.For example, a minimal reference recipe could look something like this (just as an illustration of the type of guidance we are hoping to see):
mysqld.cnftuned for InnoDB buffer pool, replication, and cache/storagemedia files):This way, even a startup deployment begins with a structure that can scale horizontally (adding nodes per role) without needing to completely re-architect later.
Thank you, sharing a community reference like this would help a lot of teams get UNA into production reliably. Also Thank you for NEO timeline clarification.
@Andrey Yasko With the UNA 15a1 and NEO release, will we be able to build a native mobile app? Please could you clarify that part?
Yes. NEO is a monorepo client app which we use as a reference SDK for React (Next.js) and ReactNative (Expo) apps. We have 3 client apps built and preparing for production release now, and another 2 should be our by end of the year.
With UNA 15 you’ll get early alpha of the tyr SDK as well as uodated Spacenook KIT with both UNA wnd NEO bundled.
That's awesome! Thank you so much for the great work.
Can you explain to a noob what you mean? :-)