Пул процессов в im4java

Question

Ребята я использую библиотеку imagemagick для обработки изображений в моем проекте (Java). Когда несколько запросов попадают на сервер, он отвечает очень медленно. Теперь несколько convert Команды (выполняются как отдельный процесс) выполняются одновременно и во избежание задержки думаю о process pooling в im4java. Следующие альтернативы были бы полезны?:

• Объединение процессов в im4java - Есть ли способ достичь исключительно в im4java(должен ли я использовать упаковщик gm4java, я думаю, что он поддерживает объединение процессов - НО, у него есть несколько ограничений, например, отсутствие использования буферизованных изображений)?
• Выделенный сервер - Использование выделенного сервера только для обработки изображений (по меньшей мере, я хочу).

  ---

Есть ли какой-либо другой метод, я должен пойти? Спасибо за помощь заранее!

Answer 1

На самом деле наша команда выполнила точно такое же требование, и поэтому мы создали gm4java. Это именно то, что вы ищете. Что касается поддержки BufferedImage, мы уже поддерживаем использование BufferedImage в качестве входных данных в последней версии. Использование BufferedImage в качестве вывода все еще не поддерживается, но вы можете легко обойти его.

Обходной путь - позволить GM записать образ на RAM-диск (во многих дистрибутивах Linux вы получаете RAM-диск бесплатно, для Windows доступны различные решения). Все, что вам нужно сделать сейчас, это чтобы ваш Java-код считывал преобразованный образ с RAM-диска. Маленькие накладные расходы (если таковые имеются) - безразличие по сравнению с огромными накладными расходами на запуск нового процесса каждый раз.

Даже при прямом сравнении с подходом RAM-диска к BufferedImage размер BufferedImage часто в 10 раз больше, чем байтовый массив файла изображения JPG. Таким образом, если все, что вам нужно, это обслуживать изображения, а не выполнять дополнительную обработку в Java, то подход к RAM-диску действительно быстрее и использует меньше памяти.

Подробнее о текущей реализации BufferedImage в im4java. При использовании его в качестве входных данных он просто записывался в файл tmp, что очень медленно. При использовании в качестве вывода он использует потоковые операции stdin/stdout, которые быстрее, чем файл tmp, но все же не оптимальны. Лучше всего было бы использовать именованный канал с реализацией Java NIO. Но для этого потребуется немало, в частности, взлом API, изменений в im4java.

Наконец, я бы НЕ рассматривал gm4java как обертку для im4java, ядро ​​gm4java запускается само по себе и дает вам возможность отправлять массивные параллельные команды в GM и возвращать вывод GM вам. Команды - это просто список строк, поэтому, если вы знаете, как писать команды GM, вам не нужен im4java для использования gm4java. Это на самом деле, как мы использовали в приложении, которое требует сырой производительности. im4java дает вам удобный способ (с некоторыми накладными расходами) для создания команды GM и для анализа вывода GM. Класс GMBatchCommand в gm4java служит мостом между im4java и gm4java. Это позволяет использовать это удобство из im4java для создания команд, а затем использовать механизм gm4java для выполнения команды. Движок gm4java использует совершенно другой механизм, чем im4java, для управления и связи с GM. И это причина, почему это так быстро.