[Rabbit-dev] Questions about the RabbIT

[Артур Хуснутдинов]

Hello, Dev's.
I have one big question:
After the testing on proxy with the 500 users, I see, what RabbIT have lags
(too low speed).
I know that the slow processing associated with the use of my options
include compression of images with the help of ImageMagic. The inclusion
ImageMagic proxy starts slow, and there is a lot of memory processes
ImageMagic, which strongly uses the CPU and RAM. Will the time soon to write
a separate Java or C++ image processor to reduce the load on the CPU and
RAM, and reduce delays?
Recently I developed a compressive other proxies for C ++. I have an
opportunity to give you the code responsible for compression of images.
Checked that our proxy for a load of 1500 users using 50-70% CPU, for
example, Core2Duo 2.33 GHz. Expect that it will be possible not to use
ImageMagic, and include in the set of our small piece of code in C ++ for
compressing images.
Sorry my English.

[Mindaugas Žakšauskas]

??????,

If the problem you are solving is scalability (the system becomes too
slow under a huge load), why don't you just throw another box in
(horizontal scaling) or buy better hardware?

Balancing the load among the different nodes should be trivial as
Rabbit doesn't preserve the state between different HTTP requests, so
a simple DNS round robin would do.

I might not be the best person to tell this, but I think that any
image transformation activity is out of the scope of this project. If
you feel like sharing some good code, why not create another open
source project and claim it's seamless integration with Rabbit?

m.

Post by Артур Хуснутдинов
Hello, Dev's.
After the testing on proxy with the 500 users, I see, what RabbIT have lags
(too low speed).
I know that the slow processing associated with the use of my options
include compression of images with the help of ImageMagic. The inclusion
ImageMagic proxy starts slow, and there is a lot of memory processes
ImageMagic, which strongly uses the CPU and RAM. Will the time soon to write
a separate Java or C++ image processor to reduce the load on the CPU and
RAM, and reduce delays?
?Recently I developed a compressive other proxies for C ++. I have an
opportunity to give you the code responsible for compression of images.
Checked that our proxy for a load of 1500 users using 50-70% CPU, for
example, Core2Duo 2.33 GHz. Expect that it will be possible not to use
ImageMagic, and include in the set of our small piece of code in C ++ for
compressing images.
Sorry my English.
--
? ?????????,. ArtUrlWWW
_______________________________________________
Rabbit-dev mailing list
Rabbit-dev at khelekore.org
http://khelekore.org/cgi-bin/mailman/listinfo/rabbit-dev

[Robert Olofsson]

On Tue, 20 Oct 2009 15:39:16 +0500

Post by Артур Хуснутдинов
Hello, Dev's.
After the testing on proxy with the 500 users, I see, what RabbIT have lags
(too low speed).

Ok, I do not have the users to test like that, I only run a small instance
of rabbit so it will be hard for me to really test like that.

Post by Артур Хуснутдинов
I know that the slow processing associated with the use of my options
include compression of images with the help of ImageMagic.

Yes, rabbit uses imagemagic by default, you are very much free to try
out alternatives. I know that convert is not the fastest or most memory
efficient program so it may well be worthwhile to try some alternatives
out.

There are a few different reasons why forking off a convert-process was
done, one of the biggest was that image conversion is heavy, so if the
converter program dies with out-of-memory we do not want the proxy to die.

If you want to look for alternatives I can suggest the graphicsmagick
suite (it is a fork from imagemagick, so probably very easy to try out)
Another alternative that may be useful is ExactImage:
http://www.exactcode.de/site/open_source/exactimage/

Post by Артур Хуснутдинов
Recently I developed a compressive other proxies for C ++. I have an
opportunity to give you the code responsible for compression of images.
Checked that our proxy for a load of 1500 users using 50-70% CPU, for
example, Core2Duo 2.33 GHz. Expect that it will be possible not to use
ImageMagic, and include in the set of our small piece of code in C ++ for
compressing images.

If you know how to code java it is probably quite easy for you to hook
into/subclass ImageHandler and change the convert call.

The easy way is to do load balancing and scale horizontally, but if
we can find some ways to reduce the image conversion load that is very
nice.

/robo

[Robert Olofsson]

On Tue, 20 Oct 2009 19:00:34 +0200

Post by Robert Olofsson

Post by Артур Хуснутдинов
Recently I developed a compressive other proxies for C ++. I have an
opportunity to give you the code responsible for compression of images.
Checked that our proxy for a load of 1500 users using 50-70% CPU, for
example, Core2Duo 2.33 GHz. Expect that it will be possible not to use
ImageMagic, and include in the set of our small piece of code in C ++ for
compressing images.

If you know how to code java it is probably quite easy for you to hook
into/subclass ImageHandler and change the convert call.

One thing that would be easy to do is to have an external pool of image
converters that we can call.
Something like ImageHandler holding 10-20 convert processes alive and
when it is time to convert one image grab a converter from the pool and
tell it to run. That would mean no forking and startup and still mean
that when a convert process dies the proxy still lives on.
I do not know of any command line options to convert that can do this,
but maybe there are other image converters that can. It is also possible
to write a small C/C++ wrapper for convert to handle this.

/robo

[Robert Olofsson]

On Tue, 20 Oct 2009 19:00:34 +0200

Post by Robert Olofsson
If you want to look for alternatives I can suggest the graphicsmagick
suite (it is a fork from imagemagick, so probably very easy to try out)
http://www.exactcode.de/site/open_source/exactimage/

I did a quick try with exactimage and I could not get it to work very well.
It did work on a few images and did not work on quite a big number.

GraphicsMagick works well though, I do not have any high load so I can
not really say if it using less resources, but it is trivial to test with
it, all you have to do is
1) install the graphicsmagick suite
2) change the rabbit.conf:
--------------------------------------------------
[rabbit.handler.ImageHandler*jpeg]
convert=/usr/bin/gm
convertargs=convert -quality 10 -flatten $filename +profile "*" jpeg:$filename.c
min_size=2000

[rabbit.handler.ImageHandler*gif]
convert=/usr/bin/gm
convertargs=convert -quality 10 -flatten $filename +profile "*" jpeg:$filename.c
min_size=2000

[rabbit.handler.ImageHandler*png]
convert=/usr/bin/gm
convertargs=convert -quality 10 -flatten $filename +profile "*" jpeg:$filename.c
min_size=2000
--------------------------------------------------

Since this is easy to change/change back I would suggest testing it.

/robo

[Robert Olofsson]

On Tue, 20 Oct 2009 19:00:34 +0200

Post by Robert Olofsson

Post by Артур Хуснутдинов
Recently I developed a compressive other proxies for C ++. I have an
opportunity to give you the code responsible for compression of images.
Checked that our proxy for a load of 1500 users using 50-70% CPU, for
example, Core2Duo 2.33 GHz. Expect that it will be possible not to use
ImageMagic, and include in the set of our small piece of code in C ++ for
compressing images.

If you know how to code java it is probably quite easy for you to hook
into/subclass ImageHandler and change the convert call.

One thing that would be easy to do is to have an external pool of image
converters that we can call.
Something like ImageHandler holding 10-20 convert processes alive and
when it is time to convert one image grab a converter from the pool and
tell it to run. That would mean no forking and startup and still mean
that when a convert process dies the proxy still lives on.
I do not know of any command line options to convert that can do this,
but maybe there are other image converters that can. It is also possible
to write a small C/C++ wrapper for convert to handle this.

/robo

[Robert Olofsson]

On Tue, 20 Oct 2009 19:00:34 +0200

Post by Robert Olofsson
If you want to look for alternatives I can suggest the graphicsmagick
suite (it is a fork from imagemagick, so probably very easy to try out)
http://www.exactcode.de/site/open_source/exactimage/

I did a quick try with exactimage and I could not get it to work very well.
It did work on a few images and did not work on quite a big number.

GraphicsMagick works well though, I do not have any high load so I can
not really say if it using less resources, but it is trivial to test with
it, all you have to do is
1) install the graphicsmagick suite
2) change the rabbit.conf:
--------------------------------------------------
[rabbit.handler.ImageHandler*jpeg]
convert=/usr/bin/gm
convertargs=convert -quality 10 -flatten $filename +profile "*" jpeg:$filename.c
min_size=2000

[rabbit.handler.ImageHandler*gif]
convert=/usr/bin/gm
convertargs=convert -quality 10 -flatten $filename +profile "*" jpeg:$filename.c
min_size=2000

[rabbit.handler.ImageHandler*png]
convert=/usr/bin/gm
convertargs=convert -quality 10 -flatten $filename +profile "*" jpeg:$filename.c
min_size=2000
--------------------------------------------------

Since this is easy to change/change back I would suggest testing it.

/robo

[Robert Olofsson]

On Tue, 20 Oct 2009 19:00:34 +0200

Post by Robert Olofsson

Post by Артур Хуснутдинов
Recently I developed a compressive other proxies for C ++. I have an
opportunity to give you the code responsible for compression of images.
Checked that our proxy for a load of 1500 users using 50-70% CPU, for
example, Core2Duo 2.33 GHz. Expect that it will be possible not to use
ImageMagic, and include in the set of our small piece of code in C ++ for
compressing images.

If you know how to code java it is probably quite easy for you to hook
into/subclass ImageHandler and change the convert call.

One thing that would be easy to do is to have an external pool of image
converters that we can call.
Something like ImageHandler holding 10-20 convert processes alive and
when it is time to convert one image grab a converter from the pool and
tell it to run. That would mean no forking and startup and still mean
that when a convert process dies the proxy still lives on.
I do not know of any command line options to convert that can do this,
but maybe there are other image converters that can. It is also possible
to write a small C/C++ wrapper for convert to handle this.

/robo

[Robert Olofsson]

On Tue, 20 Oct 2009 19:00:34 +0200

Post by Robert Olofsson
If you want to look for alternatives I can suggest the graphicsmagick
suite (it is a fork from imagemagick, so probably very easy to try out)
http://www.exactcode.de/site/open_source/exactimage/

I did a quick try with exactimage and I could not get it to work very well.
It did work on a few images and did not work on quite a big number.

GraphicsMagick works well though, I do not have any high load so I can
not really say if it using less resources, but it is trivial to test with
it, all you have to do is
1) install the graphicsmagick suite
2) change the rabbit.conf:
--------------------------------------------------
[rabbit.handler.ImageHandler*jpeg]
convert=/usr/bin/gm
convertargs=convert -quality 10 -flatten $filename +profile "*" jpeg:$filename.c
min_size=2000

[rabbit.handler.ImageHandler*gif]
convert=/usr/bin/gm
convertargs=convert -quality 10 -flatten $filename +profile "*" jpeg:$filename.c
min_size=2000

[rabbit.handler.ImageHandler*png]
convert=/usr/bin/gm
convertargs=convert -quality 10 -flatten $filename +profile "*" jpeg:$filename.c
min_size=2000
--------------------------------------------------

Since this is easy to change/change back I would suggest testing it.

/robo

[Артур Хуснутдинов]

Hello, Dev's.
I have one big question:
After the testing on proxy with the 500 users, I see, what RabbIT have lags
(too low speed).
I know that the slow processing associated with the use of my options
include compression of images with the help of ImageMagic. The inclusion
ImageMagic proxy starts slow, and there is a lot of memory processes
ImageMagic, which strongly uses the CPU and RAM. Will the time soon to write
a separate Java or C++ image processor to reduce the load on the CPU and
RAM, and reduce delays?
Recently I developed a compressive other proxies for C ++. I have an
opportunity to give you the code responsible for compression of images.
Checked that our proxy for a load of 1500 users using 50-70% CPU, for
example, Core2Duo 2.33 GHz. Expect that it will be possible not to use
ImageMagic, and include in the set of our small piece of code in C ++ for
compressing images.
Sorry my English.

[Mindaugas Žakšauskas]

??????,

If the problem you are solving is scalability (the system becomes too
slow under a huge load), why don't you just throw another box in
(horizontal scaling) or buy better hardware?

Balancing the load among the different nodes should be trivial as
Rabbit doesn't preserve the state between different HTTP requests, so
a simple DNS round robin would do.

I might not be the best person to tell this, but I think that any
image transformation activity is out of the scope of this project. If
you feel like sharing some good code, why not create another open
source project and claim it's seamless integration with Rabbit?

m.

Post by Артур Хуснутдинов
Hello, Dev's.
After the testing on proxy with the 500 users, I see, what RabbIT have lags
(too low speed).
I know that the slow processing associated with the use of my options
include compression of images with the help of ImageMagic. The inclusion
ImageMagic proxy starts slow, and there is a lot of memory processes
ImageMagic, which strongly uses the CPU and RAM. Will the time soon to write
a separate Java or C++ image processor to reduce the load on the CPU and
RAM, and reduce delays?
?Recently I developed a compressive other proxies for C ++. I have an
opportunity to give you the code responsible for compression of images.
Checked that our proxy for a load of 1500 users using 50-70% CPU, for
example, Core2Duo 2.33 GHz. Expect that it will be possible not to use
ImageMagic, and include in the set of our small piece of code in C ++ for
compressing images.
Sorry my English.
--
? ?????????,. ArtUrlWWW
_______________________________________________
Rabbit-dev mailing list
Rabbit-dev at khelekore.org
http://khelekore.org/cgi-bin/mailman/listinfo/rabbit-dev

[Robert Olofsson]

On Tue, 20 Oct 2009 15:39:16 +0500

Post by Артур Хуснутдинов
Hello, Dev's.
After the testing on proxy with the 500 users, I see, what RabbIT have lags
(too low speed).

Ok, I do not have the users to test like that, I only run a small instance
of rabbit so it will be hard for me to really test like that.

Post by Артур Хуснутдинов
I know that the slow processing associated with the use of my options
include compression of images with the help of ImageMagic.

Yes, rabbit uses imagemagic by default, you are very much free to try
out alternatives. I know that convert is not the fastest or most memory
efficient program so it may well be worthwhile to try some alternatives
out.

There are a few different reasons why forking off a convert-process was
done, one of the biggest was that image conversion is heavy, so if the
converter program dies with out-of-memory we do not want the proxy to die.

If you want to look for alternatives I can suggest the graphicsmagick
suite (it is a fork from imagemagick, so probably very easy to try out)
Another alternative that may be useful is ExactImage:
http://www.exactcode.de/site/open_source/exactimage/

Post by Артур Хуснутдинов
Recently I developed a compressive other proxies for C ++. I have an
opportunity to give you the code responsible for compression of images.
Checked that our proxy for a load of 1500 users using 50-70% CPU, for
example, Core2Duo 2.33 GHz. Expect that it will be possible not to use
ImageMagic, and include in the set of our small piece of code in C ++ for
compressing images.

If you know how to code java it is probably quite easy for you to hook
into/subclass ImageHandler and change the convert call.

The easy way is to do load balancing and scale horizontally, but if
we can find some ways to reduce the image conversion load that is very
nice.

/robo

[Артур Хуснутдинов]

Hello, Dev's.
I have one big question:
After the testing on proxy with the 500 users, I see, what RabbIT have lags
(too low speed).
I know that the slow processing associated with the use of my options
include compression of images with the help of ImageMagic. The inclusion
ImageMagic proxy starts slow, and there is a lot of memory processes
ImageMagic, which strongly uses the CPU and RAM. Will the time soon to write
a separate Java or C++ image processor to reduce the load on the CPU and
RAM, and reduce delays?
Recently I developed a compressive other proxies for C ++. I have an
opportunity to give you the code responsible for compression of images.
Checked that our proxy for a load of 1500 users using 50-70% CPU, for
example, Core2Duo 2.33 GHz. Expect that it will be possible not to use
ImageMagic, and include in the set of our small piece of code in C ++ for
compressing images.
Sorry my English.

[Mindaugas Žakšauskas]

??????,

If the problem you are solving is scalability (the system becomes too
slow under a huge load), why don't you just throw another box in
(horizontal scaling) or buy better hardware?

Balancing the load among the different nodes should be trivial as
Rabbit doesn't preserve the state between different HTTP requests, so
a simple DNS round robin would do.

I might not be the best person to tell this, but I think that any
image transformation activity is out of the scope of this project. If
you feel like sharing some good code, why not create another open
source project and claim it's seamless integration with Rabbit?

m.

Post by Артур Хуснутдинов
Hello, Dev's.
After the testing on proxy with the 500 users, I see, what RabbIT have lags
(too low speed).
I know that the slow processing associated with the use of my options
include compression of images with the help of ImageMagic. The inclusion
ImageMagic proxy starts slow, and there is a lot of memory processes
ImageMagic, which strongly uses the CPU and RAM. Will the time soon to write
a separate Java or C++ image processor to reduce the load on the CPU and
RAM, and reduce delays?
?Recently I developed a compressive other proxies for C ++. I have an
opportunity to give you the code responsible for compression of images.
Checked that our proxy for a load of 1500 users using 50-70% CPU, for
example, Core2Duo 2.33 GHz. Expect that it will be possible not to use
ImageMagic, and include in the set of our small piece of code in C ++ for
compressing images.
Sorry my English.
--
? ?????????,. ArtUrlWWW
_______________________________________________
Rabbit-dev mailing list
Rabbit-dev at khelekore.org
http://khelekore.org/cgi-bin/mailman/listinfo/rabbit-dev

[Robert Olofsson]

On Tue, 20 Oct 2009 15:39:16 +0500

Post by Артур Хуснутдинов
Hello, Dev's.
After the testing on proxy with the 500 users, I see, what RabbIT have lags
(too low speed).

Ok, I do not have the users to test like that, I only run a small instance
of rabbit so it will be hard for me to really test like that.

Post by Артур Хуснутдинов
I know that the slow processing associated with the use of my options
include compression of images with the help of ImageMagic.

Yes, rabbit uses imagemagic by default, you are very much free to try
out alternatives. I know that convert is not the fastest or most memory
efficient program so it may well be worthwhile to try some alternatives
out.

There are a few different reasons why forking off a convert-process was
done, one of the biggest was that image conversion is heavy, so if the
converter program dies with out-of-memory we do not want the proxy to die.

If you want to look for alternatives I can suggest the graphicsmagick
suite (it is a fork from imagemagick, so probably very easy to try out)
Another alternative that may be useful is ExactImage:
http://www.exactcode.de/site/open_source/exactimage/

Post by Артур Хуснутдинов
Recently I developed a compressive other proxies for C ++. I have an
opportunity to give you the code responsible for compression of images.
Checked that our proxy for a load of 1500 users using 50-70% CPU, for
example, Core2Duo 2.33 GHz. Expect that it will be possible not to use
ImageMagic, and include in the set of our small piece of code in C ++ for
compressing images.

If you know how to code java it is probably quite easy for you to hook
into/subclass ImageHandler and change the convert call.

The easy way is to do load balancing and scale horizontally, but if
we can find some ways to reduce the image conversion load that is very
nice.

/robo

[Robert Olofsson]

On Tue, 20 Oct 2009 15:39:16 +0500

Post by Артур Хуснутдинов
Hello, Dev's.
I know that the slow processing associated with the use of my options
include compression of images with the help of ImageMagic. The inclusion
ImageMagic proxy starts slow, and there is a lot of memory processes
ImageMagic, which strongly uses the CPU and RAM. Will the time soon to write

Did you have any time to try out the java based image converter?
With 4.3-pre-5 it even has some type of memory usage protection.
I have been running with the java based conversion for some time
and it seems to work ok for my usage, but what do I know.

Anyone else that can see any difference in speed/cpu usage/image
quality/<other>?

/robo

[Samat K Jain]

Post by Robert Olofsson
Did you have any time to try out the java based image converter?
With 4.3-pre-5 it even has some type of memory usage protection.
I have been running with the java based conversion for some time
and it seems to work ok for my usage, but what do I know.
Anyone else that can see any difference in speed/cpu usage/image
quality/<other>?

I've been using it for about a week and a half.

I haven't noticed any differences in speed or CPU usage, but it feels like image quality is lower (I haven't quantitatively tested). With 4.3-pre-2 there was also some issue where certain images would recompress with a strong red tint (fixed in recent builds).
--
Samat K Jain <http://samat.org/> | GPG: 0x0x4A456FBA

How's the wife? Is she at home enjoying capitalism?
-- None (136)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: <http://khelekore.org/pipermail/rabbit-dev/attachments/20091110/fd993e72/attachment.pgp>

[Robert Olofsson]

On Tue, 10 Nov 2009 17:13:52 -0700

Post by Samat K Jain

Post by Robert Olofsson
Did you have any time to try out the java based image converter?
With 4.3-pre-5 it even has some type of memory usage protection.
I have been running with the java based conversion for some time
and it seems to work ok for my usage, but what do I know.
Anyone else that can see any difference in speed/cpu usage/image
quality/<other>?

I've been using it for about a week and a half.
I haven't noticed any differences in speed or CPU usage, but it feels like image quality is lower (I haven't quantitatively tested). With 4.3-pre-2 there was also some issue where certain images would recompress with a strong red tint (fixed in recent builds).

Ok, since I wanted to know I wrote a small benchmarking program
that times image conversion.
The results are not really what I expected.
The java based converter is _much_ faster on my machine.

Small image 6550 bytes:
ImageMagick convert took 160112 millis, on average: 160.112 millis
JavaConvert convert took 2320 millis, on average: 2.32 millis

Medium sized image 112326 bytes:
ImageMagick convert took 172001 millis, on average: 172.001 millis
JavaConvert convert took 73231 millis, on average: 73.231 millis

Medium sized image, 160928 bytes:
ImageMagick convert took 199568 millis, on average: 199.568 millis
JavaConvert convert took 33531 millis, on average: 33.531 millis

Big image, 3066439 bytes:
ImageMagick convert took 979269 millis, on average: 979.269 millis
JavaConvert convert took 504584 millis, on average: 504.584 millis

The output is reasonably similar, the java based converter tend to
output slightly larger files (.c = convert, .j = java based)

-rw-r--r-- 1 robo robo 3066439 2009-11-14 16:10 big.jpg
-rw-r--r-- 1 robo robo 123766 2009-11-14 16:11 big.jpg.c
-rw-r--r-- 1 robo robo 170232 2009-11-14 16:11 big.jpg.j
-rw-r--r-- 1 robo robo 112326 2009-11-14 15:38 kreml.jpg
-rw-r--r-- 1 robo robo 12759 2009-11-14 15:45 kreml.jpg.c
-rw-r--r-- 1 robo robo 12237 2009-11-14 15:42 kreml.jpg.j
-rw-r--r-- 1 robo robo 160928 2009-11-14 16:10 pa030039.jpg
-rw-r--r-- 1 robo robo 15601 2009-11-14 15:54 pa030039.jpg.c
-rw-r--r-- 1 robo robo 18226 2009-11-14 15:50 pa030039.jpg.j
-rw-r--r-- 1 robo robo 6550 2009-11-14 15:07 ps.jpg
-rw-r--r-- 1 robo robo 1317 2009-11-14 15:40 ps.jpg.c
-rw-r--r-- 1 robo robo 1801 2009-11-14 15:37 ps.jpg.j

Running GraphicsMagick I see a much better times, small image:
GraphicsMagick convert took 13039 millis, on average: 13.039 millis
JavaConvert convert took 2486 millis, on average: 2.486 millis

Medium image 1:
GraphicsMagick convert took 32332 millis, on average: 32.332 millis
JavaConvert convert took 73218 millis, on average: 73.218 millis

Medium image 2:
GraphicsMagick convert took 44901 millis, on average: 44.901 millis
JavaConvert convert took 35046 millis, on average: 35.046 millis

The red tint most probably comes from transparent backgrounds,
I have made no changes to handle it better.

So as it is now, I would probably suggest running graphicsmagick.
The java based converter is probably faster for small to medium
sized images, but image quality may be a bit worse and image sizes
are a bit bigger, so in all graphicsmagick looks like the win for
now.

/robo

[Robert Olofsson]

On Tue, 10 Nov 2009 17:13:52 -0700

Post by Samat K Jain

Post by Robert Olofsson
Did you have any time to try out the java based image converter?
With 4.3-pre-5 it even has some type of memory usage protection.
I have been running with the java based conversion for some time
and it seems to work ok for my usage, but what do I know.
Anyone else that can see any difference in speed/cpu usage/image
quality/<other>?

I've been using it for about a week and a half.
I haven't noticed any differences in speed or CPU usage, but it feels like image quality is lower (I haven't quantitatively tested). With 4.3-pre-2 there was also some issue where certain images would recompress with a strong red tint (fixed in recent builds).

Ok, since I wanted to know I wrote a small benchmarking program
that times image conversion.
The results are not really what I expected.
The java based converter is _much_ faster on my machine.

Small image 6550 bytes:
ImageMagick convert took 160112 millis, on average: 160.112 millis
JavaConvert convert took 2320 millis, on average: 2.32 millis

Medium sized image 112326 bytes:
ImageMagick convert took 172001 millis, on average: 172.001 millis
JavaConvert convert took 73231 millis, on average: 73.231 millis

Medium sized image, 160928 bytes:
ImageMagick convert took 199568 millis, on average: 199.568 millis
JavaConvert convert took 33531 millis, on average: 33.531 millis

Big image, 3066439 bytes:
ImageMagick convert took 979269 millis, on average: 979.269 millis
JavaConvert convert took 504584 millis, on average: 504.584 millis

The output is reasonably similar, the java based converter tend to
output slightly larger files (.c = convert, .j = java based)

-rw-r--r-- 1 robo robo 3066439 2009-11-14 16:10 big.jpg
-rw-r--r-- 1 robo robo 123766 2009-11-14 16:11 big.jpg.c
-rw-r--r-- 1 robo robo 170232 2009-11-14 16:11 big.jpg.j
-rw-r--r-- 1 robo robo 112326 2009-11-14 15:38 kreml.jpg
-rw-r--r-- 1 robo robo 12759 2009-11-14 15:45 kreml.jpg.c
-rw-r--r-- 1 robo robo 12237 2009-11-14 15:42 kreml.jpg.j
-rw-r--r-- 1 robo robo 160928 2009-11-14 16:10 pa030039.jpg
-rw-r--r-- 1 robo robo 15601 2009-11-14 15:54 pa030039.jpg.c
-rw-r--r-- 1 robo robo 18226 2009-11-14 15:50 pa030039.jpg.j
-rw-r--r-- 1 robo robo 6550 2009-11-14 15:07 ps.jpg
-rw-r--r-- 1 robo robo 1317 2009-11-14 15:40 ps.jpg.c
-rw-r--r-- 1 robo robo 1801 2009-11-14 15:37 ps.jpg.j

Running GraphicsMagick I see a much better times, small image:
GraphicsMagick convert took 13039 millis, on average: 13.039 millis
JavaConvert convert took 2486 millis, on average: 2.486 millis

Medium image 1:
GraphicsMagick convert took 32332 millis, on average: 32.332 millis
JavaConvert convert took 73218 millis, on average: 73.218 millis

Medium image 2:
GraphicsMagick convert took 44901 millis, on average: 44.901 millis
JavaConvert convert took 35046 millis, on average: 35.046 millis

The red tint most probably comes from transparent backgrounds,
I have made no changes to handle it better.

So as it is now, I would probably suggest running graphicsmagick.
The java based converter is probably faster for small to medium
sized images, but image quality may be a bit worse and image sizes
are a bit bigger, so in all graphicsmagick looks like the win for
now.

/robo

[Robert Olofsson]

On Tue, 10 Nov 2009 17:13:52 -0700

Post by Samat K Jain

Post by Robert Olofsson
Did you have any time to try out the java based image converter?
With 4.3-pre-5 it even has some type of memory usage protection.
I have been running with the java based conversion for some time
and it seems to work ok for my usage, but what do I know.
Anyone else that can see any difference in speed/cpu usage/image
quality/<other>?

I've been using it for about a week and a half.
I haven't noticed any differences in speed or CPU usage, but it feels like image quality is lower (I haven't quantitatively tested). With 4.3-pre-2 there was also some issue where certain images would recompress with a strong red tint (fixed in recent builds).

Ok, since I wanted to know I wrote a small benchmarking program
that times image conversion.
The results are not really what I expected.
The java based converter is _much_ faster on my machine.

Small image 6550 bytes:
ImageMagick convert took 160112 millis, on average: 160.112 millis
JavaConvert convert took 2320 millis, on average: 2.32 millis

Medium sized image 112326 bytes:
ImageMagick convert took 172001 millis, on average: 172.001 millis
JavaConvert convert took 73231 millis, on average: 73.231 millis

Medium sized image, 160928 bytes:
ImageMagick convert took 199568 millis, on average: 199.568 millis
JavaConvert convert took 33531 millis, on average: 33.531 millis

Big image, 3066439 bytes:
ImageMagick convert took 979269 millis, on average: 979.269 millis
JavaConvert convert took 504584 millis, on average: 504.584 millis

The output is reasonably similar, the java based converter tend to
output slightly larger files (.c = convert, .j = java based)

-rw-r--r-- 1 robo robo 3066439 2009-11-14 16:10 big.jpg
-rw-r--r-- 1 robo robo 123766 2009-11-14 16:11 big.jpg.c
-rw-r--r-- 1 robo robo 170232 2009-11-14 16:11 big.jpg.j
-rw-r--r-- 1 robo robo 112326 2009-11-14 15:38 kreml.jpg
-rw-r--r-- 1 robo robo 12759 2009-11-14 15:45 kreml.jpg.c
-rw-r--r-- 1 robo robo 12237 2009-11-14 15:42 kreml.jpg.j
-rw-r--r-- 1 robo robo 160928 2009-11-14 16:10 pa030039.jpg
-rw-r--r-- 1 robo robo 15601 2009-11-14 15:54 pa030039.jpg.c
-rw-r--r-- 1 robo robo 18226 2009-11-14 15:50 pa030039.jpg.j
-rw-r--r-- 1 robo robo 6550 2009-11-14 15:07 ps.jpg
-rw-r--r-- 1 robo robo 1317 2009-11-14 15:40 ps.jpg.c
-rw-r--r-- 1 robo robo 1801 2009-11-14 15:37 ps.jpg.j

Running GraphicsMagick I see a much better times, small image:
GraphicsMagick convert took 13039 millis, on average: 13.039 millis
JavaConvert convert took 2486 millis, on average: 2.486 millis

Medium image 1:
GraphicsMagick convert took 32332 millis, on average: 32.332 millis
JavaConvert convert took 73218 millis, on average: 73.218 millis

Medium image 2:
GraphicsMagick convert took 44901 millis, on average: 44.901 millis
JavaConvert convert took 35046 millis, on average: 35.046 millis

The red tint most probably comes from transparent backgrounds,
I have made no changes to handle it better.

So as it is now, I would probably suggest running graphicsmagick.
The java based converter is probably faster for small to medium
sized images, but image quality may be a bit worse and image sizes
are a bit bigger, so in all graphicsmagick looks like the win for
now.

/robo

[Samat K Jain]

Post by Robert Olofsson
Did you have any time to try out the java based image converter?
With 4.3-pre-5 it even has some type of memory usage protection.
I have been running with the java based conversion for some time
and it seems to work ok for my usage, but what do I know.
Anyone else that can see any difference in speed/cpu usage/image
quality/<other>?

I've been using it for about a week and a half.

I haven't noticed any differences in speed or CPU usage, but it feels like image quality is lower (I haven't quantitatively tested). With 4.3-pre-2 there was also some issue where certain images would recompress with a strong red tint (fixed in recent builds).
--
Samat K Jain <http://samat.org/> | GPG: 0x0x4A456FBA

How's the wife? Is she at home enjoying capitalism?
-- None (136)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: <http://khelekore.org/pipermail/rabbit-dev/attachments/20091110/fd993e72/attachment-0002.pgp>

[Samat K Jain]

Post by Robert Olofsson
Did you have any time to try out the java based image converter?
With 4.3-pre-5 it even has some type of memory usage protection.
I have been running with the java based conversion for some time
and it seems to work ok for my usage, but what do I know.
Anyone else that can see any difference in speed/cpu usage/image
quality/<other>?

I've been using it for about a week and a half.

I haven't noticed any differences in speed or CPU usage, but it feels like image quality is lower (I haven't quantitatively tested). With 4.3-pre-2 there was also some issue where certain images would recompress with a strong red tint (fixed in recent builds).
--
Samat K Jain <http://samat.org/> | GPG: 0x0x4A456FBA

How's the wife? Is she at home enjoying capitalism?
-- None (136)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: <http://khelekore.org/pipermail/rabbit-dev/attachments/20091110/fd993e72/attachment-0003.pgp>

[Robert Olofsson]

On Tue, 20 Oct 2009 15:39:16 +0500

Post by Артур Хуснутдинов
Hello, Dev's.
I know that the slow processing associated with the use of my options
include compression of images with the help of ImageMagic. The inclusion
ImageMagic proxy starts slow, and there is a lot of memory processes
ImageMagic, which strongly uses the CPU and RAM. Will the time soon to write

Did you have any time to try out the java based image converter?
With 4.3-pre-5 it even has some type of memory usage protection.
I have been running with the java based conversion for some time
and it seems to work ok for my usage, but what do I know.

Anyone else that can see any difference in speed/cpu usage/image
quality/<other>?

/robo

[Robert Olofsson]

On Tue, 20 Oct 2009 15:39:16 +0500

Post by Артур Хуснутдинов
Hello, Dev's.
I know that the slow processing associated with the use of my options
include compression of images with the help of ImageMagic. The inclusion
ImageMagic proxy starts slow, and there is a lot of memory processes
ImageMagic, which strongly uses the CPU and RAM. Will the time soon to write

Did you have any time to try out the java based image converter?
With 4.3-pre-5 it even has some type of memory usage protection.
I have been running with the java based conversion for some time
and it seems to work ok for my usage, but what do I know.

Anyone else that can see any difference in speed/cpu usage/image
quality/<other>?

/robo