scalability issues with server side chart generation

Discussion about JFreeChart related to stockmarket charts.
Locked
hongping
Posts: 14
Joined: Thu Jul 29, 2004 1:32 am

scalability issues with server side chart generation

Post by hongping » Mon Aug 16, 2004 5:13 pm

Hi,

I posted a similar thread on the general forum, but realized that stockmarket charting may actually be more likely to face the issues I am encountering.
I am currently developing a web application that displays statistics of computers such as cpu and memory usage. The web application runs on a server, and provides stats about many other computers by getting the information from a database. Users of the web app can choose to view the stats at different interval ranges, and stats from only specified computers.

For example, stats from past hour with a sample taken every 1 min; past day with a sample every 5 mins; past week with a sample every 1 hour and so on.

My first design model is a straight forward one. For each individual request, the server retrieves all the data from the database, creates a new jfreechart using the data and renders the chart as an image to be sent to the user.

My second approach was simply to cache the data points of the graph currently being viewed in the session on the first request, and retrieve only the latest stats and updating cached copy. However, this requires checking if the user is viewing the same graph as the previous request. And if not, the cached is cleared and the whole thing starts over again.

I was thinking of scalability issues with these approaches. I am wondering if there are any tools or standards for such a problem.

1. If a thousand viewers are looking at the same graph, should it be pre-generated and available to all?

A suggestion might be to have a thread pre-generate the graphs at a regular interval.

2. However, if the webapp is getting stats for one thousand computers and needs to pre-generate all the graphs, wouldn't a lot of graphs be generated but only a small subset of the graphs be actually used?
I would appreciate any guidelines or pointers, to any best practices or tools for dealing with this problem.

Guest

Post by Guest » Wed Sep 15, 2004 11:38 am

from what i understand . The best approach is to stress test your web app. First stress test approach 1 and then stress test approach 2.

I was looking for a stress testing tool, so as soon as i find one i'll tell you.

I hope this helps you.


Guest

Re: scalability issues with server side chart generation

Post by Guest » Thu Jun 09, 2005 3:41 pm

This is a serious problem that needs a good workaround. I'm not complaining here because JFreeChart is a fantastic piece of software. However, caching data into a user's session to produce a chart is a horrid idea for server production environments. It probably works just fine, however, in other environments.

1. Session replication. When you have a clustered environment for load balancing, user's sessions sometimes have to be copied to another server(s) such as with Tomcat.

For a good explaination on why depending on the Session is a bad idea, here is a very informative clustering and caching article

Any given chart could be comprised of 1000s of data items. To store those items in the session of each user who is using that chart is just a shame. Memory is wasted from holding gobs of duplicate data, CPU is wasted by repeating work, and Network is potentially wasted with chatty clusters and session replication.


Solution?
My research continues on that. But I'm thinking about a combination of
1. Avoiding user's session
2. On-Demand generation

My idea is to capture the chart's parameters and compute a unique hash (MD5?) for it. That hash becomes the chart's image's filename. So when a request for a chart comes, you compute the hash, see if the image for that hash has already been created. If it has been created, just stream the already-created image file from the filesystem. Otherwise create the image on demand and store it on the filesystem.

This way you pay for it only once (until you have generated images purged or some event listener signals that the data for that chart image has changed and it is now invalid) and share it many times.

This would solve the problem about holding vast amounts of duplicate data in multiple sessions, keep session bloat down for session replication, prevent unnecessary & wasted chart pre-generation, and most importantly in multi-tier apps, reduce the load on the bottom tier (database).


It would be incredibly beneficial to implement some kind of easy-to-use image generation & mgmt system like this while keeping these finished images aware of events that trigger their invalidation.


What does everyone else think?
Brad Plies
pliesb@yahoo.com
hongping wrote:Hi,
I am currently developing a web application that displays statistics of computers such as cpu and memory usage. The web application runs on a server, and provides stats about many other computers by getting the information from a database. Users of the web app can choose to view the stats at different interval ranges, and stats from only specified computers.

For example, stats from past hour with a sample taken every 1 min; past day with a sample every 5 mins; past week with a sample every 1 hour and so on.

My first design model is a straight forward one. For each individual request, the server retrieves all the data from the database, creates a new jfreechart using the data and renders the chart as an image to be sent to the user.

My second approach was simply to cache the data points of the graph currently being viewed in the session on the first request, and retrieve only the latest stats and updating cached copy. However, this requires checking if the user is viewing the same graph as the previous request. And if not, the cached is cleared and the whole thing starts over again.

I was thinking of scalability issues with these approaches. I am wondering if there are any tools or standards for such a problem.

1. If a thousand viewers are looking at the same graph, should it be pre-generated and available to all?

A suggestion might be to have a thread pre-generate the graphs at a regular interval.

2. However, if the webapp is getting stats for one thousand computers and needs to pre-generate all the graphs, wouldn't a lot of graphs be generated but only a small subset of the graphs be actually used?

I would appreciate any guidelines or pointers, to any best practices or tools for dealing with this problem.

gcshekar
Posts: 1
Joined: Tue Jan 02, 2007 4:03 pm

Can you help me providing a few sample pages pl.

Post by gcshekar » Tue Jan 02, 2007 4:22 pm

Hello

From the postings I notice you have worked extensively on Java and have made use of jFree a lot.

I am trying to put some graph pages for my work on NSE Stocks and wish to include Graphs whereever possible.

Kindly help me by providing a few sample pages that make use of jFree especially for the Price/Volume graph.

You may have a look at my web site
equityPlus.mansof.com/Default.aspx

Thanks & Regards
G Chandra Shekar
gcshekar@yahoo.com

Locked