<div dir="ltr">I maintain an Nginx config generation plugin for a web hosting control panel, where people put on such high number of domains on a server normally and things I notice are<div><br></div><div>1. Memory consumption by worker process go up when vhost count go up , so we may need to reduce worker count</div><div><br></div><div>2. As already mentioned the reload might take a lot of time ,so do nginx -t</div><div><br></div><div>3. Even startup will take time as most package maintainers put a nginx -t on ExecPre(similar in non-systemd) which take a lot of time on startup</div><div><br></div><div>I have read somewhere, Nginx is not good at handling this many vhost defs ,so they use a dynamic setup (like the one in OpenResty) at CloudFlare edge servers for SSL </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 12, 2019 at 1:25 AM Peter Booth via nginx <<a href="mailto:nginx@nginx.org">nginx@nginx.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">+1 to the openresty suggestion<div><br></div><div>I’ve found that whenever I want to do something gnarly or perverse with nginx, openresty helps me do it in a way that’s maintainable and with any ugliness minimized.</div><div><br></div><div>It’s like nginx with super-powers!<br><br><div id="gmail-m_-5541991174348563954AppleMailSignature" dir="ltr">Sent from my iPhone</div><div dir="ltr"><br>On Feb 11, 2019, at 1:34 PM, Robert Paprocki <<a href="mailto:rpaprocki@fearnothingproductions.net" target="_blank">rpaprocki@fearnothingproductions.net</a>> wrote:<br><br></div><blockquote type="cite"><div dir="ltr"><div dir="ltr">FWIW, this kind of large installation is why solutions like OpenResty exist (providing for dynamic config/cert service/hostname registration without having to worry about the time/expense of re-parsing the Nginx config).</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 11, 2019 at 7:59 AM Richard Paul <<a href="mailto:Richard@primarysite.net" target="_blank">Richard@primarysite.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">



<div style="text-align:left;direction:ltr" bgcolor="#ffffff">
<div></div>
<div><span>
<div></div>
</span></div>
<div>Hi Ben,</div>
<div><br>
</div>
<div>Thanks for the quick response. That's great to hear, as we'd only get to find this out after putting rather a lot of effort into the process.</div>
<div>We'll be hosting these on cloud instances but since those aren't the fastest machines around I'll take the reloading as a word of caution (we're probably going to have to make another bit of application functionality which will handle this so that we're
 only reloading when we have domain changes rather than on a regular schedule that'd I'd thought would be the simplest method.)
</div>
<div><br>
</div>
<div>I have a plan for the rate limits, but thank you for mentioning it. SANs would reduce the number of vhosts, but I'm not sure about the added complexity of managing the vhost templates and the key/cert naming.</div>
<div><br>
</div>
<div>Kind regards,</div>
<div>Richard</div>
<div><br>
</div>
<div><br>
</div>
<div>On Mon, 2019-02-11 at 16:35 +0100, Ben Schmidt wrote:</div>
<blockquote type="cite" style="margin:0px 0px 0px 0.8ex;border-left:2px solid rgb(114,159,207);padding-left:1ex">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">Hi Richard,
<div><br>
</div>
<div>we have experience with around 1/4th the vhosts on a single Server, no Issues at all.</div>
<div>Reloading can take up to a minute but the Hardware isn't what I would call recent.</div>
<div><br>
</div>
<div>The only thing that you'll have to watch out are Letsencrypt rate Limits > <a href="https://letsencrypt.org/docs/rate-limits/" target="_blank">https://letsencrypt.org/docs/rate-limits/</a></div>
<div>#####</div>
<div>
<div>/etc/letsencrypt/renewal $ ls | wc -l</div>
<div>1647</div>
</div>
<div>#####</div>
<div>We switched to using SAN Certs whenever possible.</div>
<div><br>
</div>
<div>Around 8 years ago I managed a 8000 vHosts Webfarm with a apache. No Issues ether.</div>
<div><br>
</div>
<div>Cheers,</div>
<div>Ben</div>
</div>
</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Feb 11, 2019 at 4:16 PM rick_pri <<a href="mailto:nginx-forum@forum.nginx.org" target="_blank">nginx-forum@forum.nginx.org</a>> wrote:<br>
</div>
<blockquote type="cite" style="margin:0px 0px 0px 0.8ex;border-left:2px solid rgb(114,159,207);padding-left:1ex">
Our current setup is pretty simple, we have a regex capture to ensure that<br>
the incoming request is a valid ascii domain name and we serve all our<br>
traffic from that.  Great ... for us.<br>
<br>
However, our customers, with about 12000 domain names at present have<br>
started to become quite vocal about having HTTPS on their websites, to which<br>
we provide a custom CMS and website package, which means we're about to<br>
create a new Nginx layer in front of our current servers to terminate TLS. <br>
This will require us to set up vhosts for each certificate issued with<br>
server names which match what's in the certificate's SAN.<br>
<br>
To keep this simple we're currently thinking about just having each domain,<br>
and www subdomain, on its own certificate (LetsEncrypt) and vhost but that<br>
is going to lead, approximately, to the number of vhosts mentioned in the<br>
subject line.  As such I wanted to put the feelers out to see if anyone else<br>
had tried to work with large numbers of vhosts and any issues which they may<br>
have come across.<br>
<br>
Kind regards,<br>
<br>
Richard<br>
<br>
Posted at Nginx Forum: <a href="https://forum.nginx.org/read.php?2,282986,282986#msg-282986" rel="noreferrer" target="_blank">
https://forum.nginx.org/read.php?2,282986,282986#msg-282986</a><br>
<br>
_______________________________________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org" target="_blank">nginx@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx" rel="noreferrer" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx</a><br>
</blockquote>
</div>
<pre>_______________________________________________</pre>
<pre>nginx mailing list</pre>
<a href="mailto:nginx@nginx.org" target="_blank">
<pre>nginx@nginx.org</pre>
</a>
<pre><br></pre>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx" target="_blank">
<pre>http://mailman.nginx.org/mailman/listinfo/nginx</pre>
</a></blockquote>
</div>

_______________________________________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org" target="_blank">nginx@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx" rel="noreferrer" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx</a></blockquote></div>
</div></blockquote><blockquote type="cite"><div dir="ltr"><span>_______________________________________________</span><br><span>nginx mailing list</span><br><span><a href="mailto:nginx@nginx.org" target="_blank">nginx@nginx.org</a></span><br><span><a href="http://mailman.nginx.org/mailman/listinfo/nginx" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx</a></span></div></blockquote></div></div>_______________________________________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org" target="_blank">nginx@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx" rel="noreferrer" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx</a></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><b>Anoop P Alias</b> <div><br></div></div></div></div>