Leandro Moreira's questions

Let's say we want to change a response from a upstream, what we can do is to use Lua+nginx on the body_filter_by_lua_block phase, here's a snippet of that.

  server {
    listen 8181;
    location /media {
        alias /media/;
    }
  }

  server {
    listen 8080;

    location /media {
        proxy_pass http://localhost:8181;

        # we need to keep this url since we're going to rewrite
        set_by_lua_block $original_uri { return ngx.var.uri }

        # when the Lua code may change the length of the response body
        header_filter_by_lua_block { ngx.header.content_length = nil }

        # removing (rewriting) the filters
        rewrite_by_lua_block {
          local uri = ngx.re.sub(ngx.var.uri, "^/media/(.*)/hls/(.*)$", "/media/hls/$2")
          ngx.req.set_uri(uri)
        }

        # applying the bandwidth min filter
        # but we can use the ngx.var.original_uri to build/select the filters
        body_filter_by_lua_block {
          local modified_manifest = filtering(ngx.arg[1])
          ngx.arg[1] = modified_manifest
          ngx.arg[2] = true
        }
    }

This works just fine! But the thing is, in this way the response will be using chunked transfer, and some clients can not deal with chunked response, do you know how can I overcome that?

Let's imagine a client A watching a live stream (which translates to a bunch of HTTP requests) with keep-alive header on.

    A -r-> LB-----> R1 --|
   /|\      |-----> R2 --|
    |       ------> R3 --| 
    |---R----------------|

Is it possible that this DSR (direct server return) Load Balancer (L4) offers least-conn method?

If it's yes, how does the reals manage to work with TCP sequence number? (and also to keepalive the connection) Since for each new client connection, the LB can route you to a different real server.

_{(source: haproxy.com)}

Let's say we're using ext4 (with dir_index enabled) to host around 3M files (with an average of 750KB size) and we need to decide what folder scheme we're going to use.

In the first solution, we apply a hash function to the file and use two levels folder (being 1 character for the first level and 2 characters to second level): therefore being the filex.for hash equals to abcde1234, we'll store it on /path/a/bc/abcde1234-filex.for.

In the second solution, we apply a hash function to the file and use two levels folder (being 2 characters for the first level and 2 characters to second level): therefore being the filex.for hash equals to abcde1234, we'll store it on /path/ab/de/abcde1234-filex.for.

For the first solution we'll have the following scheme /path/[16 folders]/[256 folders] with an average of 732 files per folder (the last folder, where the file will reside).

While on the second solution we'll have /path/[256 folders]/[256 folders] with an average of 45 files per folder.

Considering we're going to write/unlink/read files (but mostly read) from this scheme a lot (basically the nginx caching system), does it maters, in a performance sense, if we chose one or other solution?

Also, what are the tools we could use to check/test this setup?

I ran this tc bellow and it outputs requeues with high number, do you know what this requeues means? By the way, it keeps increasing over the time.

I look at man tc but I couldn't find anything.

$ tc -s qdisc ls dev em1
 qdisc mq 0: root
 Sent 1760345587651 bytes 1790125037 pkt (dropped 0, overlimits 0 **requeues 135812** ) 
 rate 0bit 0pps backlog 0b 0p **requeues 135812**