Question

Guys am using imagemagick library for image processing in my project(java). When multiple requests hit the server, it responds very slowly. Now, multiple convert commands ( executes as an individual process ) are executed simultaneously and to avoid delay am thinking of process pooling in im4java. Following alternatives would be of any help ? :

  • Process Pooling in im4java - Is there any way to achieve solely in im4java(should i use gm4java wrapper, i guess it supports process pooling - BUT, it has few limitations like no use of buffered images)?
  • Dedicated Server - Using a dedicated server just for image processing (the least i want).

Is there any OTHER method should i go for ? Thanks for help in advance !

Était-ce utile?

La solution

Actually, our team went through exactly the same requirement and hence we created gm4java. It does exactly what you are looking for. As to the support for BufferedImage, we already support using BufferedImage as input in the latest release. Using BufferedImage as output is still not supported but you can workaround it easily.

The workaround is to let GM write the image to the RAM disk (in many Linux distributions, you get RAM disk for free, for Windows there are various solutions available). All you need to do now is to have your Java code reads the converted image from the RAM disk. The little overhead (if any) is indifference comparing to the huge overhead of starting a new process each time.

Even directly comparing with RAM disk approach to BufferedImage, the size of BufferedImage is often 10 times larger than a byte array of a JPG image file. So if all you need is to serve images instead of doing additional processing in Java, the RAM disk approach is indeed faster also uses less memory.

More about current BufferedImage implementation in im4java. When using it as input, it was simply written to a tmp file, which is very slow. When using it as output, it utilizes stdin/stdout stream operations, which is faster than tmp file but still not optimal. The best would be to use named pipe with Java NIO implementation. But that will require quite a bit of, most like API breaking, changes in im4java.

Lastly, I would NOT consider gm4java a wrapper of im4java, the core of gm4java runs by itself and gives you the capability of sending massive concurrent commands to GM and to return the output of GM back to you. Commands are just a list of strings, so if you know how to write GM commands, you don't need im4java to use gm4java. That is actually how we used in an application that demands raw performance. im4java give you a convenience way (with some overhead) to construct the GM command and to parse the GM output. GMBatchCommand class in gm4java serves a bridge between im4java and gm4java. It let you use that convenience from im4java to construct the commands, then use gm4java engine to execute the command. The gm4java engine uses a completely different mechanism than im4java to manage and to communicate with GM. And that's the reason why it is so fast.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top