Download it now!
Bug 92274 - Problem with the speed of generating pdf in headless mode
Summary: Problem with the speed of generating pdf in headless mode
Status: RESOLVED INSUFFICIENTDATA
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
Version:
(earliest affected)
4.4.2.2 release
Hardware: x86-64 (AMD64) Linux (All)
: low minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: filter:pdf, perf
Depends on:
Blocks: PDF-Export
  Show dependency treegraph
 
Reported: 2015-06-23 10:39 UTC by Tomas Kralik
Modified: 2017-08-30 19:32 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample document for export to pdf (1.00 MB, application/vnd.oasis.opendocument.text)
2015-07-02 07:11 UTC, Tomas Kralik
Details
SimpleDocument (19.46 KB, application/vnd.oasis.opendocument.text)
2015-08-21 14:10 UTC, Tomas Kralik
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tomas Kralik 2015-06-23 10:39:39 UTC
Hello,
we have a problem with the speed of generating pdf in headless mode.
If you compare the OO version 3.2.1. and LO  version 4.4.2.2.  
LO is about 2 times or more slower to generate.
Tested on the application server is running redhat 6.6
An interesting situation is when compared LO 4.4.2.2. on different systems. Installing LO on server with redhat 6.6 in headless mode is about 2 times slower against instalation server with Mint 17.01.
You do not know what it could be due?
Comment 1 Buovjaga 2015-06-26 14:44:58 UTC
Please attach an example document, so we can benchmark.
What were your parameters for OOo 3.2.1?

With LibreOffice, I tried with
./soffice --convert-to pdf filename --headless

Those don't work in OOo.

Set to NEEDINFO.
Change back to UNCONFIRMED after you have provided the document and more information.
Comment 2 Tomas Kralik 2015-07-02 07:09:37 UTC
Starting in the Openoffice 3.2.1. 
./soffice -headless -accept="socket,host=localhost,port=8100;urp;" -nocrashreport -nodefault -nofirststartwizard -nolockcheck -nologo -norestore

Starting in the Libreoffice 4.3.3.  
./soffice --headless --accept="socket,host=localhost,port=8101;urp;" --nocrashreport --nodefault --nofirststartwizard --nolockcheck --nologo --norestore

Tests were conducted on documents with different sizes with pictures.

Sample document in attachment. 

I will add that headless mode for use as a background application, that is running on an application server through port.
Comment 3 Tomas Kralik 2015-07-02 07:10:33 UTC
Please confirmed
Comment 4 Tomas Kralik 2015-07-02 07:11:58 UTC
Created attachment 116986 [details]
Sample document for export to pdf
Comment 5 Buovjaga 2015-07-02 12:33:42 UTC
LibreOffice 4.4.4 took 2 seconds to convert it.

OpenOffice 3.3 freezes in the command line, when I try:
-headless -accept="socket,host=localhost,port=8100;urp;" -nocrashreport -nodefault -nofirststartwizard -nolockcheck -nologo -norestore -convert-to pdf vzor.odt

How do you do the pdf conversion exactly? You didn't include the parameters. Do you use the exact same parameters as in my above line?
Comment 6 Buovjaga 2015-07-02 12:44:28 UTC
(In reply to Tomas Kralik from comment #0)
> An interesting situation is when compared LO 4.4.2.2. on different systems.
> Installing LO on server with redhat 6.6 in headless mode is about 2 times
> slower against instalation server with Mint 17.01.

Do you really mean "installing" or are you still talking about converting with your sentence?

Btw. could the slowness be about network name resolution? Timing out when querying localhost? Can you debug it?

Could it be the same issue as this: http://lists.freedesktop.org/archives/libreoffice/2015-January/065570.html

First post: http://lists.freedesktop.org/archives/libreoffice/2014-December/065499.html

This fix was added to work around systems that are broken in that manner: https://gerrit.libreoffice.org/#/c/13856/

Fix should be in 4.4.0 already, so I'm not sure..
Comment 7 Buovjaga 2015-07-02 12:46:22 UTC
Ok, the fix is not in 4.4 branch. You should try with 5.0 RC2 and see, if the problem persists. You should also look into your server setup.
Comment 8 Tomas Kralik 2015-07-14 09:04:40 UTC
first excuse I was away from civilization, so I did not react :-)

Yes, I've used these switches to install OO on Red Hat EL 6.6 and Mint 17.1KDE and normally I passed the test.



(In reply to Beluga from comment #5)
> LibreOffice 4.4.4 took 2 seconds to convert it.
> 
> OpenOffice 3.3 freezes in the command line, when I try:
> -headless -accept="socket,host=localhost,port=8100;urp;" -nocrashreport
> -nodefault -nofirststartwizard -nolockcheck -nologo -norestore -convert-to
> pdf vzor.odt
> 
> How do you do the pdf conversion exactly? You didn't include the parameters.
> Do you use the exact same parameters as in my above line?
Comment 9 Tomas Kralik 2015-07-14 12:49:22 UTC
(In reply to Beluga from comment #6)
> (In reply to Tomas Kralik from comment #0)
> > An interesting situation is when compared LO 4.4.2.2. on different systems.
> > Installing LO on server with redhat 6.6 in headless mode is about 2 times
> > slower against instalation server with Mint 17.01.
> 
> Do you really mean "installing" or are you still talking about converting
> with your sentence?

Here I am referring to the rate of conversion into pdf. Within two Linux distributions.

> Btw. could the slowness be about network name resolution? Timing out when
> querying localhost? Can you debug it?

A network problem that can not be tested on multiple devices, whether locally or on a remote server. I'm talking about the installation location.


> Could it be the same issue as this:
> http://lists.freedesktop.org/archives/libreoffice/2015-January/065570.html
> 
> First post:
> http://lists.freedesktop.org/archives/libreoffice/2014-December/065499.html
> 
> This fix was added to work around systems that are broken in that manner:
> https://gerrit.libreoffice.org/#/c/13856/
> 
> Fix should be in 4.4.0 already, so I'm not sure..
Comment 10 Buovjaga 2015-07-14 13:07:28 UTC
Please test with 5.0 RC3 and see, if the PDF generation speed issue is solved. Please also look into fixing your server setup to remedy the real issue.

Set to NEEDINFO.
Change back to UNCONFIRMED, if the problem persists. Change to RESOLVED FIXED, if the problem went away.
Comment 11 Tomas Kralik 2015-08-21 13:01:46 UTC
Unfortunately 5.0.0.3 LibreOffice is not faster than in version 4.4.2. Even as a little slower. However, let us return to the problem of speed generate pdf. Thus, comparing speeds between LO 4.4.2 and 3.2.1 OO. In Annex I add an attachment. Simple odt. There is a difference between the speed as follows: 
LO is 10 times slower than OO.
The average generation time attached document is 90 ms at OO.
The average generation time attached document is 810 ms to LO.
User configuration I have the same in both versions.
Both versions are running headless mode with the same switches. On the same machine.
Comment 12 Tomas Kralik 2015-08-21 14:10:03 UTC
Created attachment 118069 [details]
SimpleDocument
Comment 13 Joel Madero 2015-08-21 20:40:13 UTC
Clearly not a major bug. Please don't over prioritize your bugs.

Major is retained for crashers, loss of data, and the like...


Minor - slows down professional quality work (from what I can read in the comments...it's by milliseconds?? might not even deserve minor);
Low - default.
Comment 14 Tomas Kralik 2015-08-25 12:11:48 UTC
If OO document generated in 90 ms and LO is now generates over 810 ms consider it a huge problem. For example, if you generate daily 80,000 documents so the difference is unreal ...
Comment 15 V Stuart Foote 2015-08-25 12:29:07 UTC
(In reply to Tomas Kralik from comment #14)
> If OO document generated in 90 ms and LO is now generates over 810 ms
> consider it a huge problem. For example, if you generate daily 80,000
> documents so the difference is unreal ...

I don't see that you mention anything about the resulting PDF. Are the sizes comparable, are the images present in LO generated PDF converted to bitmap rather than vector? Suspect the issue is in that facet.
Comment 16 Joel Madero 2015-08-25 15:34:21 UTC
...everyone thinks their bugs are "huge problems" but we use an objective standard that takes these personal biases out of the picture. Minor is appropriate. If you're using this in a business setting (which I suspect you might be doing if you have that number of documents) I suggest you get L3 support and then a certified developer can and will focus on the issue (i.e., you can dictate what is fixed and when)

https://www.documentfoundation.org/certification/developers/
Comment 17 tommy27 2017-01-09 17:13:47 UTC
@ Tomas Kralik 
is the bug still present in LibO 5.2.4.2?

status NEEDINFO
revert it to UNCONFIRMED if bug is still present or change it to RESOLVED WORKSFORME if bug is gone

NEEDINFO until then
Comment 18 QA Administrators 2017-07-27 12:06:49 UTC Comment hidden (obsolete)
Comment 19 QA Administrators 2017-08-30 19:32:04 UTC Comment hidden (obsolete)