3 ms·

>Do you know where that reduced average latency is coming from? Is it because nginx is serving static assets that would tie up an apache worker that could be ru

by rehack 13y ago

>Do you know where that reduced average latency is coming from? Is it because nginx is serving static assets that would tie up an apache worker that could be running/serving PHP in apache? If so, you can do the same thing by offloading all your static asset serving to another server (or a completely external CDN, which has other extremely beneficial client-side advantages too) using apache too. That is, the choice of software here isn't as big a win as presented, it's the architecture of the ecosystem that is the big influence. Yes, I understand that. I have studied about the C10K problem[1]. And have coded another service which just uses libevent[2] directly and some C++ code to serve a feature for our site very low latency. So I understand quite well why Nginx is offering low latency. As you rightly observe later on, I don't have the luxury to get obsessed with all the Whys, so often shoot for the major architectural gain and take any side effects that come along in the stride. >.. But the way you've presented it doesn't indicate well that all the causes and effects are completely understood. And I think this ends up giving Apache a bad rap. I am surprised by your this observation. I have been 100% honest in what I wrote above, and I repeat have a huge respect and thankful for the Apache team and Apache web server software. Just that, by the page loading gains we got, were clearly very good. And also there were less errors in general reported in the web master. So we stuck with the change. Also a point regarding the switching costs and extra processing between php-fpm and Nginx processes. As I said in my first comment, we do mainly Java and PHP is just for the blog. But I very clearly remember seeing all the Apache child procs bloating to 25 Mb after the first hit to the PHP code was done. So I am actually saving by externalizing on the resources. Trust me I know what I am doing. Another tangential thing not related to Nginx, which I am doing for low resource consumption. Is moving some relevant code from Java to Go. And there also am seeing huge memory gains (i.e. savings). Perhaps will share more about it at an appropriate time. [1] http://www.kegel.com/c10k.html http://www.kegel.com/c10k.html [2] libevent.org Edit: grammar

thwarted 13y ago
I am surprised by your this observation. I have been 100% honest in what I wrote above... Trust me I know what I am doing. Sorry, I didn't mean to suggest that you weren't being honest or that you didn't know what you were doing. I'm sure we've all had to deal with "Well, this guy on HN converted to X from Y and saw <insert generic gains claims here>, so why are we on Y again?", which the somewhat hand-wavy details in your original comment can end up contributing to (obviously we're limited for space and attention here, so leaving out some details can be desirable). What I failed at was communicating that my comments were not intended as an attack on your specific methodologies or choices, but was more meant to make the reader of our comments consider the wider implications of blindly following the herd and not making informed decisions. I have had people forward me lists of links to isolated, comment-less HN comments as "support" for their position. But I very clearly remember seeing all the Apache child procs bloating to 25 Mb after the first hit to the PHP code was done. So I am actually saving by externalizing on the resources. Yes, sorry, I didn't consider the exact traffic ratios between the (proxied) Java requests and the (internally handled) PHP requests. If you've got a wide spread there favoring proxied requests, then, as you've experienced, it would be advantageous to get rid of the internal handling, proxy all requests, and outsource the bloating to other processes/systems where it is more isolated, and the upper bound on the bloat be more influenced by the lower total requests for the resources that consume more. And once that's done (the getting rid of the monolithic parts) then it's a lot easier to experiment with replacing the different parts to see if there are other gains. You may have seen similar resource consumption benefits by nginx proxying to Apache+mod_php or even to bare PHP cgi. But one shouldn't even follow that method blindly either, because it's all based on workload, and everyone's workload is different. There are so system management and monitoring benefits and drawbacks that go with these kinds of changes. We both know that there is no software selection silver bullet, but it's not necessarily the readers of these comments that know that.

by rehack 13y ago

thwarted 13y ago

I am surprised by your this observation. I have been 100% honest in what I wrote above... Trust me I know what I am doing. Sorry, I didn't mean to suggest that you weren't being honest or that you didn't know what you were doing. I'm sure we've all had to deal with "Well, this guy on HN converted to X from Y and saw <insert generic gains claims here>, so why are we on Y again?", which the somewhat hand-wavy details in your original comment can end up contributing to (obviously we're limited for space and attention here, so leaving out some details can be desirable). What I failed at was communicating that my comments were not intended as an attack on your specific methodologies or choices, but was more meant to make the reader of our comments consider the wider implications of blindly following the herd and not making informed decisions. I have had people forward me lists of links to isolated, comment-less HN comments as "support" for their position. But I very clearly remember seeing all the Apache child procs bloating to 25 Mb after the first hit to the PHP code was done. So I am actually saving by externalizing on the resources. Yes, sorry, I didn't consider the exact traffic ratios between the (proxied) Java requests and the (internally handled) PHP requests. If you've got a wide spread there favoring proxied requests, then, as you've experienced, it would be advantageous to get rid of the internal handling, proxy all requests, and outsource the bloating to other processes/systems where it is more isolated, and the upper bound on the bloat be more influenced by the lower total requests for the resources that consume more. And once that's done (the getting rid of the monolithic parts) then it's a lot easier to experiment with replacing the different parts to see if there are other gains. You may have seen similar resource consumption benefits by nginx proxying to Apache+mod_php or even to bare PHP cgi. But one shouldn't even follow that method blindly either, because it's all based on workload, and everyone's workload is different. There are so system management and monitoring benefits and drawbacks that go with these kinds of changes. We both know that there is no software selection silver bullet, but it's not necessarily the readers of these comments that know that.