Which OS do you recommend to use for Hestia?
Depends on what you like… There are performance wise no really big differences.
Main difference see the link below.
https://linuxconfig.org/debian-vs-ubuntu
I use Ubuntu the fact I use some functions that are not available on Debian…
2 Likes
I have one more question.
I have 2 instances of Digital Ocean in Singapore. I have installed VestaCP on one and HestiaCP on other.
I have created a page to show phpinfo and when I test the speed of the page using webpagetest from CA, I find huge difference in SSL negotiation time.
VestaCP VPS SSL negotiation: ~250ms
HestiaCP SSL negotiation: ~420ms
Any idea why such huge difference?
That’s a good question, probaly @alex has an answer for it 
.
What I can write is that hestia has much more improved security than vesta, including A+ certificates on https://www.ssllabs.com/ssltest/, at least when you enable HSTS for your domain. So “maybe” there is some relation due to the ssl negotation time - but this is just a guess.
Maybe here some to read:
- Certificate used. You’ll want a RSA 2048 cert. Anything more is overkill and slow. Some sites (and some scanning tools) choose RSA 4096 certificates but these do have a noticeable impact on speed with no real increase in security (at this time - that may change). There are newer ECDSA certs (usually shown as 256 EC cert in ssllabs report) but these faster ECDSA certs are not supplied by all CAs and are not universally supported by all clients, so visitors on older hardware and software may not be able to connect with them. Apache (and very recently Nginx from v 1.11.0) supports dual certs to have best of both worlds but at the expense of having two certs and some complexity of setting them up.
Don’t know what VestaCP is using (Never used it before) but this could be the reason…
SSLlabs test:
VPS with HestiaCP: This server supports TLS 1.3 (A)
VPS with VestaCP: This server supports TLS 1.0 and TLS 1.1. Grade capped to B.
420ms for ssl negotiation is huge, there something else going on there.
Hi @pkr
Even though I can’t comment for the exact figures since there are many parameters impacting negotiation times and I don’t have a Vesta installation at the moment in order to perform comparisons, nor access to your servers.
What I can tell you is that Hestia’s focus from day one has been security, given the bad experience most of us had with Vesta. So security is always on top of our list.
Stricter security among others means using more advanced ciphers, resolving of names of upstream servers, SSL stapling etc. So it’s normal to have somehow higher SSL negotiation times etc.
Don’t get me wrong - we value performance a lot. But when compared to security, it always comes second.
1 Like
I tested HestiaCP on Ubuntu 18/20, Debian 9/10. On Debian 10 and Ubuntu 18/20, SSL negotiation time from Singapore to CA was ~425ms.
But on Debian 9, SSL negotiation time is ~225ms.
So, it seems that Ubuntu 18/20 and Debian 10 have something to do with HestiaCP in slowing down the SSL negotiation.
This is just my observation.
I used Nginx+Apache(MPM_event)+PHP-FPM on all OS.
I tested the latest HestiaCP on Debian 9/10 and Ubuntu 18/20 and found that except for Debian 9, the SSL negotiation time of the website is very slow.
E.g.
On Debian 10 and Ubuntu 18/20, the SSL negotiation time of my website was ~450ms.
On Debian 9, it was ~270ms.
Any idea, what could the issue?
Just merged your threads together, please give it next time a new entry instead creating a new thread, so we’ve the informations a bit more together .
@pkr can you run checks with ssllabs on deb9 vs deb10 and watch out for differences in protocols and ciphers used as well as additional certs being requested or pulled in from elsewhere.
also maybe try some other destinations to check from to make sure that it really isn’t just a cert that’s missing and has to be pulled from a third party or whatever.
don’t get me wrong, but I would only consider this is an issue, if you can reproduce it from other locations as well 
PS: my guess would be that packages in deb 9 (as well as whatever vesta, mentioned in the older posts, is using) simply don’t support some newer algorythms/caphers that offer better security but come at the costs of negotiation taking longer as @alex pointed out already