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 22.214.171.124.
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 126.96.36.199. 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?
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.
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.
Created attachment 116986 [details]
Sample document for export to pdf
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?
(In reply to Tomas Kralik from comment #0)
> An interesting situation is when compared LO 188.8.131.52. 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..
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.
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?
(In reply to Beluga from comment #6)
> (In reply to Tomas Kralik from comment #0)
> > An interesting situation is when compared LO 184.108.40.206. 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:
> First post:
> This fix was added to work around systems that are broken in that manner:
> Fix should be in 4.4.0 already, so I'm not sure..
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.
Unfortunately 220.127.116.11 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.
Created attachment 118069 [details]
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.
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 ...
(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.
...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)
@ Tomas Kralik
is the bug still present in LibO 18.104.22.168?
revert it to UNCONFIRMED if bug is still present or change it to RESOLVED WORKSFORME if bug is gone
NEEDINFO until then
Dear Bug Submitter,
This bug has been in NEEDINFO status with no change for at least
6 months. Please provide the requested information as soon as
possible and mark the bug as UNCONFIRMED. Due to regular bug
tracker maintenance, if the bug is still in NEEDINFO status with
no change in 30 days the QA team will close the bug as INSUFFICIENTDATA
due to lack of needed information.
For more information about our NEEDINFO policy please read the
wiki located here:
If you have already provided the requested information, please
mark the bug as UNCONFIRMED so that the QA team knows that the
bug is ready to be confirmed.
Thank you for helping us make LibreOffice even better for everyone!
Dear Bug Submitter,
Please read this message in its entirety before proceeding.
Your bug report is being closed as INSUFFICIENTDATA due to inactivity and
a lack of information which is needed in order to accurately
reproduce and confirm the problem. We encourage you to retest
your bug against the latest release. If the issue is still
present in the latest stable release, we need the following
information (please ignore any that you've already provided):
a) Provide details of your system including your operating
system and the latest version of LibreOffice that you have
confirmed the bug to be present
b) Provide easy to reproduce steps – the simpler the better
c) Provide any test case(s) which will help us confirm the problem
d) Provide screenshots of the problem if you think it might help
e) Read all comments and provide any requested information
Once all of this is done, please set the bug back to UNCONFIRMED
and we will attempt to reproduce the issue. Please do not:
a) respond via email
b) update the version field in the bug or any of the other details
on the top section of our bug tracker