Diagnostics views and features
If you happen to have problems with the site being able to diagnose this is very important. You got several tools reachable from the management tool.
- 1. Statistics (2)
Here you can get some basic information of what is stored in your system and also if you can clean something.
- 2. ViewApplicationState (1)
The ViewApplicationState.action can be reached through the management tool and each application has one view.
Each application then has a status view and the sections are described below (opened in new window here)
The first section describes some release information, memory information and rough statistics on how the site is performing and how the load is at the moment. This is all live information so reloading this view is often quite useful. Pay close attention to the memory state when doing load tests for example or when you are developing new heavy components. The average processing time is also of great interest during load testing or during production. A low value here but slow site performance for users would for example indicate that there is an issue with your infrastructure or bandwidth. Beneath it is a list of publication (in case of live) or changes in case of working deliver.
The first input form (shown above) lets you control log4j-logging during runtime on this application. Very useful for debugging issues and the concept is simple. You just state the full class or package and then set the log level. For example – if you want to get all available debug info from the class “org.infoglue.deliver.applications.actions.ViewPageAction” you just type it in and set log level to debug. When you have gotten the debug you need do the same but set it back to warning and it stops verbose logging again.
The section above is the list of all caches InfoGlue controls:
This view is very useful when optimizing cache sizes to minimize memory consumption etc. As mentioned in the section about controlling different cache sizes one should look at the big caches and consider putting a limit on them. To low limit means less performance so it’s a delicate balance. The statistics for the different caches helps here. A high miss count in comparison to hit count means a lot of performance loss and suggest you increase that cache size if you limited it. Here you can also clear all the caches if you have cache-problems and want to debug.
Below the normal caches we have added a view of the 3:rd party taglib OSCache so you can clear those caches as well.
We have also added a part were you can clear castor persistence caches as well as application-attributes individually.
The section above lets you do a few things described on the following pages.
The section after that shows a full list of the components rendered since the application was started. It also shows the average processing time for each component and this is really great if you want to optimize your site. In this example the application has run for a while and it has becomes quite clear that the top 6 components are in fact quite heavy and should be considered first when optimizing. However the average page response time on the previous section was quite low and the number of hits the components have had are mostly limited to under 30-100 per component. This indicates that the pages are well cached and that the component average is perhaps not very interesting as they are hit so seldom. Look instead for components with a lot of hits and slow average time or extremely long response times. Below the list you can reset the stats.
This view shows you statistics for the slowest pages. Observe – this is not saved between application restarts and should only be used for debugging – not for statistics.
Suspected Thread Locks
The last links let you get to some more technical views. The first (“Suspected thread locks”) shows the stacktraces for threads that have taken to long to be good and the second (List of all active threads) shows all currently active threads. Here is an example of the suspected threads:
These views may seem a waste and to technical but they actually contains very valuable information. However you need to be familiar with java stacktraces to be able to read them. Most interesting here is the original url which caused the long response time and then the first lines in the stacktrace. It shows exactly where in the java-code the thread is now and that in combination with the call history below is all information a developer needs to find what stalls. If you reload the view and the thread does not progress you know what to debug.
3. Log viewer
This tool is like the tail-program in linux. That is – you can choose how many of the latest added lines you want to view from a certain file. Very useful if you don’t have access to the server yourself.
Just select the file you want to show and how many lines and press the refresh-button.
4. Mail notifications
In InfoGlue 2.4.6 we have added a feature that senses if the system is getting in trouble or if some pages takes to long. This is a very, very important debugging feature and quite often the best way to start debugging any production instabilities. The concept is quite simple. You set up the warning email receiver address in application settings and InfoGlue will then send emails with full thread information when pages takes to long or memory issues arises. Simplifies debugging and error tracking hugely. USE IT!!!
comments powered by Disqus