On Friday 05 March 2004 18:59, you wrote:
When I will get some time, I will try to do some tests by splitting the
0-proc nsv array into several arrays to check if I can reduce the lock
contention.
I will let you know if results are better with this technique.
Unfortunately, I am pretty busy
:[EMAIL PROTECTED] la part
de Zoran Vasiljevic
Envoyé : vendredi 5 mars 2004 18:29
À : [EMAIL PROTECTED]
Objet : Re: [AOLSERVER] TTrace, nsv_, arrays and tcl
On Tuesday 24 February 2004 12:02, you wrote:
BUT... with the same traffic as before my processor (%CPU and load
balancing
Selon Zoran Vasiljevic [EMAIL PROTECTED]:
I didn't investigate more, but as I understand the ttrace::getentry proc
should be called only when resolving the function.
Correctly. Once per thread and once per proc.
But adding some ns_log trace, I found the getentry proc was called on
On Thursday 26 February 2004 11:14, you wrote:
Here I am not sure to understand. Why do your cleanup code per request
(the ttrace::cleanup added) delete the loaded functions ?
They should not be deleted... (I am perhaps missing something, I didn't
chek carefully the cleanup code so far).
Selon Zoran Vasiljevic [EMAIL PROTECTED]:
On Thursday 26 February 2004 11:14, you wrote:
Because your code may modify some state during the execution of the
procedure and I have to make sure that next run gets a clean
interp state.
The regular way to change the state is to run ns_eval. So,
On Thursday 26 February 2004 12:49, you wrote:
Anyway, I have a question about this cleanup : If I am sure I am not
changing the interp state and procs, there is no need to run this cleanup.
Am I right ?
You are right.
I never use ns_eval on my web site, and I think (90% sure) my procs
de Zoran Vasiljevic
On Tuesday 24 February 2004 13:24, you wrote:
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.
You can make your life easier by adding
On Wednesday 25 February 2004 22:07, you wrote:
The lock contention problem comes from the nsv_array 0-proc.
As I understand TTrace module, the xx-proc (where xx=0 for me) is the
array where all the procs are saved (the proc db we can say).
0 = the epoch time I suppose.
Correct. So you have
Hi all,
I activated last week the TTrace package on my production server.
I stopped it after a few days. It is working great and is really terrific to
keep AOLServer process memory low !
BUT... with the same traffic as before my processor (%CPU and load balancing)
is multiplied by about 8 !
Jean-Fabrice RABAUTE said:
time { array get t d10906c3dac1172d4f60bd41f224ae75 } 100
You shouldn't use array get to get one value. the pattern isn't a key,
it is what is says it is: a pattern. So foo*, a?c and [a-z] are all
allowed and array get will return you a list of key/value pairs that
Selon Bas Scheffers [EMAIL PROTECTED]:
Jean-Fabrice RABAUTE said:
time { array get t d10906c3dac1172d4f60bd41f224ae75 } 100
You shouldn't use array get to get one value. the pattern isn't a key,
it is what is says it is: a pattern. So foo*, a?c and [a-z] are all
allowed and array get will
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
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
On Tuesday 24 February 2004 13:24, you wrote:
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.
Pay attention to ns_eval! This can be your bottleneck.
On each
On Tuesday 24 February 2004 13:24, you wrote:
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.
You can make your life easier by adding some log displays to
the
Selon Zoran Vasiljevic [EMAIL PROTECTED]:
On Tuesday 24 February 2004 13:24, you wrote:
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.
You can make your
16 matches
Mail list logo
