4 ms·

Looking forward to a day when I can give Nginx another try when its feature set has matured in more directions. Its unfortunate lack of fine-grained versatility

Looking forward to a day when I can give Nginx another try when its feature set has matured in more directions. Its unfortunate lack of fine-grained versatility in some areas of configuration forced us to stick with Apache's httpd after trying to replace an old Apache setup with Nginx - everything looked much better in terms of resource efficiency, until we hit the problem of simply not being able to translate a few specific configuration scenarios from Apache to Nginx, forcing us to deem Nginx as a definite no-go for our case.

hackermom 14y ago
Did I hit a nerve of some zealous Nginx user when mentioning the fact that Nginx isn't a silver bullet? :) I'm sure you can downvote this comment, too! Knock yourself out!
- deleted 14y ago
  [deleted]
- hellweaver666 14y ago
  I think it's because you didn't expand on the problems you experienced sufficiently.
- elithrar 14y ago
  > Did I hit a nerve of some zealous Nginx user when mentioning the fact that Nginx isn't a silver bullet? :) I'm sure you can downvote this comment, too! Knock yourself out! I don't believe the comments had anything to do with being a zealot, but instead a curiosity: being HN, it is useful to know why a user made a technical decision. If you could elaborate on the problem, you're much less likely to get downvoted.
- mhurron 14y ago
  No you just gave a handwave "Nginx is not all that" without supporting the assertion. You would get the same response posting "Nginx is the greatest thing since sliced bread and you should ditch httpd."
  - hackermom 14y ago
    I wasn't aware that this was a Q&A or issues tracker for Nginx, which is why I never had the intent of bringing details up. My apologies for posting these things in the official Nginx resources. The sarcasm is on the house.
    - deleted 14y ago
      [deleted]
    - JoachimSchipper 14y ago
      (Your new posts appear [dead]. You may want to petition pg and/or make a new account.)
    - JoachimSchipper 14y ago
      (You're still [dead]. Look at HN from a non-logged-in computer.)
theatrus2 14y ago
I've run into the same issues. Apache and it's modules simply do more out of the box.
boundlessdreamz 14y ago
It would be helpful if you explain what those scenarios are.
- hackermom 14y ago
  One problem that comes to mind is Nginx' inability to have multiple root dirs set for one and the same host depending on what location directive will be in use, for example when wanting to set unique root dirs during userdir mapping - which also happens to be something that Nginx can't do as properly as Apache. Another problem I can recall is how some configuration scenarios require an abundance of PCRE matching clauses to fulfill, which in turn causes Nginx a tangible but most noticable delay for each request that happens to match the implied regexp portion. I am not sure why this is the case, and I am not sure why it isn't so in Apache, where regexp clauses introduce no noticable stall.
  - moonboots 14y ago
    For the userdir example, would the following link solve your problem? http://wiki.nginx.org/UserDir http://wiki.nginx.org/UserDir
    - hackermom 14y ago
      We used something just like that to map users' home directories, but it doesn't solve the problem of not being able to set a unique root directory for each user case. Nginx accepts just one root dir setting, and it can't be conditionally set (or overwritten in a later if-else scenario) by putting it inside a location clause. One solution is to globally set /home as the definite root for all user location cases, but this does not sit alright with me - the document root should just not sit outside the target's home.
      - moonboots 14y ago
        This example uses the alias directive, which can be set inside location clauses unlike the root directive. The distinction between root and alias isn't the most user friendly, but I think this setup is effectively the same as separate roots per user. Unless otherwise configured, users will not be able to access anything directly in /home, only in the user subdirectories. That being said, I have no problems with Apache, especially if it's already in place and working.

hackermom 14y ago

Did I hit a nerve of some zealous Nginx user when mentioning the fact that Nginx isn't a silver bullet? :) I'm sure you can downvote this comment, too! Knock yourself out!

deleted 14y ago
[deleted]
hellweaver666 14y ago
I think it's because you didn't expand on the problems you experienced sufficiently.
elithrar 14y ago
> Did I hit a nerve of some zealous Nginx user when mentioning the fact that Nginx isn't a silver bullet? :) I'm sure you can downvote this comment, too! Knock yourself out! I don't believe the comments had anything to do with being a zealot, but instead a curiosity: being HN, it is useful to know why a user made a technical decision. If you could elaborate on the problem, you're much less likely to get downvoted.
mhurron 14y ago
No you just gave a handwave "Nginx is not all that" without supporting the assertion. You would get the same response posting "Nginx is the greatest thing since sliced bread and you should ditch httpd."
- hackermom 14y ago
  I wasn't aware that this was a Q&A or issues tracker for Nginx, which is why I never had the intent of bringing details up. My apologies for posting these things in the official Nginx resources. The sarcasm is on the house.
  - deleted 14y ago
    [deleted]
  - JoachimSchipper 14y ago
    (Your new posts appear [dead]. You may want to petition pg and/or make a new account.)
  - JoachimSchipper 14y ago
    (You're still [dead]. Look at HN from a non-logged-in computer.)

theatrus2 14y ago

I've run into the same issues. Apache and it's modules simply do more out of the box.

boundlessdreamz 14y ago

It would be helpful if you explain what those scenarios are.

hackermom 14y ago
One problem that comes to mind is Nginx' inability to have multiple root dirs set for one and the same host depending on what location directive will be in use, for example when wanting to set unique root dirs during userdir mapping - which also happens to be something that Nginx can't do as properly as Apache. Another problem I can recall is how some configuration scenarios require an abundance of PCRE matching clauses to fulfill, which in turn causes Nginx a tangible but most noticable delay for each request that happens to match the implied regexp portion. I am not sure why this is the case, and I am not sure why it isn't so in Apache, where regexp clauses introduce no noticable stall.
- moonboots 14y ago
  For the userdir example, would the following link solve your problem? http://wiki.nginx.org/UserDir http://wiki.nginx.org/UserDir
  - hackermom 14y ago
    We used something just like that to map users' home directories, but it doesn't solve the problem of not being able to set a unique root directory for each user case. Nginx accepts just one root dir setting, and it can't be conditionally set (or overwritten in a later if-else scenario) by putting it inside a location clause. One solution is to globally set /home as the definite root for all user location cases, but this does not sit alright with me - the document root should just not sit outside the target's home.
    - moonboots 14y ago
      This example uses the alias directive, which can be set inside location clauses unlike the root directive. The distinction between root and alias isn't the most user friendly, but I think this setup is effectively the same as separate roots per user. Unless otherwise configured, users will not be able to access anything directly in /home, only in the user subdirectories. That being said, I have no problems with Apache, especially if it's already in place and working.