This site has been archived and you can no longer log in or post new messages. For up-to-date community resources please visit

eZ Community » Forums » Setup & design » No more image variations :-(

No more image variations :-(

No more image variations :-(

Wednesday 06 June 2012 1:02:35 pm - 25 replies

Hi every body,

I have another problem, after the one you helped me to solve few weeks ago here.

The site was working pretty well (a "4.6", community 2012.2), and I made few security updates, I guess the problems may come from here, but impossible to be sure, since I can't tell the problems apprear just after or not.

After the previous issue, the images were OK, and eZ generated the variations without problems.

Right now, no way ! As soon as I integrate a new picture in the back-office, it is correctly imported on the serveur, but I can't see it in the front or back office (I can only see it in FTP mode).

I thought it could be a problem of policies, but event if the image, and all the folder of "/var" are in 777, no changes...

The settings seems to be OK, all variations are set-up.

An attribute(show) of an image in a related object show "NULL" for the variations suspicious.gif Emoticon

Do you have any ideas where I should look ? Thanks in advance,

PS : Excuse my poor english, I'm french blunk.gif Emoticon 

Tuesday 12 June 2012 10:37:16 am

I'm afraid this one doesn't work as well as the previous one sad.gif Emoticon

I did restore all files, and launch the patch. No error in console mode, and file where correctly updated.

But I tried to update an image, and then again had a empty <img> every where sad.gif Emoticon

I send you a private email also...

Modified on Tuesday 12 June 2012 10:45:34 am by Arnaud Boulai

Tuesday 12 June 2012 5:53:39 pm

This should now be working.

Thanks Arnaud for your help for debugging this.

I've submitted a pull request to eZ Systems.

Hopefully this will be added to a future version of eZ Publish.

Tuesday 12 June 2012 7:14:27 pm

@huy Would you recommend this setting to be applied everywhere, only on shared hosting, or only under specific conditions?

As far as I understand, this param is used to limit the number of threads used by IM.

This might make a lot of sense in the general case, ie. with 8 cores always limit IM to only use 4 - this leaves 4 cores available for Apache to run (providing IM is running 1 process) and should improve the case for when 2 IM processes are running in parallel as well.

But on 1and1 the problem seems to stem from excessive mem usage by IM. This means, to my understanding, that limiting the number of threads also has the side-effect of limiting the used memory. Do you agree on this analysis?

Last: the benefits in more responsive cpu and lesser memory used are probably offset by a slower image conversion process. Do you have any rough data about this deterioration?

Tuesday 12 June 2012 8:22:04 pm

From IM's website:

"In most circumstances, the default number of threads is set to the number of processor cores on your system for optimal performance. However, if your system is hyperthreaded or if you are running on a virtual host and only a subset of the processors are available to your server instance, you might get an increase in performance by setting the thread policy or theMAGICK_THREAD_LIMIT environment variable. For example, your virtual host has 8 processors but only 2 are assigned to your server instance. The default of 8 threads can cause severe performance problems.

One solution is to limit the number of threads to the available processors in your policy.xml configuration file:

<policy domain="resource" name="thread" value="2"/>

Or suppose your 12 core hyperthreaded computer defaults to 24 threads. Set the MAGICK_THREAD_LIMIT environment variable and you will likely get improved performance:



Your case makes sense actually. Maybe we could include a code that auto-detects the number of cores and allow IM to use 1/2 of them or some rule like that.

You are right for 1and1. And a lot of shared hosting services restricts the number of threads to avoid not only too much memory usage but also CPU usage.

I have no metrics. But here is a little benchmark result from IM's site:

Here is an example benchmark for threads 1-8:
convert -bench 40 model.png -sharpen 0x1 null:Performance[1]: 10i 0.712ips 1.000e 14.000u 0:14.040Performance[2]: 10i 1.362ips 0.657e 14.550u 0:07.340Performance[3]: 10i 2.033ips 0.741e 14.530u 0:04.920Performance[4]: 10i 2.667ips 0.789e 14.590u 0:03.750Performance[5]: 10i 3.236ips 0.820e 14.970u 0:03.090Performance[6]: 10i 3.802ips 0.842e 15.280u 0:02.630Performance[7]: 10i 4.274ips 0.857e 15.540u 0:02.340Performance[8]: 10i 4.831ips 0.872e 15.680u 0:02.070
In certain cases, it might be optimal to set the number of threads to 1 or to disable OpenMP completely.</div>


Also on:

"When running in parallel, we found that image manipulation activities ran suprisingly more slowly in the continuous integration environment.  We tracked this down to ImageMagick defaulting to using all processors in parallel, which caused cpu contention when more than one operation took place concurrently; limiting the threads available to ImageMagick (which we did by setting the MAGICK_THREAD_LIMIT environment variable) made this more comfortably parallel."

Modified on Tuesday 12 June 2012 8:23:01 pm by Quoc-Huy NGUYEN DINH

Friday 12 October 2012 5:35:03 pm

I had a problem that looked very like this one but had a different cause / resolution.

Identical failure of the convert function but caused by Apache running as user nobody and me having migrated the content from one server to the next and giving the var directory the same ownership as the ftp user account.

chown nobody:nobody -R var


from the eZ Publish root sorted the issue from me


You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu

Proudly Developed with from