ImageMagick отнема много време, за да конвертира SVG с текст в JPEG

Използваме ImageMagick (Версия: ImageMagick 6.9.1-7 Q16 x86_64) и неговото PHP разширение Imagick в нашия стек LAMP за конвертиране на SVG в JPEG и отнема необичайно много време, когато SVG съдържа някакъв текст (12-13 секунди / файл).

Когато едно и също нещо се изпълнява като самостоятелен PHP скрипт от командния ред (или директно с помощта на конвертирането на IM), то се конвертира бързо за по-малко от 1 секунда, независимо дали има текст или не.

Заслужава да се спомене също така, че нямаме този проблем с GraphicsMagick. (Но има някои SVG грешки, които не са разрешени и ни пречат да го използваме.)

Някой би ли имал идея защо обработката на шрифтовете отнема толкова време в стека LAMP или как да идентифицира основната причина за забавянето?

Примерен SVG:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg xmlns="http://www.w3.org/2000/svg"     xmlns:xlink="http://www.w3.org/1999/xlink" width="344" height="243"  viewBox="0 0 737 521">
<g class="main">
    <title>Main</title>
    <image xmlns:xlink="http://www.w3.org/1999/xlink" id="svg_12"  height="218.4417" width="291.2556" y="32.2537" x="-10.893" xlink:href="/bg/tmp/767756670842438737_7032fbfb3c364e6da226254687eb1edb.jpg" style="pointer-events:inherit">29.75235 32.253654 209.964875 218.441697</image>
    <g font-size="normal" font-family="Allerta" class="textarea" id="svg_13" style="pointer-events:inherit">
        <rect opacity="0" fill-opacity="0" stroke-opacity="0" stroke-width="2" fill="#000" id="svg_10" height="32" width="150.4384" y="293.06824" x="550.14683" style="pointer-events:inherit"/>
        <text text-anchor="start" xml:space="preserve" fill="#000" font-size="21" y="293" x="550" id="svg_68" style="pointer-events:inherit">
            <tspan dy="14" x="550" xml:space="preserve" id="svg_69" style="pointer-events:inherit">
        hello </tspan>
            <tspan dy="21" x="550" xml:space="preserve" id="svg_70" style="pointer-events:inherit">gc </tspan>
        </text>
    </g>
</g>
</svg>

и кода за конвертиране:

$im = new Imagick(); 
$svg = file_get_contents($svgFile); 
$svg = str_replace(array("\n", "\r", "\t"), '', $svg); 
$im->readImageBlob($svg); 
$im->setImageFormat("jpeg"); 
$im->writeImage($jpgFile); 
$im->clear(); 

person Sayan Bhattacharyya    schedule 17.07.2015    source източник
comment
Каква е вашата операционна система и знаете ли дали IM използва собствен четец на svg или се използва rsvg?   -  person dlemstra    schedule 17.07.2015
comment
здрасти Използваме Ubuntu (12) и той използва RSVG делегата.   -  person Sayan Bhattacharyya    schedule 17.07.2015
comment
Предполагам, че PHP налага ограничение на паметта, което не присъства в командния ред - опитайте да стартирате identify -list resource както в командния ред, така и от PHP, като използвате system() или нещо подобно.   -  person Mark Setchell    schedule 17.07.2015
comment
Или опитайте да създадете поредица от изображения, които запълвате с шум, така че да не могат да бъдат компресирани с размери 1000x1000, 2000x1000, 4000x1000 и т.н. и вижте как времето за това се променя в PHP и извън него.   -  person Mark Setchell    schedule 17.07.2015


Отговори (1)


Този SVG конвертира добре за мен.

Начинът да проучите това е да стартирате PHP скрипта през strace с команда като:

strace -f -F /usr/local/bin/php testScript.php

Но с подходящия път за PHP във вашата система.

Има голяма вероятност да има някакво състояние на грешка, което кара „нещо“ да отнеме много повече време, отколкото би трябвало. Командата strace по-горе ще ви позволи да видите всички системни повиквания, които се правят, и колко време отнема всяко от тях.

Подозирам, че ще видите, че някои системни повиквания отнемат почти цялото общо време за обработка, преди да върнат код за грешка. Ако не можете да разберете какво означава изходът, моля, прикачете изхода към въпроса си или пастебин и аз ще се опитам да интерпретирам руните.

Предупреждение - strace е в състояние да улавя информация, която може да не искате да бъде разкрита (напр. секретни ключове), така че трябва да се внимава, преди да се публикува нейният изход навсякъде.

person Danack    schedule 19.07.2015