Forum OpenACS Q&A: nstelemetry.adp q (plus an interesting NT hack attempt)

Is there someone more familiar with nstelemetry.adp that can help me
figure out what all the info means?  I am especially curious about:

1.  Current URL stats:  wait/open/closed:  does this mean average? max?
or total time for all requests for that particular URL?

2.  Memory cache:  given "adpObj.5584896 entries: 20 flushed: 0 hits:
133 misses: 20 hitrate: 86" what, exactly does that mean?

3.  Thread locks:  all but one of the thread objects listed have had no
nbusy on them (0 count).  However, nsthread:tclobjs has 28 nbusy on a
count of 9366 locks.  Is this good/bad?  Does it affect performance?

interestingly, since the server keeps stats on URL requests, even when
the URL does not exist, I notice that I have received some requests for


which appears to be a hack attack on NT based FrontPage enabled sites.
Running on OpenBSD/AOLserver of course, the only thing the script kiddy
got for his troubles was a 404.  :-)

1. On my version it is the the average; it sums times in the C code and then the nstelemetry.adp computes sum/hits.  It is per url

2. entries is the current number of entries in the cache, flushed is the total number deleted or replaced, hits is the count of successful gets, misses is the number of unsuccessful gets and hitrate is the percentage of time the cache was useful.  86% hitrate is reasonably good.

3. I dont think that number of busy locks is an issue.  It is a count so really as a fraction of the number of locks taken that is minuscule.

If you are interested in tuning your server you should look for the
article Jim Davidson wrote about Digital City's use of aolserver at
also, and have some useful

My last remaining IIS server was attacked by this.
Someone was nice enough to write a worm that infects solaris
machines and uses them to attack IIS machines so most of the
attempts are not from an individual but from a program.
The nice thing about that is that since I had organized my IIS
server with different folders from normal it blindly stuck it's
files in the wrong place.  I got lucky.

If you ever want to scare an IIS administrator just tell them to
search google for "iis exploits", "apache exploits", and maybe
"aolserver exploits".  I don't want to have to spend 4 hours of each
day searching the web for any new exploits for this closed source
product.  (If your program had as many holes as theirs you'd want
the source to be closed also)

If you're running IIS and you're not using exe files directly I
recommend associating the .exe extension with a useless program.  (I
assumed hostname.exe would be safe).  Not a bad idea to do this to
.bat files as well.  and of course removing any script mappings you
are not using.