Performance improvements for heavily loaded servers

[GoogleCodeExporter]

We are using JavaMelody for a server running thousands of threads (many are 
Comet-style long polling threads) and it's working great, but starting to get a 
little slow. The monitoring page can run into the megabyte range, and it causes 
the JS interpreter of the web browser to block.

The culprits seem to be the Threads and Current Requests sections, which can 
contain thousands of entries.

Some suggestions:

* Make it possible to omit or load the Threads and Current Requests sections 
separately
* Make sections or individual entries load dynamically
* Compress stack traces (they share much of the same text, so may be easily 
compressable)

Original issue reported on code.google.com by seh...@gmail.com on 9 Sep 2010 at 7:09

[GoogleCodeExporter]

First, I am happy that it works even with thousands of active threads (except 
this slow report).
And the http stream is probably already compressed in gzip by the server and 
then decompressed by the browser before the rendering of the html. You can 
check that by looking at the "Content-Encoding: gzip" http header in the 
response. 

And some questions: how do you know that the JS interpreter blocks the web 
browser and are you sure that it is not css or layout for example? have you 
tried the report in google chrome/firefox/opera?

Original comment by evernat@free.fr on 9 Sep 2010 at 10:08

[GoogleCodeExporter]

Yes, it works fine even with many threads! It's been critical in resolving 
server issues thus far. Kudos for that!

It seems to work OK in Firefox -- Safari shows the JS warning. I am just 
worried what will happen when we hit 30,000 or so threads. This page already 
takes several seconds to render (with ~7000 threads) and is a >25 MB download.

Original comment by seh...@gmail.com on 10 Sep 2010 at 1:25

[GoogleCodeExporter]

First it seems recommended not to use safari but to use mozilla firefox (or a 
bit better in my case google chrome) to display html reports when there are 
thousands of threads. And html reports are already compressed as gzip and 
uncompressed by the browser with a ratio of about 1/30 (30 KB compressed for 
900 KB uncompressed).
And it is good to know that javamelody has no problem with 7000 threads and 
7000 active http requests, except that reports are quite large when 
uncompressed (thanks).

Then I have changed things in order to display the threads in their own page 
("?part=threads") when there are more than 500 of them, and to display the 
"current requests" in their own page ("?part=currentRequests") when there are 
more than 500 of them.
If there are less than 500 threads or current requests, then nothing is changed 
in the reports.

This is commited in trunk for next release and I have made a new build, which 
is available at 
http://javamelody.googlecode.com/files/javamelody-20100913.jar

Original comment by evernat@free.fr on 12 Sep 2010 at 11:23

• Changed state: Fixed

[GoogleCodeExporter]

This is great, thanks! This will be helpful also when looking @ JavaMelody on 
the iPhone, as it too uses Safari (and has a much lower memory threshold)

Original comment by seh...@gmail.com on 13 Sep 2010 at 5:17