Page MenuHomePhabricator

Cache generation of the SSH authentication keyfile for sshd
ClosedPublic

Authored by epriestley on Oct 21 2016, 2:27 PM.
Tags
None
Referenced Files
F14052202: D16744.diff
Fri, Nov 15, 7:12 AM
F14047932: D16744.id.diff
Thu, Nov 14, 5:51 AM
F14045403: D16744.diff
Wed, Nov 13, 3:40 AM
F14037394: D16744.diff
Sun, Nov 10, 3:34 PM
F14022311: D16744.diff
Wed, Nov 6, 4:10 PM
F14015505: D16744.diff
Sun, Nov 3, 7:55 PM
F13990071: D16744.id.diff
Tue, Oct 22, 12:55 AM
F13967493: D16744.diff
Oct 16 2024, 1:57 PM
Subscribers
None

Details

Summary

Ref T11469. This isn't directly related, but has been on my radar for a while: building SSH keyfiles (particular for installs with a lot of keys, like ours) can be fairly slow.

At least one cluster instance is making multiple clone requests per second. While that should probably be rate limited separately, caching this should mitigate the impact of these requests.

This is pretty straightforward to cache since it's exactly the same every time, and only changes when users modify SSH keys (which is rare).

Test Plan
  • Ran bin/auth-ssh, saw authfile generate.
  • Ran it again, saw it read from cache.
  • Changed an SSH key.
  • Ran it again, saw it regenerate.

Diff Detail

Repository
rP Phabricator
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

epriestley retitled this revision from to Cache generation of the SSH authentication keyfile for sshd.
epriestley updated this object.
epriestley edited the test plan for this revision. (Show Details)
epriestley added a reviewer: chad.
chad edited edge metadata.
This revision is now accepted and ready to land.Oct 21 2016, 2:28 PM
src/applications/cache/PhabricatorKeyValueDatabaseCache.php
101

This was just a bug, but we mostly don't interact with database caches today since we have relatively little data like this.

This revision was automatically updated to reflect the committed changes.