mbg-opendocument-[server|client]
Внимание: при изменении версии openoffice необходимо переустановить пакет odtfactory-server.
Внимание: пакеты переименованы и создан отдельный пакет с файлом конфигурации:
odtfactory-client odtfactory-config odtfactory-server
Ограничения для отдельного процесса конвертации (для одностраничного шаблона нужно около 200 Mb памяти, которые занимают openoffice и ява, а с указанными настройками можно обрабатывать достаточно большие документы):
Размер выходного файла не может превышать 8 Mb, для подавляющего большинства применений этого лимита хватает с избытком.
Обработчик каждого формата принимает не более 3-х одновременных подключений (настраивается в /etc/service/odt2*/run скриптах).
Архитектура
Клиент-серверное взаимодействие выполняется путем двусторонней передачи бинарных файлов, при этом никакая служебная информация не передается. Для контроля целостности файлов на стороне клиента и сервера следует воспользоваться анализаторами для файлов соответствующего формата (например, см. статью Работа с файлами формата OpenDocument).
odtfactory-server - принимает через сокет файл формата OpenDocument на обработку и возвращает в требуемом формате. Для каждого типа результирующих документов используется отдельный порт.
Настройки по умолчанию:
Здесь переменная LANG может быть необходима для openoffice (если при конвертации выдает ошибки определения локали, нужно раскомментировать эту строку в конфиге).
На сервере odtfactory-server обработка производится с использованием 2-х временных файлов (оригинального и результирующего).
odtfactory-client - отправляет файл серверу и принимает результат.
На клиенте можно открыть пайп и читать данные, или сохранить во временный файл. Исходные данные могут быть как получены из пайпа, так и из файла.
odt2doc@, odt2pdf@ - утилиты для преобразования OpenDocument файла в соответствующий формат, выполняют пересылку файла серверу и принимают результат.
Тесты на ноутбуке Core2Duo, частота 800 MHz, 1Gb RAM:
С более новым openoffice:
И с последней версией openoffice:
По возможности стоит использовать свежую версию openoffice, т.к. разница в быстродействии очень значительна.
Upd.
Если преобразование не работает, или первой строкой в созданном файле указано javaldx: Could not find a Java Runtime Environment!, следует проверить, что в профиле openoffice правильно определена java:
Случается такое, что после установки openoffice ява никоими манипуляциями не находится и тогда в указанном файле профиля нужных строк нет. Рекомендую выполнить вот такую команду:
В общем, черт бы побрал эту яву и программистов на побочных эффектах.
Итак, вот как выглядит "лечение":
Как видим, ява успешно нашлась, и все заработало, но не спрашивайте меня, почему.
Upd.
На сервере с процессором Intel(R) Core(TM)2 Quad CPU Q6700 @ 2.66GHz имеем следующие показатели:
Если сравнить с результатом на ноутбуке (см. выше), то мы получили практически линейную зависимость от частоты. Таким образом, несложно подсчитать, что openoffice 3.2 на CoreQuad обработает тот же файл примерно за полсекунды.
Upd.
openoffice 2.3 можно запустить и без виртуальных иксов, установив пакет openoffice.org-headless.
А если запускать напрямую /usr/lib/openoffice/program/soffice.bin, то выполнение команды окажется примерно на треть быстрее (для простых документов, когда запуск openoffice занимает львиную долю времени). Тест на том же сервере:
Примечание: Категорически не рекомендую пытаться использовать управляющий сокет openoffice! Во-первых, при работе с ним наблюдается утечка памяти. Во-вторых, протокол часто меняется, что приводит к невозможности обновить версию openoffice (например, когда я отладил работу tcluno с ooo 2.3, с ooo 2.4 эта библиотека отказалась работать из-за изменения версии протокола).
По результатам своих тестов могу утверждать - для неадминистрируемого сервера единственный вариант - запускать отдельный процесс openoffice для каждой конвертации. На сервере с процессором CoreQuad и 8Gb RAM ежедневная конвертация нескольких тысяч документов не создает никакой ощутимой нагрузки.
Внимание: пакеты переименованы и создан отдельный пакет с файлом конфигурации:
odtfactory-client odtfactory-config odtfactory-server
Ограничения для отдельного процесса конвертации (для одностраничного шаблона нужно около 200 Mb памяти, которые занимают openoffice и ява, а с указанными настройками можно обрабатывать достаточно большие документы):
ulimit -m 300000 ulimit -v 300000 ulimit -f 2000
Размер выходного файла не может превышать 8 Mb, для подавляющего большинства применений этого лимита хватает с избытком.
Обработчик каждого формата принимает не более 3-х одновременных подключений (настраивается в /etc/service/odt2*/run скриптах).
Архитектура
Клиент-серверное взаимодействие выполняется путем двусторонней передачи бинарных файлов, при этом никакая служебная информация не передается. Для контроля целостности файлов на стороне клиента и сервера следует воспользоваться анализаторами для файлов соответствующего формата (например, см. статью Работа с файлами формата OpenDocument).
odtfactory-server - принимает через сокет файл формата OpenDocument на обработку и возвращает в требуемом формате. Для каждого типа результирующих документов используется отдельный порт.
Настройки по умолчанию:
$ cat /etc/odtfactory/config.sh # settings for openoffice.org and java #export LANG=ru_RU.UTF8 # odt2doc service location ODT2DOCHOST=127.0.0.1 ODT2DOCPORT=3001 # odt2pdf service location ODT2PDFHOST=127.0.0.1 ODT2PDFPORT=3002
Здесь переменная LANG может быть необходима для openoffice (если при конвертации выдает ошибки определения локали, нужно раскомментировать эту строку в конфиге).
На сервере odtfactory-server обработка производится с использованием 2-х временных файлов (оригинального и результирующего).
odtfactory-client - отправляет файл серверу и принимает результат.
На клиенте можно открыть пайп и читать данные, или сохранить во временный файл. Исходные данные могут быть как получены из пайпа, так и из файла.
odt2doc@, odt2pdf@ - утилиты для преобразования OpenDocument файла в соответствующий формат, выполняют пересылку файла серверу и принимают результат.
Тесты на ноутбуке Core2Duo, частота 800 MHz, 1Gb RAM:
$ apt-cache policy openoffice.org openoffice.org: Установлен: 1:2.4.1+dfsg-1+lenny3 # time odt2doc@ /tmp/100.odt > /tmp/x.doc $ time cat /tmp/100.odt | odt2doc@ > /tmp/x.doc real 0m3.330s user 0m0.020s sys 0m0.004s # time cat /tmp/100.odt | odt2pdf@ > /tmp/x.pdf $ time odt2pdf@ /tmp/100.odt > /tmp/x.pdf real 0m3.482s user 0m0.004s sys 0m0.016s
С более новым openoffice:
$ apt-cache policy openoffice.org openoffice.org: Установлен: 1:3.1.1-8 $ time odt2doc@ /tmp/100.odt > /tmp/x.doc real 0m2.382s user 0m0.008s sys 0m0.012s $ time odt2pdf@ /tmp/100.odt > /tmp/x.pdf real 0m2.560s user 0m0.020s sys 0m0.004s
И с последней версией openoffice:
$ apt-cache policy openoffice.org openoffice.org: Установлен: 1:3.2.0~rc1-1 $ time odt2doc@ /tmp/100.odt > /tmp/x.doc real 0m2.362s user 0m0.012s sys 0m0.004s $ time odt2pdf@ /tmp/100.odt > /tmp/x.pdf real 0m2.275s user 0m0.012s sys 0m0.008s
По возможности стоит использовать свежую версию openoffice, т.к. разница в быстродействии очень значительна.
Upd.
Если преобразование не работает, или первой строкой в созданном файле указано javaldx: Could not find a Java Runtime Environment!, следует проверить, что в профиле openoffice правильно определена java:
sudo less ~odtfactory/.openoffice.org2/user/config/javasettings_Linux_x86.xml <?xml version="1.0" encoding="UTF-8"?> <!--This is a generated file. Do not alter this file!--> <java xmlns="http://openoffice.org/2004/java/framework/1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <enabled xsi:nil="true"/> <userClassPath xsi:nil="true"/> <vmParameters xsi:nil="true"/> <jreLocations xsi:nil="true"/> <javaInfo xsi:nil="false" vendorUpdate="2004-01-30" autoSelect="true"> <vendor>Sun Microsystems Inc.</vendor> <location>file:///usr/lib/jvm/java-6-sun-1.6.0.12/jre</location> <version>1.6.0_12</version> <features>0</features> <requirements>1</requirements> <vendorData>660069006C0065003A002F002F002F007500730072002F006C00690062002 ... 32002F006A00720065002F006C00690062002F0069003300380036000A00</vendorData> </javaInfo> </java>
Случается такое, что после установки openoffice ява никоими манипуляциями не находится и тогда в указанном файле профиля нужных строк нет. Рекомендую выполнить вот такую команду:
# /usr/bin/Xvfb :10 -from localhost -nolisten tcp $ sudo -H -u odtfactory soffice -invisible -headless -norestore \ "macro:///odtfactory.Template.ConvertToDOC(/tmp/100.odt)" -nologo
В общем, черт бы побрал эту яву и программистов на побочных эффектах.
Итак, вот как выглядит "лечение":
$ odt2doc@ /tmp/100.odt /tmp/100.doc $ head -n1 /tmp/100.doc javaldx: Could not find a Java Runtime Environment! $ rm 100.doc $ sudo -H -u odtfactory soffice -invisible -headless -norestore \ "macro:///odtfactory.Template.ConvertToDOC(/tmp/100.odt)" -nologo $ head -n1 /tmp/100.doc �� ࡱ �; �� � $ extract /tmp/100.doc mimetype - application/vnd.ms-office
Как видим, ява успешно нашлась, и все заработало, но не спрашивайте меня, почему.
Upd.
На сервере с процессором Intel(R) Core(TM)2 Quad CPU Q6700 @ 2.66GHz имеем следующие показатели:
$ apt-cache policy openoffice.org openoffice.org: Installed: 1:2.4.1+dfsg-1+lenny3 $ time odt2doc@ /tmp/100.odt /tmp/100.doc real 0m0.877s user 0m0.000s sys 0m0.004s
Если сравнить с результатом на ноутбуке (см. выше), то мы получили практически линейную зависимость от частоты. Таким образом, несложно подсчитать, что openoffice 3.2 на CoreQuad обработает тот же файл примерно за полсекунды.
Upd.
openoffice 2.3 можно запустить и без виртуальных иксов, установив пакет openoffice.org-headless.
А если запускать напрямую /usr/lib/openoffice/program/soffice.bin, то выполнение команды окажется примерно на треть быстрее (для простых документов, когда запуск openoffice занимает львиную долю времени). Тест на том же сервере:
$ time odt2doc@ /tmp/100.odt /tmp/100.doc real 0m0.668s user 0m0.004s sys 0m0.000s
Примечание: Категорически не рекомендую пытаться использовать управляющий сокет openoffice! Во-первых, при работе с ним наблюдается утечка памяти. Во-вторых, протокол часто меняется, что приводит к невозможности обновить версию openoffice (например, когда я отладил работу tcluno с ooo 2.3, с ooo 2.4 эта библиотека отказалась работать из-за изменения версии протокола).
По результатам своих тестов могу утверждать - для неадминистрируемого сервера единственный вариант - запускать отдельный процесс openoffice для каждой конвертации. На сервере с процессором CoreQuad и 8Gb RAM ежедневная конвертация нескольких тысяч документов не создает никакой ощутимой нагрузки.
Comments