Sure, every story calls publish_another. Maybe even more than once.
I do massive republish by bric_soap setting jobs to lowest priority.
This way users can overtake when publishing their stories via UI on
higher priority. Works good.
Now, I wonder, could template figure out its own job priority, and based
on that publish_another could be avoided while republish, while it
would normally publish cover pages when ran on higher priority.
Bret Dawson wrote: > Hi Zdravko,
> If your templates call publish_another() in every story, that's probably
> causing a good portion of the slowness you're experiencing.
> What happens if you temporarily disable that?
> All the best,
> On Mon, 2012-01-30 at 08:15 +0100, Zdravko Balorda wrote:
>> Hi, Matthew!
>> I remeber, yes. here, I am chasing speed of a whole republish. When you
>> have 25000 stories, and if it takes 2-3seconds on a story it takes a while. :)
>> But not much can be done, except perhaps in templates. I use publish another
>> in every story, unfortunately. Fanny thing though, perl takes 70% of CPU time.
>> What is it doing? :)
>> Matthew Rolf wrote:
>>> I started a thread on this topic a while ago relating specifically to the API:
>>> On Jan 26, 2012, at 12:03 PM, David E. Wheeler wrote:
>>>> On Jan 26, 2012, at 6:40 AM, Zdravko Balorda wrote:
>>>>> I'm trying to otpimize publishing for speed, now. Using
>>>>> bric_queued leaves apache for UI, which is good. There are
>>>>> left two main processes working on publish: perl (bric_queued) and
>>>>> postgres. Interestingly, the two grabs all 100% of one CPU, while
>>>>> leaving the other lose. There are two in my box.
>>>>> System time is very low: 3.3%.
>>>>> Seems quite optimal. Are there any better practices?
>>>> Not really. The best way to minimize publish time is to keep your templates simple, and donâ€™t over-call pubish_another().
JurÄkova 229, Ljubljana
Tel.: +386 (0)1 520 50 50
ObiÅ¡Äite sistem zdravstvenih nasvetov Med.Over.Net