Use a cache instead of sync.Pool in script processor #19562
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
adriansr
added
enhancement
discuss
|
Pinging @elastic/siem (Team:SIEM) |
botelastic
bot
added
needs_team
💔 Tests Failed
Expand to view the summary
Build stats
Test stats 🧪
Test errorsExpand to view the tests failures
Steps errorsExpand to view the steps failures
Log outputExpand to view the last 100 lines of log output
|
|
@andrewkroh I was tempted to add another flag to control if it should be blocking if there are no instances available, or just the current approach of allocating a spare one. I'm not sure what the implications will be in the Winlogbeat use case. |
|
Jenkins, run tests please |
andrewkroh
approved these changes
Jul 6, 2020
This updates the script processor to keep a simple cache of Javascript VM sessions instead of relying on sync.Pool for this task. The size of this cache can be controlled by the new `max_cached_sessions` option. The reasoning behind this change is to avoid sync.Pool discarding and re-allocating new sessions every garbage collection cycle. For large Javascript pipelines, allocating a new session is a very expensive operation that can take hundreds of milliseconds or even seconds to complete. This has a severe impact in ingestion rates.
adriansr
force-pushed
the
js-processor-session
branch
from
26c6a7b to
6cb9c09
Compare
|
CI errors unrelated |
adriansr
added a commit
to adriansr/beats
that referenced
this pull request
Jul 7, 2020
This updates the script processor to keep a simple cache of Javascript VM sessions instead of relying on sync.Pool for this task. The size of this cache can be controlled by the new `max_cached_sessions` option. The reasoning behind this change is to avoid sync.Pool discarding and re-allocating new sessions every garbage collection cycle. For large Javascript pipelines, allocating a new session is a very expensive operation that can take hundreds of milliseconds or even seconds to complete. This has a severe impact in ingestion rates. (cherry picked from commit 7930f9e)
6 tasks
adriansr
added a commit
that referenced
this pull request
Jul 14, 2020
This updates the script processor to keep a simple cache of Javascript VM sessions instead of relying on sync.Pool for this task. The size of this cache can be controlled by the new `max_cached_sessions` option. The reasoning behind this change is to avoid sync.Pool discarding and re-allocating new sessions every garbage collection cycle. For large Javascript pipelines, allocating a new session is a very expensive operation that can take hundreds of milliseconds or even seconds to complete. This has a severe impact in ingestion rates. (cherry picked from commit 7930f9e)
melchiormoulin
pushed a commit
to melchiormoulin/beats
that referenced
this pull request
Oct 14, 2020
This updates the script processor to keep a simple cache of Javascript VM sessions instead of relying on sync.Pool for this task. The size of this cache can be controlled by the new `max_cached_sessions` option. The reasoning behind this change is to avoid sync.Pool discarding and re-allocating new sessions every garbage collection cycle. For large Javascript pipelines, allocating a new session is a very expensive operation that can take hundreds of milliseconds or even seconds to complete. This has a severe impact in ingestion rates.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What does this PR do?
Updates the script processor to keep a simple cache of Javascript VM sessions instead of relying on sync.Pool for this task.
Why is it important?
The reasoning behind this change is to avoid sync.Pool discarding and re-allocating new sessions every garbage collection cycle. For large Javascript pipelines, allocating a new session is a very expensive operation that can take hundreds of milliseconds, even seconds to complete. This has a severe impact in ingestion rates.
Checklist
I have made corresponding changes to the documentationI have made corresponding change to the default configuration filesI have added tests that prove my fix is effective or that my feature worksI have added an entry inCHANGELOG.next.asciidocorCHANGELOG-developer.next.asciidoc.