Comment to 'The need for speed'
Comment to The need for speed

  • 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.

    • See older replies...

    • 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.