Forums / Extensions / eZ Find / OptimizeOnCommit enabled implies long publishing time?

OptimizeOnCommit enabled implies long publishing time?

Author Message

Carlos Revillo

Tuesday 14 April 2009 7:56:21 am

Hi. I think i'm doing something wrong with eZ Find. I'm working with the last rev from the repo btw.

After i enabled eZ find extension, all the publishing process takes a lot of time. I'm talking about 30 - 45 seconds...

This is not good for me, because in this site there will be a lot of content coming not only from the editors but also from guest accounts users.

Disabling OptimizeOnCommit option publishing is faster. Only 3-4 seconds.

I now i can disable this and set a cron to optimize, but is this normal? I mean, is normal that these optimize operations takes so long?

This is not a very big site at the moment (development stage). It's a bilingual site right now, but more languages will be added. think about less than 1000 objects right now.

I'm using ubuntu and i have 3GB memory.

Thanks in advance.

Xavier Serna

Thursday 16 April 2009 12:38:43 am

Hi Carlos,

this is the same problem here with big indices. Each Optimize operation causes a regeneration of the whole index files, it's the reason for this publishing delay.
I believe that disabling optimize on commit and optimizing indices via cronjob once a day it's ok, we have these setup here too.

regards!

--
Xavier Serna
eZ Publish Certified Developer
Departament de Software
Microblau S.L. - http://www.microblau.net
+34 937 466 205

Carlos Revillo

Thursday 16 April 2009 12:47:54 am

Thanks Xavier,

Disabling it and setting the cron job seems to be a good solution.
Maybe eZ Systems can put a comment on the ezfind.ini talking about this.

Regards.

Jon Ramster

Tuesday 08 February 2011 8:03:00 am

Hello all

Sorry to add a reply to such an old thread, but we recently had the same problem. On Publishing the eZ Find Java process would max the CPU out for 25 seconds on a small site! We had no option but to disable this to get an acceptable speed...

Jon

Paul Borgermans

Tuesday 08 February 2011 11:47:30 am

Disabling optimize on commit is indeed something you should disable for any site that has more than a few hundres of objects (most do ;) )

You can set up a cron job that optimizes the index once a week or once a day. See the cronjobs directory in ezfind.

If commits are taking too long, consider using the commitWithin ini setting in eZ Find 2.3 (specifying a time that is 2x the average commmit time -- see the logs for that, tyoically i would recommend 5000, which is 5 secs). This is a bit like delayed indexing, but then handled by the backend Solr.

hth

Paul

eZ Publish, eZ Find, Solr expert consulting and training
http://twitter.com/paulborgermans

eZ debug

Timing: Jan 30 2025 00:17:41
Script start
Timing: Jan 30 2025 00:17:41
Module start 'content'
Timing: Jan 30 2025 00:17:41
Module end 'content'
Timing: Jan 30 2025 00:17:41
Script end

Main resources:

Total runtime0.0205 sec
Peak memory usage2,048.0000 KB
Database Queries4

Timing points:

CheckpointStart (sec)Duration (sec)Memory at start (KB)Memory used (KB)
Script start 0.00000.0059 588.2031180.7578
Module start 'content' 0.00590.0059 768.960999.0234
Module end 'content' 0.01180.0087 867.984474.7031
Script end 0.0205  942.6875 

Time accumulators:

 Accumulator Duration (sec) Duration (%) Count Average (sec)
Ini load
Load cache0.002311.1057120.0002
Check MTime0.00125.9436120.0001
Mysql Total
Database connection0.00062.845210.0006
Mysqli_queries0.003316.069240.0008
Looping result0.00000.072020.0000
Template Total0.008340.610.0083
Template load0.00104.953010.0010
Template processing0.007335.621110.0073
Override
Cache load0.00083.696510.0008
General
dbfile0.005024.4725100.0005
String conversion0.00000.024430.0000
Note: percentages do not add up to 100% because some accumulators overlap

Templates used to render the page:

UsageRequested templateTemplateTemplate loadedEditOverride
1pagelayout.tpl<No override>extension/sevenx/design/simple/templates/pagelayout.tplEdit templateOverride template
 Number of times templates used: 1
 Number of unique templates used: 1

Time used to render debug report: 0.0001 secs