[
https://issues.apache.org/jira/browse/LOG4J2-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514807#comment-17514807
]
Matt Sicker edited comment on LOG4J2-2795 at 3/30/22, 4:35 PM:
---------------------------------------------------------------
Well, compare the startup time of instantiating DefaultInjector (and even
running init() on it) versus the rest of the system. The DI container is the
easy part at this point. I'd expect that our implementation is faster than CDI
or Guice because it doesn't have the same huge list of features and added
indirection (interceptors, etc). At this point, I'd like to try to figure out
what remaining aspects are causing this slowdown. While I wouldn't expect this
to be much of an issue in typical applications, it would certainly be annoying
in CLI tools or cloud native micro services where you deploy super often and
startup time matters more. I know just how annoying it is to set up liveness
probes in K8s to wait for Spring Boot to start up, for example, so I know what
you mean and would love to see how else we can improve this.
I'll note in contrast, running the same thing on my machine executes in less
than 100ms, so it's gotten harder for me to find the remaining low hanging
fruit as they're all blending together at this point. If you're willing to test
out a few combinations of things, can you compare how different versions of
Java perform here? Would be nice to see how it compares with different types of
disk, too (e.g., if a cloud service is using something like EBS versus using a
local NVMe drive), to see how much of an issue this is caused by loading files
rather than executing anything redundant.
Edit: I should also note that last night, I made more optimizations to
PluginManager so that it invokes collectPlugins() at most once per category, so
that should save some time, too, though I don't expect it to be much (or if it
is a lot, hooray).
was (Author: jvz):
Well, compare the startup time of instantiating DefaultInjector (and even
running init() on it) versus the rest of the system. The DI container is the
easy part at this point. I'd expect that our implementation is faster than CDI
or Guice because it doesn't have the same huge list of features and added
indirection (interceptors, etc). At this point, I'd like to try to figure out
what remaining aspects are causing this slowdown. While I wouldn't expect this
to be much of an issue in typical applications, it would certainly be annoying
in CLI tools or cloud native micro services where you deploy super often and
startup time matters more. I know just how annoying it is to set up liveness
probes in K8s to wait for Spring Boot to start up, for example, so I know what
you mean and would love to see how else we can improve this.
I'll note in contrast, running the same thing on my machine executes in less
than 100ms, so it's gotten harder for me to find the remaining low hanging
fruit as they're all blending together at this point. If you're willing to test
out a few combinations of things, can you compare how different versions of
Java perform here? Would be nice to see how it compares with different types of
disk, too (e.g., if a cloud service is using something like EBS versus using a
local NVMe drive), to see how much of an issue this is caused by loading files
rather than executing anything redundant.
> Make LogManager/LoggerContext creation time reasonable
> ------------------------------------------------------
>
> Key: LOG4J2-2795
> URL: https://issues.apache.org/jira/browse/LOG4J2-2795
> Project: Log4j 2
> Issue Type: Task
> Components: Core
> Affects Versions: 2.13.0
> Reporter: Romain Manni-Bucau
> Priority: Major
> Attachments: image-2020-03-06-08-58-21-169.png, log4j2.png
>
>
> Currently (2.13), LogManager.getLogger("xxx") takes ~600ms on a cold JVM by
> itself.
> For a logging framework it is likely way too much (by comparison a CDI test
> with classpath scanning takes ~50ms).
>
> This ticket is about trying to be faster (maybe by removing java
> serialization usage and reducing registry usage + reflection of plugins by
> generating java code?).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
