Massive speed difference between identical asp pages

[MikeT]

I have a page that produces little thumbnails of the 3D models it
finds in a specified directory (and iterates down through any sub
directories).

It basically scans each directory for 3D Studio Max files using the
filesystemobject and writes an activeX component called iDrop for each
file so it can be displayed on the page (and drag-dropped straight
into Max). If it happens to find a similarly named XML file in the
directory, it loads that and transforms the content with a pre-loaded
XSL stylesheet to provide a summary of the model's size/face
count/etc. This is just for context though, just in case it is
relevant.

In response to complaints that it was running really slowly (from 6 to
13 seconds to scan a directory with 3 models in it), I made a copy of
the page to add debug timers to, so I could see where it was taking
all the time.

This copy completes in between 0.3 and 0.6 seconds for the same
directory.

The code is identical. I can cut and paste the code from the slow file
to the fast one (or vice versa) and it makes no difference to the
execution speed of either file. They both execute using the IUSR_foo
account on the webserver. They are both in the same directory. The
directory they are reading from has read permission for "Everyone".

What gives? How is this possible? What is IIS doing differently for
the two pages? Surely IIS should recompile a page if its modified date
changes, so how can it compile two different execution schemes for the
same code?

The fix for me is to use the new page and not the old one, but I
really want to know what is going on here.

Server is IIS5.0 on Windows 2000 Server

 

[Patrice]

Have you found where exactly the time difference is ?

For now it looks like to me that you see fast running server side code under
all circumstances. If yes , the delay experienced by users is IMO the time
taken to download all the 3D models so that they can be viewed by the
(multiple) ActiveX control(s) hosted in your HTML page...

If yes, you could try to donwload only those models the user actually wants
to use...

Patrice

 

[Mark Schupp]

Rename the "slow" file, then make a copy of the "fast" file with the "slow"
file name. Is it still slow?

Are you calling both files exactly the same way (by a link, form post, etc)?
If you are calling by a link or form post swap the links and see if the
performance problem follows the link.

 

[MikeT]

Rename the "slow" file, then make a copy of the "fast" file with the "slow"
file name. Is it still slow?

The file with the "slow" name becomes slow. The one that was slow
becomes fast This kinda proves that it's something IIS is doing
when executing the code. The same thing happens with a second page in
the same directory that is used as a detailed view for a particular
model. Again, making a new file with a new name speeds up the code,
but the slowdown is associated with the filename and not the code
itself.

Are you calling both files exactly the same way (by a link, form post, etc)?
If you are calling by a link or form post swap the links and see if the
performance problem follows the link.

I'm typing in a direct URL to the page with the same parameter (a
directory
path to scan) for each.

Have you found where exactly the time difference is ?

Inserting more timing checks makes it clear that one page is taking
around 2 seconds to run through the files in a directory, the other
<0.2 seconds. Specifically, it's taking a long time to get a file's
name. The code makes repeated use of objFile.Name. Caching this name
in a string (which I should have been doing anyway, doh) speeds up
BOTH pages immensely, but the slow down factor for the files is still
around 16 to 1. So it's the FileSystemObject that's got the problem.
Why would getting a file name be so slow?

For now it looks like to me that you see fast running server side code
under all circumstances.

Nope - the timings are being done on the server side, the activeX
loads
the models clientside, so won't slow down the execution of the ASP.

If yes, you could try to donwload only those models the user actually
wants to use...

Point taken, but this is a model library browser - they don't know
what
model they are looking for, they are browsing, say, 100 office chairs
looking
for the right one for the scheme they are modelling.


Hmm. It looks like IIS has cached something to do with the page's
name that
isn't getting reset when the page is edited. I'll try restarting the
IIS server, but if that fails I'm assuming the IIS metabase has got
corrupted for the files that were in that directory, but it's beyond
me what it might have cached that affects behaviour in this way.


Here's the code for the loop that is being so slow:
(splittime is my debug code that logs the elapsed time in milliseconds
for each call, and writeGalleryModel just outputs the HTML based on
the available files, fso is a global fileSystemObject)

sub listmodelsunder(libraryroot, librarywebroot, subpath, preview)

dim thisFolder, subFolder, file
dim bestproxyfile
dim proxyfile
dim xmlfile
dim maxfile
dim vrmlfile

dim filename

set thisfolder = fso.GetFolder(libraryroot & subpath)
proxyfile = ""
xmlfile = ""
maxfile = ""
vrmlfile = ""

splittime(libraryroot & subpath)
for each file in thisFolder.Files

filename = file.Name 'THIS IS THE CALL THAT TAKES 16 TIMES LONGER
ON ONE PAGE
splittime(filename & " start")
select case fileextension(filename)
case "jpg"
if proxyfile = "" then proxyfile = filename

if instr(1,filename,"best",1) > 0 then bestproxyfile =filename
if instr(1,filename,preview,1) > 0 then proxyfile = filename

case "max"
if maxfile = "" then
maxfile = filename
else
if filename = thisFolder.Name & ".max" then
maxfile = filename
end if
end if

case "xml"
if instr(1,filename,"fileproperties",1) > 0 then xmlfile =
filename

case "wrl"
if vrmlfile = "" and preview = "3d" then vrmlfile = filename

end select

splittime(filename & " end")
next
splittime("scan complete")
if proxyfile = "" or preview = "3d" then proxyfile = bestproxyfile

if maxfile<>"" then 'this directory is a model, list it
writeGalleryModel library & subpath, librarywebroot & subpath,
proxyfile, maxfile, xmlfile, vrmlfile
modelcount = modelcount + 1
else
for each subFolder in thisFolder.subFolders
listmodelsunder libraryroot, librarywebroot, subpath & "/" &
subFolder.Name, preview
next
end if

set thisfolder = nothing
end sub

 

[Aaron [SQL Server MVP]]

the two pages? Surely IIS should recompile a page if its modified date

changes,

Should != does. Did you restart IIS?

 

[MikeT]

Should != does. Did you restart IIS?

I tried this at lunchtime - no difference to the pages at all:
anything using the original name is slow when using the
filesystemobject, the same code under a new name runs at normal
speed. This is getting silly.

Mike

 

[Aaron [SQL Server MVP]]

See the last section of http://www.aspfaq.com/2022 ... you may be able to
resolve this by dropping the application and re-creating it.

 

[Bob Barrows [MVP]]

I tried this at lunchtime - no difference to the pages at all:
anything using the original name is slow when using the
filesystemobject, the same code under a new name runs at normal
speed. This is getting silly.

Mike

What are the filenames? (grasping at straws)

 

[Mark Schupp]

See Aaron's response. If that doesn't help:

Is the slow page slow when called a second time with the same parameters?
Does it make a difference which page is called first?

restart web-server (re-boot if possible)
1. call slow page
2. call fast page
restart web-server again
3. call fast page
4. call slow page

 

[MikeT]

What are the filenames? (grasping at straws)

The slow ones are called gallery.asp and model.asp - both sub frames
of a simple two frame default.asp.

I copied the files and named them gallery2.asp and model2.asp and then
linked those names instead in the default.asp page to end up with a
normal running app.

So - I've 'fixed' the problem but still no closer to tracking this
down. Off to try Aaron's suggestion from the FAQ.

Mike

 

[MikeT]

See Aaron's response. If that doesn't help:

Is the slow page slow when called a second time with the same parameters?
Does it make a difference which page is called first?

restart web-server (re-boot if possible)
1. call slow page
2. call fast page
restart web-server again
3. call fast page
4. call slow page

OK Tried Aaron's idea, no joy.

But whilst I was logged into the webserver I checked the page
permissions again - the "slow" page was using a domain IUSR account we
set up ages ago when the libraries were on a different server to the
current one. The "fast" page was using the default local IUSR account.
The library itself couldn't care less as it has Everyone: read
permissions.

So - the speed difference is caused by the different authentication
methods. Each and every reference to oFile.Name was costing me lots of
time when using a domain account. Ouch. Teach me to use such similar
account names.

Thanks for all the help folks. There's nobody here to talk these sort
of problems through with, and sometimes that's the only way to solve
them.

Mike

 

[Mark Schupp]

Aaron,

this sounds like a keeper. you do have a category on aspfaq for "weird and
mystifying" stuff don't you?

 

[MikeT]

Aaron,

this sounds like a keeper. you do have a category on aspfaq for "weird and
mystifying" stuff don't you?

When I have more time tomorrow, I'll see if I can narrow down the
behaviour to see exactly what the difference is, but the two major
gotchas are:

1) if you set things like the anonymous account used for
authentication on a page and then delete that page, a new page with
the name will inherit the old settings.

2) the filesystemobject appears to authenticate with every access to
an object. Well, at least, that is the only explanation I can find for
the behaviour I'm seeing. I'm going to be much more careful about
making lots of fso calls inside loops from now on - I've got a bunch
of other pages that I just thought were inherently slow that I'm going
to go back through now. The most useful page searches through around a
terabyte of Photoshop files so if I can speed that up, I'll be a very
happy man.

Mike