341–350 of 366 posts
Earlier quoted context omitted.
A bit of a micro-optimization, but couldn’t you interpret 4 bytes (including the trailing null on the three-letter verbs) as a 32-bit unsigned int and then do integer comparisons or a case statement?
You could add a computed goto to really spice things up.
Earlier quoted context omitted.
A bit of a micro-optimization, but couldn’t you interpret 4 bytes (including the trailing null on the three-letter verbs) as a 32-bit unsigned int and then do integer comparisons or a case statement?
NGINX does exactly that (after finding the space character after the verb): https://github.com/nginx/nginx/blob/7587778a33bea0ce6f203a8c... There are several points to note: This trick only works if the architecture supports unaligned memory access. Macros are used instead of functions, so you don't have to rely on the compiler to do inlining. The shifts and ors should get optimized out by the compiler. I once tried…
Presumably then it's relying on undefined behaviour.
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...
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 hi…
The Architecture of Open Source Applications - volume II - nginx:
Earlier quoted context omitted.
NGINX does exactly that (after finding the space character after the verb): https://github.com/nginx/nginx/blob/7587778a33bea0ce6f203a8c... There are several points to note: This trick only works if the architecture supports unaligned memory access. Macros are used instead of functions, so you don't have to rely on the compiler to do inlining. The shifts and ors should get optimized out by the compiler. I once tried…
> This trick only works if the architecture supports unaligned memory access Presumably then it's relying on undefined behaviour.
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...
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 hi…
Earlier quoted context omitted.
Yeah that was great. I think we all felt like we had a secret superpower few others knew about.
My job as an intern was to write an Nginx plugin for a specific type of filtering for high performance- boss was abit of a masochist ;)
Earlier quoted context omitted.
Back in 2008, if you had a FastCGI backend that produced a large body, such as a file download, lighttpd would allocate the same amount of memory and forget to free it afterward. Everything would work fine for a while, but then someone attaches a large file on your busy PHP forum and bam! Your 720MB linode is thrashing like there's no tomorrow. The proper workaround was to send an X-Sendfile header to instruct lightt…
Just to say thank you for this closure ~15 years later. I was on team lighttpd back in the day (I think I liked the config syntax more? I honestly can't remember) but this bug caused a lot of grief and at the time, it appeared like no one knew the cause. Still, lighttpd/fcgi was still better than the epic custom Apache C++ module disaster in the previous iteration.
I still remember when it was new and so small a novice can review it without a headache. It was to me the answer to attacks like slowloris and C10K problem. And the config, by far much more pleasant than apache or IIS. I use it to reverse proxy all the time! Thank you Igor and best wishes.
[flagged]
Can you please review the site guidelines and stick to them in the future? You broke more than one of them badly here.
Earlier quoted context omitted.
[flagged]
It was downvoted because you originally posted it to the wrong thread ( https://news.ycombinator.com/item?id=29981188 , instead of https://news.ycombinator.com/item?id=29985871 ). I've moved it to the right thread now. Can you please review the site guidelines and stick to them in the future? You broke more than one of them badly here. https://news.ycombinator.com/newsguidelines.html
Earlier quoted context omitted.
My memory is hazy but I think I remember running into an actual memory leak in lighttpd circa 2008. We were serving dynamic content via FastCGI, IIRC. This was a long time ago and I'm pretty hazy on the details, but I'm pretty sure I remember finding memory leak bug discussions on the lighttpd website around that time, and no clear answers on how to avoid it.
Back in 2008, if you had a FastCGI backend that produced a large body, such as a file download, lighttpd would allocate the same amount of memory and forget to free it afterward. Everything would work fine for a while, but then someone attaches a large file on your busy PHP forum and bam! Your 720MB linode is thrashing like there's no tomorrow. The proper workaround was to send an X-Sendfile header to instruct lightt…