I'm currently trying to track down a performance issue and I've found a large amount of time is being spent in the code where you request a bean from a ApplicationContext:
ApplicationContext.getBean(String beanName);
Do you know if it's possible to turn on any debug or log information within Spring so that I can see all the objects that are instantiated from this call as well as the times to create them?
I've been trying to profile with Yourkit, but the operation only take 1.4 seconds in total and only on the first call, so Yourkit seems to struggle with short lived, one off calls like this.
It's why I was heading down the logging route.
Spring uses log4j, so you can set your log level to debug and see what you get. It'll be a lot of output. I'd advice not logging it to the console - write it to a file.
How did draw that conclusion? Are you profiling your app with Visual VM, with all the plugins installed?
I'd bet that the app context is not the issue. If the time spent in the app context is large, it should just be on startup when Spring is reading and parsing the configuration, instantiating and wiring beans. Once it's done the cost is amortized over the life of your app. For most web apps this is a startup cost, not a reflection on the experience users have when using your site.
It's far more likely to be in your code. Be sure that you aren't being mislead by not taking a comprehensive view.
Related
I am having multiple java application configured in my app-dynamics controller and they have their own java agent running and reporting the metrics.
My problem is that SLA for each application is different and if i change the slow transaction threshold for a single application. it changes it for other application as well, which is creating lot of trouble for me.
So my question is how to configure separate transaction threshold for each application in AppDynamics controller ?
You can build multiple baselines within AppDynamics if you'd like to. The thresholds should be auto calculated off deviation from baseline. This makes it so you don't need to configure them manually. If you want to do SLA tracking, Business iQ (analytics) can do this very well. We also are building additional features around SLA use cases we can share.
Feel free to email me or support for a hand.
I'm developping a Web Service, using Glassfish 4. When someone makes a call, I know how many time each method took. I'm saving this information on log(Log4J).
Now I want to monitorize the application using JMX (Currently I'm using Jolokia).
From what I know, there are 2 possibilities:
Implement Mbean interface and extends it on all my classes
Disadvantages: too much code and possible wasting memory and processing time)
Use JMXlogger (the information about this solution is very old)
Is there another strategy?
i found some posts dealing with this topic, but our situation is a bit different, so I post it here, hoping someone can help us with it.
The situation is:
We develop a rich client that is started via webstart (loaded from a server). In the client we use spring (3.0.5) for dependency injection, nothing else so far.
Since we had big trouble with slow component scans because of AOP in spring, we do not use all spring jars but the following:
spring-asm-3.0.5.RELEASE.jar
spring-beans-3.0.5.RELEASE.jar
spring-context-3.0.5.RELEASE.jar
spring-context-support-3.0.5.RELEASE.jar
spring-core-3.0.5.RELEASE.jar
spring-expression-3.0.5.RELEASE.jar
The effect we have is strange:
If we start the rich client via webstart it is quite fast (component scan in a few seconds).
Now (for some reason) i try to start our client as regular application by just having all jars on my computer and starting the app with a huge classpath.
In this scenario it takes 3-5 minutes (depending on the computer) to boot the app.
In the log i can see its the spring component scan that takes so long.
Of course the used jar files are 100% identical in both solutions.
So my fundamental question is: Where is the difference here?
I would have expected it all the way round. Long time in Webstart and fast as application.
Does anyone have a hint what could cause those long startup times in the application scenario?
I have an application that is getting fairly large, and the Spring start up time is about 20 seconds. For production use, this is fine, but for development, this is a big pain.
What is a good profiling tool or approach that can give me precisely the information I need to figure out what is taking so long? Maybe it's something I can optimize?
My application is a fairly typical spring/hibernate web app. There's about 50 database tables and several hundred beans (like 200-300... I didn't count). There's a few #Configurable beans. Lots of component scanning. I am also using Spring Security.
I did some primitize profiling with log4j - just at the INFO setting. Here are some of the things that are taking a bit of time:
INFO DefaultListableBeanFactory:555 - Pre-instantiating singletons - 2 seconds
INFO SessionFactoryImpl:202 - building session factory - 2 seconds
INFO HibernateTransactionManager:415 - Using DataSource [com.mchange.v2.c3p0.ComboPooledDataSource......] of Hibernate SessionFactory for HibernateTransactionManager - 7 seconds
There are a couple of things that take .5 to maybe 1 second at the most, but these 3 were the largest ones.
One option you can try is to use the default-lazy-init option to lazily initialize the beans. Spring initializes all singleton scoped beans during initialization. Read Lazily-instantiated beans section of the reference doc.
Make sure to parameterize the value so that you can change it to true during dev time and false during production deployment.
Component scanning is Slow. Refer to this post on how to disable this when you use Autowiring.
I'm saddened that all of the answers so far focus on how to improve performance and none of them actually help you do analysis. I've used YourKit to great effect in other profiling problems, but can't speak to it's usefulness with Spring startup.
I've had good success splitting my spring configuration into separate files and only loading the files needed for a particular test. This works especially well for me because I'm using Camel which is expensive to start and not used by most of my tests. I've been using H2 so that I can run tests of my DAOs + Services against a database without any complex startup/shutdown (though it took a while to get all that wired together successfully). However, I still have a problem starting up the whole app for interactive testing. It's slow for me too.
You can use Spring insight also.
20 seconds, to startup the application. that doesn't matter. What's matter is the time you need to run your test cases!
So write your tests with Mocks that do not need to startup spring at all.
For the more integration like tests, try to split the configuration, so that only the beans are initialized that are needed for some bunch of tests.
I'd like to trace a java application at runtime to log and later analyze every its behaviour.
Is there a possibility to hook into a java application to get runtime information like method calls (with parameters and return values) and the status of an object (i.e. its attributes and whose values)?
My goal is to get a complete understanding of the applications behaviour and how it deals with the data.
If you need highly customized logging and runtime processing, one alternative to profilers is to use aspects and load-time weaving.
We use AspectJ in this way to capture and log the authentication information for users who call a number of low-level methods for debugging purposes and to undo mistaken changes.
Use a profiler. For example JProfiler or one from this overview of opensource java profilers. Whenever I had to find deadlocks for example, these tools were priceless...
In Netbeans the profiler exist and work properly for use it see http://profiler.netbeans.org/
Maybe have a look at Glassbox a troubleshooting agent for Java applications that automatically diagnoses common problems. From Glassbox - Automated monitoring and troubleshooting using AOP:
Glassbox deploys as a war file to your
appserver and then uses AspectJ load
time weaving to monitor application
components and other artifacts, in
order to identify problems like excess
or failed remote calls, slow queries,
too many database queries, thread
contention, even what request
parameters caused failures. All this without
changing the code or the build process.
(...)
Glassbox monitors applications non-invasively by using aspects to track component interactions. We also monitor built-in JMX data, notably on a Java 5 VM we sample thread data (every 100 ms by default). As a request is processed, we summarize noteworthy events such as where time was spent and what parameters were involved in making things slow or fail. We also detect higher-level operations (such as Struts actions or Spring controllers) that we use to report on. Our AJAX Web client then provides summaries of status by operation on the machines being monitored and we generate a more detailed analysis on request. Glassbox allows monitoring clusters of servers: the Web app uses JMX Remote or direct RMI to access data from remote servers. We also provide JMX remote access to the lower-level summary statistics.
It's a nice application, give it a try.