Sorry guys ive been not so clear. here's the deal , ill explain the whole
process trying to resume so nobody gets bored reading :)
final images are 400x300px (sometimes png, sometimes jpg) containing pie
charts, bar charts, etc. The webapp is constantly connected getting information
from a pbx in different call centers and building tables to be displayed by jsp
pages for real time reports and storing in a postgres database historical data
which is accesed by others jsp.
For real time purposes, im building images, so thinking for example in a
"skill" image and having 10 agents in one call center queue, for skill i can
have top 10 images (image skill-1 is created first time is requested and stored
on servlet context, so if every agent is requested one by one (very rare) will
be 10 images stored in memory), if another webapp user requests again skill-1
image, this one will be created again and will overwrite the existing one on
the servletcontext, meaning that if 50 webapp users are requesting skill1
image, in memory ill have only 1 image and ill serve the same one to every
user. Once the image is re-created, will be served to all users and so on
(images are being requested by an ajax script).
so, in the heaviest scenario i can have 40/50 images tops if all are were
requested and that has a tiny chance to occur.
We'll going to images, what i store in servletcontext is NOT practically the
image, as those images are being constructed using jfreechart, what i store in
memory is the JFreeChart object (and inside the JFreeChart object i store some
other objects like the dataseries, Custom Labels, etc), after i store this
object inside servletcontext, my servet returns out.println("<img
src=\"getImage?img=skill1_239423948.png\">"); so the ajax script sets this as
innerhtml for a div in the jsp, and the jsp calls getimage servlet requesting
the image.
What happens here is
1. _239423948 is a random value that i add to avoid browser caching of the
image, so as i receive it, it's discarded
2. i read the JFreeChart object from the servletcontext regarding skill1
3. i call a method from the object that is called writeChartAsJPEG (self
explaining) , set the response type to image/jpeg and then i do
out.println(JFreeChart); which renders the image that is finally shown by the
browser.
It's working without any problem, im constantly profiling the webapp to see how
it behaves and before/after the image implementation i have noticed no change
at all on the memory and cpu usage.
What i dont know exactly is how much memory uses a JFreeChart object stored in
the servletcontext, if there's a way to know it please let me know so i can
check it and let you know.
Thanks again, sorry by the length of this message.
On May 11, 2011, at 4:05 PM, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Alexis,
>
> On 5/6/2011 10:52 AM, alexis wrote:
>> I understand, but i have top 12 images of 35kbytes, no more.
>
> Fair enough.
>
>> Encoding load is an issue yes, but the images are reflecting
>> callcenters call queues and some stuff related so the need to refresh
>> and rebuild the images is a requirement.
>
> You might consider going all the way down to the byte-level encoding and
> store the raw bytes of the JPEG or PNG that you want to use. You didn't
> say what you were doing, but it's certainly possible to store a
> java.awt.Image in memory and re-encode it for every request. You may as
> well encode it once and serve the bytes directly with those requests.
>
>> What im thinking is to avoid the generation upon servlet calls
>> (servlet only reads and presents the image to callers) and start a
>> different thread with a listener in charge to periodically rebuild
>> images.
>
> I think you're better-off doing lazy up-to-date checking, but that's
> just me... it depends on what your requirements truly are. I always hate
> having background threads running in a webapp.
>
>> Do you believe regarding memory it can cause a big issue? In worst
>> case it's 450kbytes when all images are created and stored.
>
> Just be sure to test your caching algorithm and make sure the purge is
> working you expect. Image data can take up memory in a hurry if you have
> a bug in there.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk3K3fkACgkQ9CaO5/Lv0PB81gCdE84v3o2RhjwQo+EL1cT5pHBY
> 1PUAoLAulZdm+nlzKsRfPFdWKjPRK/R9
> =b465
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
