суббота, 9 января 2010 г.

mbg-opendocument-[server|client]

Внимание: при изменении версии openoffice необходимо переустановить пакет odtfactory-server.

Внимание: пакеты переименованы и создан отдельный пакет с файлом конфигурации:
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 ежедневная конвертация нескольких тысяч документов не создает никакой ощутимой нагрузки.

Комментариев нет:


(C) Alexey Pechnikov aka MBG, mobigroup.ru