I don't quite remember right now how much of it is available via configuration settings in which eZ Publish version, but surely much of the publishing time will be connected with different cache regeneration/cleaning. Basically, the more relations you have between objects/nodes that have cache-clearing abilities (object relations, ezkeyword, complex smart view cache rules etc), the longer the publishing. Also look here:
http://ez.no/developer/forum/suggestions/ezkeyword_optimization/re_ezkeyword_optimization__3 I ran some tests with extensive ezkeyword use, I killed the publishing only after 3000 objects ;)
I don't have smart cache rules, also view cache regeneration 'over keyword' and 'over attribute relation' is limited with the new settings in eZ 4.1.*.
What more can be done? Maybe in operation definition?
Try to enable debug redirection as well as SQL debug output and take a look what takes most of time upon the publication process. Do you have any workflow events which are connecting to the external services? Like fetching content via CURL or something like that?
@Piotrek,
Case with ezkeyword cache issue should not be valid for 4.1 and above anymore.
maybe the pb is not link with the publication process but with the page display after the publish... if you have a lot of data in the parent node, ez can spend a lot of time to count the number of subnodes
enable the debug on redirection sql etc. you will know where is the pb.
do you have a lot of rows in the ezkeyword* table?
- DelayedCacheBlockClenaup already enabled
- PreviewCache already disabled
- no static cache
- full view of page viewed after publish is not trivial but with DebugRedirection enabled conclusion is that publish process is slow not the page full view generation it self. - there are not that much keywords