Skip to main content

I have a workbench that creates a single ECW file. It is intended that this process will be run, from server, up to 100 times, daily.

The problem is that if I execute this workbench from desktop, the process completes in sightly under 1 minute. The exact same process from our server implementation takes 16-17 minutes. THis has a huge impact on our productivity.

The resulting file is just 7Mb and intentionally contains large areas of black, where there was no-data.

I have done some analysis and come to the conclusion that it is the writing to ecw that causes the delay. If I replace the ecw writer with a logger, the rest of the process (reading, mosaicking etc) completes equally quickly in both environments.

This does not appear to be a question of server resources, only a small fraction of the available memory & cpu are used. Also, the temp directory is located in a sensible location, I believe. In both instances we are writing the file locally, so this is not a result of network issues.

Any idea what could be causing this disparity? Is there a difference in how the files are written between the two versions? What could we do to improve the performance on server? Version details are below - we are not in a position to upgrade.

Server - FME Server 2014 SP3 - Build 14391 - linux-x64

Desktop - FME(R) 2014 SP3 (20140814 - Build 14391 - WIN64)

Thanks

Is it possible to run the desktop version on linux? It may be that the performance difference is based on the operating system.


Looking through our developer database this seems to be a known issue that occurs on Linux. It occurs inside a 3rd party library we use which is why we haven't been able to fix it yet. Can you file a support case with us please? Visit safe.com/support to do that. Quote the reference number PR#49755. Explain that it is a productivity issue and it will get a higher priority. At the moment priority is low because there haven't been any other reports from users.

Apologies for the inconvenience this is causing. I hope we can get it resolved soon,

Mark

Mark Ireland

 

Product Evangelist

 

Safe Software Inc.

Looking through our developer database this seems to be a known issue that occurs on Linux. It occurs inside a 3rd party library we use which is why we haven't been able to fix it yet. Can you file a support case with us please? Visit safe.com/support to do that. Quote the reference number PR#49755. Explain that it is a productivity issue and it will get a higher priority. At the moment priority is low because there haven't been any other reports from users.

Apologies for the inconvenience this is causing. I hope we can get it resolved soon,

Mark

Mark Ireland

 

Product Evangelist

 

Safe Software Inc.

Thanks Mark, I have raised a support case.


Hi, I have been reviewing this issue on the osgeo forum for gdal_translate.

 

http://lists.osgeo.org/pipermail/gdal-dev/2006-Aug...

What is the version of GDAL in FME 2014? Do we think a newer version could improve the performance here? Latest GDAL for RHEL is 1.9.2 (that is from 2013)

http://elgis.argeo.org/repos/6/elgis/x86_64/repovi...

Regards


Reply