Title: [Netlify] Failed attempt to renew your TLS certificate
Failed to renew TLS certificate for <my-domain>
The TLS certificate for <my-domain> will expire on Jun 28, 2020. We tried to renew it, but got this error message:
SniCertificate::CertificateInvalidError: Unable to verify challenge for www.hedgehog.studio We’ll keep trying — in most cases of failure, we succeed on the next attempt. However, it’s still a good idea to check the certificate status in your site’s SSL/TLS settings.
A reminder that starting April 14, 2020, sites without a custom domain are being moved from your-site.netlify.com to your-site.netlify.app. New websites will also have URLs ending with netlify.app, unless you specify a custom domain.
Why the change? We're investing in the security and stability of our infrastructure, and this step is necessary on that journey.
It's important to note your existing sites will continue to operate properly using their current URLs. We expect some users may have configured redirects. If you have configured redirects on our service referring to your-site.netlify.com directly, we recommend you take action to add a second copy of them for your-site.netlify.app.
If you have no redirects like that, there's no action required on your part, but we wanted to inform you well ahead of the change in case you have any questions. Additional details are provided below if you'd like to read more. Thanks for being part of the Netlify community!
-Team Netlify
Will my current sites continue to work? Absolutely. Any sites already deployed to your-site.netlify.com will continue to operate, just as they do now. Traffic to any your-site.netlify.com address will be forwarded to your-site.netlify.app seamlessly and automatically, using a 301 redirect. (This tells browsers and search engines that the site has moved, so they know the new location.)
Importantly, we have no plans to ever stop forwarding netlify.com addresses or force a migration. We understand your established domain names and inbound links to your site are important to you. After the update, links to your sites will continue to work, just as they do now. The only change will be that netlify.app will display in the URL bar, whether visitors click on a link or type your site name in directly.
Testing is now enabled—and easy to do. We've enabled testing for the migration from sitename.netlify.com to sitename.netlify.app and you may start testing it today, especially if:
You browse via yoursitename.netlify.com start using yoursitename.netlify.app you have redirects or other configuration pointing to or referencing https://yoursitename.netlify.com Again, there's no action required on your part, but we wanted to inform you the option to test is available.
Will this impact my SEO? No. Forwarding traffic to a new domain extension using a 301 redirect is a proven technique that search engines are well aware of. Your inbound links will not be affected. Your search engine rankings will not be affected.
What if I have a custom domain? There will be minimal impact to sites with custom domains, and no need to update your DNS if it's configured according to our standard documented setup. This is true whether you purchased a domain through us or brought it with you from another provider.
Will my site take longer to load? It takes just a couple of milliseconds to direct a .com URL to .app. Your users will not perceive any additional load time. And since browsers cache 301 redirects, there will be no speed impact for page loads after the first connection.
What about HTTPS? We’re doing our part for a more secure web. Every Netlify site deployed uses a free certificate from Let’s Encrypt. Your certificates will continue to work and your sites will continue to be encrypted with no action required.
Do I need to update my site or application? In most cases, no. This change is very unlikely to impact the way your application functions, as all requests will automatically be forwarded to netlify.app on your behalf.
What about new sites? Any site you deploy after April 14, 2020 will receive a shiny new .app URL that you’ll see displayed in the Netlify dashboard. However, for simplicity’s sake, even new sites will be forwarded to the right place should anyone mistakenly type the netlify.com domain. We want things to be as simple and seamless as possible.
What if I use a proxy in front of Netlify? Since Netlify operates as a global CDN, we don't encourage customers to use proxies or services like CloudFlare in front of Netlify. Using a non-Netlify proxy isn't a configuration we officially support. (For more details, read the community post 'why not proxy to Netlify.') If you do need to use a third-party proxy, you will want to carefully test your application after the migration. Some proxies expect content returned and won't be successful navigating the 301 redirect.
What if I have questions or concerns? We're here to help! Please join the discussion in the community or if you are on a paid plan including support, you can contact support directly.
Redis is mostly single threaded, however there are certain threaded operations such as UNLINK, slow I/O accesses and other things that are performed on side threads.
Now it is also possible to handle Redis clients socket reads and writes in different I/O threads. Since especially writing is so slow, normally Redis users use pipelining in order to speedup the Redis performances per core, and spawn multiple instances in order to scale more. Using I/O threads it is possible to easily speedup two times Redis without resorting to pipelining nor sharding of the instance.
By default threading is disabled, we suggest enabling it only in machines that have at least 4 or more cores, leaving at least one spare core.
Using more than 8 threads is unlikely to help much. We also recommend using threaded I/O only if you actually have performance problems, with Redis instances being able to use a quite big percentage of CPU time, otherwise there is no point in using this feature.
So for instance if you have a four cores boxes, try to use 2 or 3 I/O threads, if you have a 8 cores, try to use 6 threads. In order to enable I/O threads use the following configuration directive:
Setting io-threads to 1 will just use the main thread as usually.
When I/O threads are enabled, we only use threads for writes, that is to thread the write(2) syscall and transfer the client buffers to the socket. However it is also possible to enable threading of reads and protocol parsing using the following configuration directive, by setting it to yes:
