Hello, I'm new to vibe.d, just read D Web Development, and I'm very very interested.
Do you recommend or is it typical to deploy behind an Nginx or other reverse proxy? This might be a good idea for non-vibe.d related reasons, under some circumstances, but I am asking if there are any additional vibe.d related reasons, given the current state of development. Of course this depends upon what is being deployed; I'd appreciate some discussion of this topic as an outsider.
On Sat, 06 Feb 2016 20:36:23 GMT, Carl Sturtivant wrote:
Hello, I'm new to vibe.d, just read D Web Development, and I'm very very interested.
Do you recommend or is it typical to deploy behind an Nginx or other reverse proxy? This might be a good idea for non-vibe.d related reasons, under some circumstances, but I am asking if there are any additional vibe.d related reasons, given the current state of development. Of course this depends upon what is being deployed; I'd appreciate some discussion of this topic as an outsider.
I definitely recommend nginx if your site has over 2K daily visitors. After running without it for about 6 months, we were left with no other option but to install it. As our traffic increased, and we added translations, our site was crashing every hour or so due to the GC running. So I installed nginx first as a means of load-balancing, but then we transitioned everything related to the transport layer to it, since it also means less garbage generated by our app.
We deploy our sites in debug mode, so we can get nice callstacks, and nice error checking and whatnot. We let nginx deal with SSL, compression, static files, redirections, etc... Then all that's left is the actual site code handling the dynamic routes which is now considerably simplified. In addition to these, you also get HTTP2 working today by simply adding a directive in your config.
I am very happy with this setup, and recommend it.
On Sun, 07 Feb 2016 11:27:17 GMT, Márcio Martins wrote:
I definitely recommend nginx if your site has over 2K daily visitors. After running without it for about 6 months, we were left with no other option but to install it. As our traffic increased, and we added translations, our site was crashing every hour or so due to the GC running. So I installed nginx first as a means of load-balancing, but then we transitioned everything related to the transport layer to it, since it also means less garbage generated by our app.
We deploy our sites in debug mode, so we can get nice callstacks, and nice error checking and whatnot. We let nginx deal with SSL, compression, static files, redirections, etc... Then all that's left is the actual site code handling the dynamic routes which is now considerably simplified. In addition to these, you also get HTTP2 working today by simply adding a directive in your config.
I am very happy with this setup, and recommend it.
Great advice, glad I don't have to find this out the hard way. Thank you, much appreciated.
I'm curious: did you consider the possibility of forcing a GC periodically to preempt big collections, and if so, what behavior did that lead to?
On Sun, 07 Feb 2016 14:43:16 GMT, Carl Sturtivant wrote:
On Sun, 07 Feb 2016 11:27:17 GMT, Márcio Martins wrote:
I definitely recommend nginx if your site has over 2K daily visitors. After running without it for about 6 months, we were left with no other option but to install it. As our traffic increased, and we added translations, our site was crashing every hour or so due to the GC running. So I installed nginx first as a means of load-balancing, but then we transitioned everything related to the transport layer to it, since it also means less garbage generated by our app.
We deploy our sites in debug mode, so we can get nice callstacks, and nice error checking and whatnot. We let nginx deal with SSL, compression, static files, redirections, etc... Then all that's left is the actual site code handling the dynamic routes which is now considerably simplified. In addition to these, you also get HTTP2 working today by simply adding a directive in your config.
I am very happy with this setup, and recommend it.
Great advice, glad I don't have to find this out the hard way. Thank you, much appreciated.
I'm curious: did you consider the possibility of forcing a GC periodically to preempt big collections, and if so, what behavior did that lead to?
I did spend a bit of time on it, but with enough traffic, there is never a good moment to collect, so you just do it at regular intervals, but it didn't help as it just took too long, i.e. more than 2 secs, which is simply unacceptable, and my watchdog just kills the process for being unresponsive. What I ended up doing was tweaking the GC and basically only doing GC when there was no more physical memory, and this let the process live for about 4 hours at a time; It obviously doesn't scale, and that's when I decided to put it all behind nginx. At this time I don't have vibe's manual memory management active, which would help tremendously, but because of some hard to track problems with that, I prefer to have it off, for the time being...
At the moment, the processes live for over 2 days on average when we let them (we deploy frequently so they almost never "crash" due to the GC).
Mind you we don't do a lot to prevent generation of garbage in the frontend code... We try as best we can when it is convenient, and a little harder in library/backend code, but in general, we really use D + vibe as an advanced and efficient scripting language :)
On Sun, 07 Feb 2016 22:47:46 GMT, Márcio Martins wrote:
On Sun, 07 Feb 2016 14:43:16 GMT, Carl Sturtivant wrote:
I'm curious: did you consider the possibility of forcing a GC periodically to preempt big collections, and if so, what behavior did that lead to?
I did spend a bit of time on it, but with enough traffic, there is never a good moment to collect, so you just do it at regular intervals, but it didn't help as it just took too long, i.e. more than 2 secs, which is simply unacceptable, and my watchdog just kills the process for being unresponsive. What I ended up doing was tweaking the GC and basically only doing GC when there was no more physical memory, and this let the process live for about 4 hours at a time; It obviously doesn't scale, and that's when I decided to put it all behind nginx. At this time I don't have vibe's manual memory management active, which would help tremendously, but because of some hard to track problems with that, I prefer to have it off, for the time being...
At the moment, the processes live for over 2 days on average when we let them (we deploy frequently so they almost never "crash" due to the GC).Mind you we don't do a lot to prevent generation of garbage in the frontend code... We try as best we can when it is convenient, and a little harder in library/backend code, but in general, we really use D + vibe as an advanced and efficient scripting language :)
Interesting. If the GC was better that would be a near perfect approximation! :) I think it's understood that D needs a better GC. Thanks again.
On Sun, 07 Feb 2016 11:27:17 GMT, Márcio Martins wrote:
We deploy our sites in debug mode, so we can get nice callstacks, and nice error checking and whatnot. We let nginx deal with SSL, compression, static files, redirections, etc... Then all that's left is the actual site code handling the dynamic routes which is now considerably simplified. In addition to these, you also get HTTP2 working today by simply adding a directive in your config.
I am very happy with this setup, and recommend it.
I'm sure you're busy just like the rest of us, but if you ever happened upon some extra time could you make a quick write up of how you set this environment up? I know that with at least Azure (presumably AWS too) we could just get a one click install image setup for people to work with something like that, and that might generate some interest.
On Mon, 08 Feb 2016 02:17:22 GMT, Charles wrote:
On Sun, 07 Feb 2016 11:27:17 GMT, Márcio Martins wrote:
We deploy our sites in debug mode, so we can get nice callstacks, and nice error checking and whatnot. We let nginx deal with SSL, compression, static files, redirections, etc... Then all that's left is the actual site code handling the dynamic routes which is now considerably simplified. In addition to these, you also get HTTP2 working today by simply adding a directive in your config.
I am very happy with this setup, and recommend it.
I'm sure you're busy just like the rest of us, but if you ever happened upon some extra time could you make a quick write up of how you set this environment up? I know that with at least Azure (presumably AWS too) we could just get a one click install image setup for people to work with something like that, and that might generate some interest.
I might blog about it sometime soon.
