Selon Zoran Vasiljevic <[EMAIL PROTECTED]>: > On Tuesday 24 February 2004 12:02, you wrote: > > > > BUT... with the same traffic as before my processor (%CPU and load > > balancing) is multiplied by about 8 ! > > After few searches, I realised a nsv lock contention was very high > (checked > > in nstelemetry.adp). > > > > So it is not directly the TTrace package that is slowing the process in my > > opinion but its use of the nsv_ commands that generate lock contentions. > > > > Yes. I use one nsv array to store item blueprints. > But what I do not understand is why there should be high contention > there. Normally, nsv array is hit only when the Tcl unknown is unable > to resolve the item in the running interp. During "normal" operation, > a connection thread will gradually load all that it needs in the > interp and thus never revert to nsv lookup again. > If you however have frequent short-lasting threads which gets > spawned to do a small task and then exit, then there will be > a contention there. > > One possible solution is to introduce pool of shared arrays > for storing item blueprints instead of one. I will consider > this option. We havent hit this problem yet, therefore I payed > little attention to it. Besides, we're still at 0.9 release > so there is room for improvements :) >
I agree 100% with you. Thread should gradually load all the procs. I may have something wrong somewhere or a special thing in all my tcl procs, I will check that and let you know. Regards. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
