Download raw body.
Failing to cache time values should not be fatal early.
On Mon, Apr 08, 2024 at 12:45:18PM +0000, Job Snijders wrote: > On Sat, Apr 06, 2024 at 12:59:22PM -0600, Bob Beck wrote: > > Now that we deal with time conversion internally we no longer > > have the performance issue, so remove this cache as it adds > > complexity and confuses people where failure modes get added > > at the wrong level. > > before applying patch: > Apr 08 11:18:43 Processing time 458 seconds (381 seconds user, 94 seconds system) > Apr 08 11:26:35 Processing time 451 seconds (380 seconds user, 86 seconds system) > Apr 08 11:34:44 Processing time 460 seconds (381 seconds user, 92 seconds system) > Apr 08 11:42:39 Processing time 455 seconds (380 seconds user, 89 seconds system) > Apr 08 11:50:39 Processing time 455 seconds (380 seconds user, 90 seconds system) > > after applying patch: > Apr 08 12:10:08 Processing time 484 seconds (401 seconds user, 102 seconds system) > Apr 08 12:18:44 Processing time 460 seconds (384 seconds user, 92 seconds system) > Apr 08 12:26:49 Processing time 465 seconds (389 seconds user, 89 seconds system) > Apr 08 12:34:46 Processing time 461 seconds (389 seconds user, 89 seconds system) > Apr 08 12:42:41 Processing time 456 seconds (384 seconds user, 88 seconds system) > > I don't see a noticable slowdown in default rpki-client on a modest amd64 machine. I tested this on several machines and can't measure a meaningful difference, so let's nuke this cache altogether. ok tb
Failing to cache time values should not be fatal early.