View Full Version : server.scripttimeout
BigDaddy
08-20-2003, 03:22 PM
I'm setting my server.scripttimeout to 180. That's already a fairly large amount of time, but pages have been timing out, so....
Anyway, setting it to 180, I notice no difference in the amount of time it waits to time out than from when it's set to 60, or 90.
The page seems to wait all of about 10-15 seconds before returning the standard "User requested cancel of operation" error.
Any idea if there is something other than scripttimeout that may affect this?
Are you sure it's the server that ends the script?
Can't it be the client machine that cancels the request? I know there is something like 'Keep Alive' request from the client but i never used it + you can't control it. The only thing you can do is set beffering to true to honor these request.
But if your script takes that long to proces ... then incrementing the timeout isn't probably the best sollution.
BigDaddy
08-20-2003, 04:21 PM
response.buffer = true?
Didn't do a thing. I'll keep checking. That might be it, though.
Roy Sinclair
08-20-2003, 04:56 PM
Be aware that other things used in your ASP page may also timeout, Queries via ADO is one thing I've had causing timeouts. Also double-check your page and make sure you aren't overriding the timeout value in that page since you can override the default timeout on a page by page basis.
IdentityCrisis
08-20-2003, 05:02 PM
Originally posted by BigDaddy
I'm setting my server.scripttimeout to 180.
It sounds like he's already setting his scriptTimeout from the ASP page... You should try setting the default in IIS (or whatever webserver you're using) to 180, and see how it goes...
Your script (Server.ScriptTimeout = 180) should work... but you may want to back yourself up this way as well
As Roy said, be sure to check to see if you're setting it twice in the same page... that will throw everything off...
IdentityCrisis
08-20-2003, 05:05 PM
Just another note: You do NOT need to re-set the ScriptTimeout in all your ASP pages, it will automatically use the server default (which again, you can set) unless you specifically tell it otherwise. Changing the timeout is on a per-page basis.
You should try setting the default in IIS (or whatever webserver you're using) to 180, and see how it goes...
I really wouldn't try that. Since there's no way you could lower it then inside your ASP pages --> if you'd set it in your ASP to 90, then it would still stay active till 180.
This is not something you can hack on a development machine, since you'll never be able to put it in production with a lower timeout-value.
The IIS timout should be as low as possible, and in the page where you need a higher timout, you can specify a higher timout.
And as Mr Sinclair said : it's probably another proces that times out.
I think that the easiest way to debug this, is to set
response.buffer = True at the very top of the page (first line)
and then place a
response.write("Step1 at" & Time)
response.flush
at strategical points. (before opening the connection or recordset or ...)
This way you can see how far the script runs.
BigDaddy
08-20-2003, 08:24 PM
Thanks, I'll try that raf.
IdentityCrisis
08-20-2003, 08:24 PM
Sorry... I'm assuming that he's set up his website as an application (Web Application)... that way, he can change the timeout for that application (not the IIS default for everything)
You don't need to apologise or explain yourself here :D IdentityCrisis. We're all friend and i'm quite impressed about the posts you made.
Anyway. A timeout of 90 is already way to much. No script that responds to a webclient should run that long. So you need to track the timeconsumer down and solve it.
BigDaddy,
are you connecting to that server through a proxy ?
BigDaddy
08-20-2003, 09:03 PM
I know what the timeout is. It's a big honkin query I'm doing. I give the user the ability to search for a person by name, or id #, or if neither is given, I return all members of the group. This particular group is pretty large, so it's just timing out on that.
Like I said....it's running maybe 15 seconds, then giving me that error.
Roy Sinclair
08-20-2003, 09:10 PM
Add a "top 300" clause or something like that to the SQL to "shorten" the time it takes to run that query, unless you want it to be possible to get all of the records on one page.
BigDaddy
08-20-2003, 10:22 PM
Yeah....unfortunately I do have to bring back all of them. I might just require at least one of the fields. I'm doing a "like" search on the name. But, this page was not originally written by me, so the blank search thing was allowed.
BigDaddy
08-20-2003, 10:22 PM
Yeah....unfortunately I do have to bring back all of them. I might just require at least one of the fields. I'm doing a "like" search on the name. But, this page was not originally written by me, so the blank search thing was allowed.
Even if you need to return all records, then you can still do some recordset paging, and return them in chunks of 100 user or so. No ?
Also, if you need some processing on the recordsets and wan't to keep the connectiontime as short as possible, then use GetRows.
http://www.devguru.com/Technologies/ado/quickref/recordset_getrows.html
BigDaddy
08-21-2003, 12:25 AM
Actually, you've got a good point. I've never really done paging, but it'd be a good excuse to learn it. Every now and then I have a day or two between projects where I'm able to play.
Thanks, raf.
Roy Sinclair
08-21-2003, 02:42 PM
If you really, really need to run a long query via ADO you can alter the "timeout" property of the "Command" object, if you don't use a command object then you can alter the "CommandTimeout" property of the "Connection" object. The former property is poorly documented while the latter property is near impossible to find which is a way of saying I've got a couple cases where really long running queries can happen too.
BigDaddy
08-21-2003, 02:44 PM
Actually, that's what I'm going to attempt to do first, is alter the connection time.
vBulletin® v3.8.2, Copyright ©2000-2012, Jelsoft Enterprises Ltd.