(Some) scripts consume all cpu cycles

I was running top when I moved a topic to another web. To my surprise, the rename took 99% of my CPU cycles. This seems to be the case in general, and is obviously really bad. How can one prevent this?

-- Contributors: MeredithLesly

Discussion

Related to Bugs:Item2375. Perhaps rename / put this topic in context (there are many topics related to performance already)?

-- SteffenPoulsen - 04 Jun 2006

This isn't about performance in the sense of TWiki being too slow but, rather, on the effect of a TWiki process on the rest of my machine. It also has nothing to do with the number of topics, which is very low.

-- MeredithLesly - 04 Jun 2006

Please add context/fill form. Suggestion for new topic name: RenameOperationIsCPUIntensive.

As a rename operation searches for backlinks it will scan topics in (current|all) webs for references.

You could time a rename operation and a backlinks operation for the same topic using i.e. ab and report how your timings compare?

For reference, in my case rename is faster than backlinks:

• /bin/oops/Sandbox/TestTopic?template=backlinksweb (~1200ms)
• /bin/rename/Sandbox/TestTopic?currentwebonly=on (~900ms)

-- SteffenPoulsen - 04 Jun 2006

The issue I raised isn't how long it took (although if it took 5 ms who would care?) The issue is that it consumed 99% of the CPU cycles, leaving none for any other process.

-- MeredithLesly - 05 Jun 2006

Sorry, I need more words to understand this, then - both backlinks and rename above use all the CPU cycles your scheduler will allow them while running (as do all TWiki operations).

(This is good, as a lower CPU usage would just mean a longer time to complete).

Perhaps the problem you are trying to state is not the 99% cpu cycles used, but the scheduling priority the process is given? In this case you can nice your apache parent process, all childs forked will inherit the priority you give it.

-- SteffenPoulsen - 05 Jun 2006