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

further optimize conf.settings access when logging is enabled #5739

Conversation

ryanpetrello
Copy link
Contributor

the callback receiver is still fairly slow when logging is enabled due
to constant setting lookups; this speeds things up considerably

related: #5618

@ryanpetrello
Copy link
Contributor Author

ryanpetrello commented Jan 22, 2020

a modest playbook, before (with logging enabled):

notice how only about 10% of the total time is spent idle polling for new messages (the blue right-hand side of the graph)

image

@ryanpetrello
Copy link
Contributor Author

ryanpetrello commented Jan 22, 2020

The same playbook, after this PR.

Notice how this version spends almost all of its time where you expect:

  • the overwhelming amount of time is spent idle waiting for more messages
  • ~9% of the overhead is the websocket emits
  • ~7% is spent on external logging; around 5% of that is actually just grabbing settings from memcached

this graph is what I'd expect to see in a system that is keeping up with spikes of stdout

image

@@ -186,8 +194,6 @@ def set_many(self, data, **kwargs):
self.set(key, value, log=False, **kwargs)

def _handle_encryption(self, method, key, value):
TransientSetting = namedtuple('TransientSetting', ['pk', 'value'])
Copy link
Contributor Author

@ryanpetrello ryanpetrello Jan 22, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It turns out namedtuples are really slow to create on demand like this. In my testing, this one line was accounting for almost 25% of the total time spent on event processing when logging was enabled:

image

looks like other communities have noticed this about Python as well:

https://rhye.org/post/python-cassandra-namedtuple-performance/
https://bugs.python.org/issue28638

@softwarefactory-project-zuul
Copy link
Contributor

Build succeeded.

self.cluster_host_id = settings.CLUSTER_HOST_ID
self.tower_uuid = None
uuid = (
getattr(settings, 'LOG_AGGREGATOR_TOWER_UUID', None) or
Copy link
Contributor Author

@ryanpetrello ryanpetrello Jan 22, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a lot less expensive to just set these once instead of doing a lookup on every log emit; they're generated once at install time anyways.

@@ -316,6 +317,7 @@ def serialize(cls, message):
def get_handler_class(self, protocol):
return HANDLER_MAPPING.get(protocol, AWXNullHandler)

@cachetools.cached(cache=cachetools.TTLCache(maxsize=128, ttl=3))
def get_handler(self, custom_settings=None, force_create=False):
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're calling this constantly, and it is absolutely destroying us when logging is enabled; this is a compromise to cache this slightly and give memcached a break when event logging is enabled.

@@ -342,10 +344,14 @@ def get_handler(self, custom_settings=None, force_create=False):
self._handler.setFormatter(self.formatter)
return self._handler

@cachetools.cached(cache=cachetools.TTLCache(maxsize=1, ttl=3))
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another one that we're calling all over the place.

@softwarefactory-project-zuul
Copy link
Contributor

Build failed.

the callback receiver is still fairly slow when logging is enabled due
to constant setting lookups; this speeds things up considerably

related: ansible#5618
@softwarefactory-project-zuul
Copy link
Contributor

Build succeeded.

@softwarefactory-project-zuul
Copy link
Contributor

Build succeeded (gate pipeline).

@softwarefactory-project-zuul softwarefactory-project-zuul bot merged commit 3c5e9da into ansible:devel Jan 22, 2020
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.

2 participants