What's coming in 6.0

[marcusquinn]

@MooCloud_Matt For interest I did a bunch of performance testing for WP a couple of years ago and LiteSpeed didn't give us any edge and was slower in many cases for a large stack (200 plugins).

I have written a ticket for our devs (brandlight.org) to share the things that we tuned for a fast stack, so we will share notes soon with our Brandlight base WP & Woo stack.

Disabling open_basedir in php gives a big performance improvement on any stack.

And we make all directories non-writable for security, except /uploads/, since the only way anything can be deployed is with GitLab CI/CD with appropriate write permissions.

We don't use full-page caching, just fragments and transients and these are our TTFB times for interest, like I say 200+ plugins:

• https://status.brandlight.org (Cloudflare)
• https://status.swanson.co.uk (Route53)
• https://status.healthshop.net (Route53 but moving to DNS Made Easy)

Each on Vultr VMs with Network WAF, and no CDN yet.

Plus, on any of those sites, you should see similar times with any language - again I'll ask our dev team to share more on all that when we get time too.

Maybe there's more to LiteSpeed that we missed but the above is with Apache, Nginx and FastCGI.

[MooCloud_Matt]

@marcusquinn

I agree that OLS or LS are not the solution, because Nginx + FastCGI + ProxyCache are excellent (with LS + ESI woocommerce it works better in any situation in this days) especially in big sites with a lot o page, content and static content like images.
But large sites are exceptional cases in the hosting world, especially those who would use cloudron do not have a huge site because they would prefer to use a custom stack in that case.
We are thinking of satisfying the customer who wants performance without doing anything other than installing the LiteSpeed cache plugin.

[MooCloud_Matt]

We are working with @girish in general to improve the WordPress and NextCloud Apps, probably moving (nothing certain) to Nginx + FastCGI.
The problem will not be nextcloud, but WordPress; We are looking for a way to intelligently implement the cache in wordpress, because one of the problems is cleaning the FastCGI cache from WordPress (we have found some plugins, but they are not always easy to implement) so we are open to advice.

[marcusquinn]

@MooCloud_Matt We use and recommend WP Super Cache for the options to cache fragments. Tried all the rest but came back to this one for code-quality, hooks and ultimately it's what wordpress.com uses.

Is there a thread under the relevant Apps > Wordpress category I can ask our devs to join and contribute?

[marcusquinn]

@MooCloud_Matt Dave Hilditch at https://www.wpintense.com is a treasure-trove of tuning knowledge & dev-ops knowledge too, and his performance demo is here: https://foundthru.com

Priority being raw uncached speed because caching is just for scaling traffic really.

Be interested in your feedback before & after for uncached from trying disabling open_basedir. Query Monitor should give a quick impression on that, although we don't have QM active on live sites of course.

We also built a mustuse unloader plugin, so only the plugins used on any page are loaded. Needs to be actively managed but does mean the minimal php is processing per page load.

[msbt]

@girish said in What's coming in 6.0:

Unified dashboard for multiple cloudron setups - This will provide a unified auth across cloudron setups plus a single dashboard to control multiple cloudrons. Details are still being worked on and I will post it once I have more info.

does this come with group- or domain-admins who can only install apps/add and edit users from their designated domains/groups?

[girish]

@msbt said in What's coming in 6.0:

does this come with group- or domain-admins who can only install apps/add and edit users from their designated domains/groups?

Not part of the multi-host but it's part of the "Fix access control for service provider setups"

[marcusquinn]

Very much looking forward to seeing how you develop the multi-host features for 6.0.

If I may suggest for consideration in that it would be very useful to be able to move an entire domain with all it's configurations and apps from one Cloudron to another with a button, confirmation and function that went through the processes. I image it would need to pause all services on that domain during the transition to ensure data is frozen but it could be a scheduled maintenance or just a staging Cloudron to live Cloudron launch process.

So we can set everything up on one Cloudron instance, and them move the whole thing to another separate and dedicated one.

Might be a big ask - but though it worth bearing in mind in your designs and planning.

[will]

@marcusquinn self-hosted auto-magical devops deployments at the click of a button....

[marcusquinn]

@will That's the dream. I like scaleable businesses where the second time doing something is a tiny percentage of the effort of the first time. Setups take time, time is finite, speed is valuable. Templating is where profits are for client and provider

[marcusquinn]

@marcusquinn Putting it another way, it would make it quick to move a domain from being on a shared Cloudron to it's own dedicated Cloudron, and we'd be happily paying another licence subscription for these

[marcusquinn]

Curious how you're getting on with your 6.0 feature wishlist? I know it's always a difficult question but any idea on timeline yet?

[girish]

I don't have a concrete time yet. We just pushed out 5.6 release last week (which hasn't even been announced yet).

For 6.0 specific features, Focal support is already in master. FTS search in mail is getting there. I think the unified dashboard feature has many architectures to choose from, so we have to pick carefully and regardless of what we choose it's a bit of work (atleast a month).

[Lonkle]

Optimize WP and Nextcloud installations

Is this for both managed and unmanaged versions of Wordpress? And is this completed already - it seems like WP has gotten a lot better with Redis (can’t remember if this is a new feature in one of the 2020 updates but I think it is).

[girish]

@Lonk Yes, it's for both. It also includes PHP stack and Nextcloud as well.

The core issue is that currently we sort of hardcode the apache mpm_prefork configuration in the Dockerfile/app package. Making this customizable will easily make things more performant based on the user's setup/traffic. The fixes are not on platform side and on the app packaging side, so it's not tied to Cloudron 6 as such. We had put it in there because we wanted to investigate if this was some platform side issue (maybe some mysql performance related etc).

[marcusquinn]

@girish Good stuff - I'm impressed already

[girish]

I made a new post for what's really coming in 6.0 - https://forum.cloudron.io/topic/3205/what-s-coming-in-6-0-take-2 . I will lock this thread since this post got split into 3 releases!