Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Misc. performance improvements #1738

Merged
merged 7 commits into from
Dec 8, 2016

Conversation

smfreegard
Copy link
Collaborator

  • Fixed bug in config cache that was causing non-existent files to be checked on every call.

  • As we've dropped support for earlier versions of Node, replace all calls to process.nextTick() with setImmediate() and expose setImmediate() in the plugin sandbox.

  • Fix toobusy plugin, it was completely broken and not working correctly.

  • Set backlog to zero on all listen() calls as it was found to improve connection handling under heavy loads (>30 connections/sec).

@codecov-io
Copy link

codecov-io commented Dec 8, 2016

Current coverage is 34.46% (diff: 25.00%)

Merging #1738 into master will decrease coverage by 0.01%

@@             master      #1738   diff @@
==========================================
  Files            23         23          
  Lines          5920       5919     -1   
  Methods         761        761          
  Messages          0          0          
  Branches       1504       1503     -1   
==========================================
- Hits           2041       2040     -1   
  Misses         3879       3879          
  Partials          0          0          

Powered by Codecov. Last update 226ab4b...2a9b9b4

@msimerson msimerson merged commit febe3a7 into haraka:master Dec 8, 2016
@baudehlo
Copy link
Collaborator

baudehlo commented Dec 8, 2016

Thinking about this Listen backlog - should we make it configurable?

Nginx has this to say:

backlog=number
sets the backlog parameter in the listen() call that limits the maximum length for the
queue of pending connections. By default, backlog is set to -1 on FreeBSD,
DragonFly BSD, and Mac OS X, and to 511 on other platforms.

And in the performance docs under the net.core.somaxconn settings: "Note: If you set this to a value greater than 512, change the backlog parameter to the NGINX listen directive to match"

@msimerson
Copy link
Member

I'd say that the first person to demonstrate the value of having it be configurable in Haraka can provide the impetus to make it so. Until then, as far as we know 0 is better than the default, right?

@smfreegard
Copy link
Collaborator Author

For SMTP - I can't really seem to find any benefit of setting it to anything other than 0. The problem being is that if you allow the kernel to queue up 511 connections, they all come thundering in at once.

I did consider making it configurable, but I really couldn't find a good argument for doing so.

@baudehlo
Copy link
Collaborator

baudehlo commented Dec 8, 2016 via email

msimerson added a commit to haraka/haraka-config that referenced this pull request Jan 9, 2017
msimerson added a commit to haraka/haraka-config that referenced this pull request Jan 9, 2017
* port haraka/Haraka#1738 to haraka-config

* update changelog
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants