Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Do svidaniya, Igor, and thank you for Nginx

nginx.com

Post reply on HN
Print view View original

271–280 of 366 posts

Re: Do svidaniya, Igor, and thank you for Nginx

#271

Post by morelisp »

simonw wrote: post #45
stormbrew wrote: post #16

Earlier quoted context omitted.

I mean there was lighttpd before nginx and they have/had pretty similar structures, weights, etc. I feel like I knew at one point why it got so thoroughly supplanted by nginx but I don't remember now why that happened.

The performance engineering in NGINX back then was really quite something. This classic 2007 tutorial starts by pointing out that NGINX parses the HTTP verb by looking at the second letter first, so that if it's O it knows to check for POST or COPY! https://web.archive.org/web/20070505051653/http://www.riceon...

These tricks are cute, but at the time nginx's performance came from much more fundamental design decisions.

First, the async model was literally years ahead of Apache. It leaned heavily on interfaces like epoll to manage large connection pools with a small number of processes, while Apache still used a thread or process per connection.

Second, it removed exactly the right features - those with minimal benefit and high performance impact. The classic example is .htaccess, which adds (at least) one stat to every single request, but in practice was only needed for the horrible multi-tenant LAMP reseller setups of the day - everyone else was fine with static centralized configuration.

Re: Do svidaniya, Igor, and thank you for Nginx

#272

Post by piyushpr134 »

e98cuenc wrote: post #210
stormbrew wrote: post #16

Earlier quoted context omitted.

I mean there was lighttpd before nginx and they have/had pretty similar structures, weights, etc. I feel like I knew at one point why it got so thoroughly supplanted by nginx but I don't remember now why that happened.

The difference is that nginx really works. I had Panoramio, a photo website featured in Google Earth / Maps, using Apache. It started to fail down under load, and I quickly switched to lighttpd. It was faster but crashing, getting OOM, etc. I fixed a memory leak and a few more bugs, but it still crashed every now and then and I looked for alternatives. This was 2006 and nginx was the only realistic alternative on the…

Major Panoramio fan here. I have traveled a lot of places on that site. Thank you for making it :)

Re: Do svidaniya, Igor, and thank you for Nginx

#273

Post by zelphirkalt »

masklinn wrote: post #9
schoolornot wrote: post #6

It still surprises me that NGINX beat out Apache so quickly even though Apache had way more modules and was/is entirely free vs. NGINX which is more or less "open core" with some nice features requiring commercial licensing.

On the other hand, the unreadable weird-ass pseudo-XML configuration files of Apache made anyone touching them wish for something better. I also expect ngx_lua did a lot for adoption, the fact that you could always "shell out" to lua if you needed was a huge boon even just for peace of mind.

To be fair NGINX config is not better. An ad-hoc grown soup of syntax without a clear concept to govern it all.

I would prefer a simple JSON file any day. Or some Lispy S-expressions. Or some TOML or well structured XML and XSD even.

NGINX makes you learn another lang only for one tool and for a config, which mostly (always?) does not need anything more than being declarative config.

Re: Do svidaniya, Igor, and thank you for Nginx

#274

Post by Tade0 »

piskov wrote: post #80
lifeisstillgood wrote: post #70

I know this is massively off-topic (have a good well paid "retirement" Igor), but I assumed that it would be written as Dos Vidaniya instead of (the correct) Do svidanyia My Russian studies is limited to listening to Sean Connery in The Russia House, and I guess I took Dos from the latin languages. Odd.

Do (до) is basically “till” Svidaniye (Свидание) has several meanings: - most common modern single-word usage is for date as in “romantic date” - archaic is for “meeting” that remained in this goodbye form. So “do svidaniya” is literally for “till we meet again” :-)

I wonder why is it romanized to "do", when it's read as "da"?

Re: Do svidaniya, Igor, and thank you for Nginx

#275

Post by scotty79 »

orthoxerox wrote: post #252
scotty79 wrote: post #240

> Do svidaniya I wonder if using English letters to write Russian phrases is acceptable practice for native Russians. Does it sound respectful, neutral or like a mockery? I don't mean in context of that post, which obviously is respectful, but in general. Especially when unicode is a thing and you could just write до свидания

What if he was Japanese? Would you prefer to see "Sayonara" or "左様なら"?

I don't know. I'm not Japanese. My question is about how people from original culture feel about latin transliterations.

Re: Do svidaniya, Igor, and thank you for Nginx

#276

Post by Brybry »

patcon wrote: post #191
simonw wrote: post #45

Earlier quoted context omitted.

The performance engineering in NGINX back then was really quite something. This classic 2007 tutorial starts by pointing out that NGINX parses the HTTP verb by looking at the second letter first, so that if it's O it knows to check for POST or COPY! https://web.archive.org/web/20070505051653/http://www.riceon...

Nice! I can't be the only one who went looking and spent way to much time trying to acquaint myself with c++ :) Here's there I ended up: https://github.com/nginx/nginx/blob/363505e806feebb7ceb1f9ed... PS, I'm not totally sure, but they definitely use the count of letters as an optimization, and it seems they increment the bits associated with each type, so the order of the bits behind each NGX_HTTP_GET etc seems to m…

It's been a while since I have C/C++'d so some of my terminology is probably wrong.

ngx_http_v2_parse_method iterates through all the tests, starting with the first test (GET).

They compare request method string length to test string length then on matching lengths compare each character in the request method string to the test string.

Fully matching strings set the request method numerical value from the test value and returns OK.

Any non-matching characters GOTO the next test.

After that it does a sanity check on the request method string characters (A to Z or _ or -) and returns OK or DECLINED as appropriate.

For the macros defining the HTTP method numerical values I think they're set up that way as bitmasks for bitwise operations.

For example, they do things like[1]

  if (!(r->method & (NGX_HTTP_GET|NGX_HTTP_HEAD)))
Here HTTP request method value is bitwise AND against (0x00000002 OR 0x00000004)

Any non-zero value here would be true and any zero value is false. So if the request method bit value AND matches either GET or HEAD bits then this conditional is false.

[1] https://github.com/nginx/nginx/blob/a64190933e06758d50eea926...

Re: Do svidaniya, Igor, and thank you for Nginx

#277

Post by indigodaddy »

nkozyra wrote: post #7

I really take for granted how well Nginx works across a number of web backend functions. Some of the container/orchestration world has tried to supplant the need for it as a reverse proxy, but you get so many goodies out of the box just by sticking this in front of your app, and for very little overhead. I remember the pre-Nginx days and all of the struggles people routinely ran into with options like Apache or other…

I’m sure that when it was only Nginx and Apache for reverse proxy options it was the only way to go, however, these days for rev proxy, I prefer HAProxy for enterprise and Caddy for personal stuff..

Re: Do svidaniya, Igor, and thank you for Nginx

#278

Post by cyberpunk »

indigodaddy wrote: post #277
nkozyra wrote: post #7

I really take for granted how well Nginx works across a number of web backend functions. Some of the container/orchestration world has tried to supplant the need for it as a reverse proxy, but you get so many goodies out of the box just by sticking this in front of your app, and for very little overhead. I remember the pre-Nginx days and all of the struggles people routinely ran into with options like Apache or other…

I’m sure that when it was only Nginx and Apache for reverse proxy options it was the only way to go, however, these days for rev proxy, I prefer HAProxy for enterprise and Caddy for personal stuff..

I tend to use haproxy only in situations where I don't have access to a 'proper' load balancer (e.g, something which does tcp connection state failover and all that jazz); make it listen on lo0 on each client server, who then just talk to 127.0.0.1:whatever..

It does mean you are doing health checks from each client service/app, but it only eats a few mb of ram, and then you don't have to deal with making your haproxy service HA :}

Re: Do svidaniya, Igor, and thank you for Nginx

#279

Post by aargh_aargh »

madrox wrote: post #139
lmilcin wrote: post #101

Earlier quoted context omitted.

Waiting for everybody else to test the product before you migrate is perfectly common sense strategy. Especially if that product does not give you any special edge over competition.

I think the irony is that newness is irrelevant once it's being used at a certain scale. You can battle test more in an hour than you could a small scale project in ten years.

How do you battle-test in an hour the ability of the upstream developer to provide security fixes? To provide updates at all as the ecosystem develops (e.g. the rise of systemd, taking advantage of advancements in worker models, SSL library API changes, new Lua versions)? Ability to keep backward compatibility with modules?

Your approach might have led you to invest heavily in lighttpd at some point in time.

Post reply on HN