Degrading performance when running consecutive insert operations

Question

Hi,
I'm using DB-XML (2.5.16) as a backend storage for a web application that works on top of a TBX (TermBase eXchange) document. The application is using the Python bindings and development is being done on GNU/Linux with Python 2.6.
The document is stored in a node-storage container, autoindexing is off at the time of container creation and transactions are enabled.
After a set of indexes are set, queries work quite fast.
On the other hand, when users input new data (terms) or perform edits on existing data, insert and replace operations have instant effect.
The application has also a feature to insert lots of new terms in a single click, resulting in a new insert operation for each term. If the amount of terms to be inserted is relatively small (let's say ~10), the operation is quickly performed and the user receives a response almost instantly.
Anyway, the problem arises when there are lots of new terms to be inserted. It starts working fast but performance quickly starts to degrade badly, needing more long seconds for each insert operation. Python's CPU-usage seems to go up to 100% when doing the actual insert, too.
I understand this is not the best-working scenario for DB-XML (a single large document), but I don't think this performance is normal or acceptable.
I have tried increasing Berkeley DB's cache size to 64MB with no success.
Any hints about what should I be looking at? any more recommendations?
These are the defined indexes:
dbxml> listindexes
Index: node-element-equality-string for node {}:admin
Index: node-element-equality-string for node {}:descrip
Index: node-attribute-equality-string edge-attribute-equality-string for node {}:id
Index: node-attribute-equality-string for node {http://www.w3.org/1999/xhtml}:lang
Index: unique-node-metadata-equality-string for node {http://www.sleepycat.com/2002/dbxml}:name
Index: node-element-equality-string for node {}:ref
Index: node-element-equality-string node-element-substring-string for node {}:term
Index: node-element-equality-string for node {}:termNote
Index: node-attribute-equality-string edge-attribute-equality-string for node {}:type
9 indexes found.Container information:
dbxml> info
Version: Oracle: Berkeley DB XML 2.5.16: (December 22, 2009)
         Berkeley DB 4.8.30: (2010-12-09)
Default container name: cont.dbxml
Type of default container: NodeContainer
Index Nodes: on
Auto-indexing: off
Shell and XmlManager state:
     Transactional, no active transaction
     Verbose: on
     Query context state: LiveValues,Eager

Answer 1

As you both have mentioned I have tried increasing the cache size to 512MB or even to 1GB (I have recreated the entire DBs after setting cache sizes), but I don't see any significative improvements.
I have also tried to tune my insert queries, and now I think they're in better shape than before. I would say the initial inserts feel slightly faster, but this only happens when the DB is empty (just bootstrapped). Then, once the DB has some term entries and grows in size, it starts to degrade and inserting becomes expensive in order of magnitudes.
Each insert operation is performed in a separate transaction. And yes, I'm using transactions all over the application.
Vyacheslav, I'll send you a couple of containers along with insert queries created by the application so you can play with.