5 ms·

This is great news for the pagespeed people.

• pilif 11y ago
  not just for them. This also helps a lot for all OS packagers because right now they have to ship multiple custom nginx packages. As a user you either don't get what you want or you get way too much. Plus, if there's a custom module you'd really like to have in your nginx you're practically forced into building your own because there's no way to get that module loaded into the distro nginx. Yes. There's some overhead to dynamic modules. Yes. There's a (minuscule) performance advantage to static linking. But having the ability to ship modules independently of the web server core is a very important usability feature which, frankly, outweighs the performance overhead for most installs. If you're really CPU bound on that nginx instance where you need the additional modules and you removing that overhead gives you that little bit extra performance you need, then you always have the option of hard-linking them.
  • geocar 11y ago
    > There's a (minuscule) performance advantage to static linking. Is that actually true? I would have thought networking latency overshadows any memory latency introduced in a `call foo@PLT` v. `call *(foo@GOT)`. Are you aware of anyone who has benchmarked this? i.e. not a microbenchmark e.g. inside something like nginx? If so, it might be worth fixing the dynamic linker: the cost difference is absolutely fixable, as it's a tradeoff for sharing pages with other processes.
  • snuxoll 11y ago
    > This also helps a lot for all OS packagers because right now they have to ship multiple custom nginx packages. As a user you either don't get what you want or you get way too much. I guess it allows us to split the nginx-included modules into separate packages, but it does nothing to aid with packaging extra modules until nginx provides a stable ABI for modules to use.
• cbr 11y ago
  Unfortunately, it looks like it may not be something will be able to work with. Instead of an ABI like Apache uses, Nginx went with signature checking. To load a precompiled module, the signature has to match. This means we would have to compile many different binary modules for every configuration people might have, and for every version of Nginx. Like several dozen. As it stands, though, the module system would be very helpful for OS packagers, because they don't have to worry about signature mismatch.
  • falcolas 11y ago
    I would think that containers would help obviate such concerns, since it would be rather trivial to keep even a hundred images in place for an automated compilation run. Of course, serving the output would be harder, but still not impossible.
    • cbr 11y ago
      Generating all those binaries would still be a pain, but you're right that containers could help. We'd also need to write a script that looked at your nginx install and figured out what would be the right precompiled module to download.
    • xorcist 11y ago
      How does containers help? Building a hundred different nginx's shouldn't be neither harder nor easier if you stuff the binary in a container or not.
      • falcolas 11y ago
        It gives you one image per configuration, instead of one build machine, or one stored VM. It makes it easier for a single machine to iterate over dozens or hundreds of build environments with a minimum of overhead. For example, one Ubuntu machine with Docker can create build environments for every Linux based distro (and version thereof) that exists, and iterate through all of them when it comes time to build. The setup is not trivial, though it is easier than creating a similar environment with VMs or physical machines.