You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Christopher Schultz <ch...@christopherschultz.net> on 2011/05/13 16:47:55 UTC

Re: [OT] storing images

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alexis,

Marking off-topic because this has nothing whatsoever to do with Tomcat.

On 5/11/2011 5:06 PM, alexis wrote:
> For real time purposes, im building images

I get it.

> 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)

Ouch. You may be storing much more in memory than necessary. When you
get new data, do you update the existing JFreeChart object, or do you
create one from scratch (new series, etc.) each time the image is
requested /and/ needs to be re-generated?

> 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.

Okay.

> 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

You could also use a random request parameter value, but there's little
practical difference.

> 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.

Hopefully not "println" as that may corrupt your image and will
definitely add an unnecessary trailing newline.

So, you re-encode the image every time it's served to a client. I'm
suggesting that when you render the JFreeChart, you go all the way to a
JPEG (or image format of your choice) and store /that/ in the
ServletContext.

> 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.

I think you'll notice that CPU usage is reduced dramatically if you
aren't re-encoding the image upon every request. Inverse cosine
transforms aren't free ;)

> 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.

What profiler are you using? I use YourKit and it tells me the sizes of
object trees fairly easily.

If you store the raw bytes of the JPEG image in memory, they will take
up exactly the same size as the file does on disk. So if you look at the
image information from your web browser and it says, say, 180k for the
image, then that's how much memory it will take when it's sitting in
your ServletContext.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk3NRJsACgkQ9CaO5/Lv0PCG8wCgqwxiCsRZSQkzHbyirOiJWJD2
SwoAnj4nOKAEV15cRi7hlb3aMlgB88+n
=xWLg
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: [OT] storing images

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alexis,

On 5/13/2011 11:14 AM, alexis wrote:
> upon new data, what i only build new are the series, then i get the
> object on the servletcontext and set the new data inside this object
> (if exists, if not, the whole chart object is created)

That's good to know, though the series is where the bulk of the data is
stored, of course. I'd be interested to see what the overhead of the
JFreeChart object is with no series data.

Also, if you discard the series data anyway when you re-build, are you
really buying yourself anything by keeping the JFreeChart object laying
around?

> On May 13, 2011, at 11:47 AM, Christopher Schultz wrote:
>> Hopefully not "println" as that may corrupt your image and will
>> definitely add an unnecessary trailing newline.
> 
>> So, you re-encode the image every time it's served to a client. I'm
>> suggesting that when you render the JFreeChart, you go all the way to a
>> JPEG (or image format of your choice) and store /that/ in the
>> ServletContext.
> 
> Yes, you're right 1 encoding against n encodings, no matter how 
> small is the cpu save, it's saved n times so it makes the
> difference.
>
> And yes, out.print it is and not out.prinln, changed :)

I would use write(byte[]), but that's just me.

>> What profiler are you using? I use YourKit and it tells me the sizes of
>> object trees fairly easily.
> 
> 
> jvisualvm from the standard jdk. i saw that a heap dump can be done
> and then find what uses the dumped [heap].

You could do that. I've never really used VisualVM so I'm unsure of it's
capabilities.

>> If you store the raw bytes of the JPEG image in memory, they will take
>> up exactly the same size as the file does on disk. So if you look at the
>> image information from your web browser and it says, say, 180k for the
>> image, then that's how much memory it will take when it's sitting in
>> your ServletContext.
> 
> Im modifying it right now and testing.

Cool. Let us know how it goes.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk3NTaIACgkQ9CaO5/Lv0PAhsACgi7XX655a1/4Kof0/hRV4LZvH
NYAAn19mmPWgmWQjmYntH2aEE8C1bVhJ
=dvb7
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: [OT] storing images

Posted by alexis <al...@gmail.com>.
On May 13, 2011, at 11:47 AM, Christopher Schultz wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Alexis,
> 
> Marking off-topic because this has nothing whatsoever to do with Tomcat.
> 
> On 5/11/2011 5:06 PM, alexis wrote:
>> For real time purposes, im building images
> 
> I get it.
> 
>> 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)
> 
> Ouch. You may be storing much more in memory than necessary. When you
> get new data, do you update the existing JFreeChart object, or do you
> create one from scratch (new series, etc.) each time the image is
> requested /and/ needs to be re-generated?
> 

upon new data, what i only build new are the series, then i get the object on the servletcontext and set the new data inside this object (if exists, if not, the whole chart object is created)



>> 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.
> 
> Okay.
> 
>> 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
> 
> You could also use a random request parameter value, but there's little
> practical difference.
> 
>> 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.
> 
> Hopefully not "println" as that may corrupt your image and will
> definitely add an unnecessary trailing newline.
> 
> So, you re-encode the image every time it's served to a client. I'm
> suggesting that when you render the JFreeChart, you go all the way to a
> JPEG (or image format of your choice) and store /that/ in the
> ServletContext.

Yes, you're right 1 encoding against n encodings, no matter how small is the cpu save, it's saved n times so it makes the difference.

And yes, out.print it is and not out.prinln, changed :)


> 
>> 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.
> 
> I think you'll notice that CPU usage is reduced dramatically if you
> aren't re-encoding the image upon every request. Inverse cosine
> transforms aren't free ;)


completely agree, ties to the above note.

> 
>> 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.
> 
> What profiler are you using? I use YourKit and it tells me the sizes of
> object trees fairly easily.
> 

jvisualvm from the standard jdk. i saw that a heap dump can be done and then find what uses the dumped heat.


> If you store the raw bytes of the JPEG image in memory, they will take
> up exactly the same size as the file does on disk. So if you look at the
> image information from your web browser and it says, say, 180k for the
> image, then that's how much memory it will take when it's sitting in
> your ServletContext.

Im modifying it right now and testing.

thanks again.


> 
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAk3NRJsACgkQ9CaO5/Lv0PCG8wCgqwxiCsRZSQkzHbyirOiJWJD2
> SwoAnj4nOKAEV15cRi7hlb3aMlgB88+n
> =xWLg
> -----END PGP SIGNATURE-----
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org