Date:         Wed, 22 Feb 2006 13:14:52 -0800
Reply-To:     David L Cassell <davidlcassell@MSN.COM>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         David L Cassell <davidlcassell@MSN.COM>
Subject:      Re: SPEDIS-based text matching application server?
In-Reply-To:  <200602221414.k1ME0icx021442@mailgw.cc.uga.edu>
Content-Type: text/plain; format=flowed

ben.powell@CLA.CO.UK wrote back:
>Don, thanks for more great suggestions. Well, you did it. You mentioned
>"sas
>spawn". Tell me, is there any reason not to have a front end web
>application
>coded in, say, C#, kick parameters into a sas batch program? The batch .sas
>could pick up the parameters from a flat file the C# prog writes... And
>*no*, I have not necessarily been talking to Alan :-)
>
>The process I'm interested in would be a read so, depending on scalability
>(linear?) this should not be an issue for multiple batch instances.
>
>Regarding interface, its the sort of thing that would really only be useful
>with a web front end, as opposed to an email response. As such, I think
>hardware would be one of the key factors. Running multiple instances would
>however mean you could not store the source dataset in memory... but this
>has drawbacks itself.
>
>For instance how about this for a spawner:
>
><batch file executed by C#>
>sas 'C:\Documents and Settings\Ben.powell.LICENCE\Desktop\batch_test.sas'
>-rsasuser -nolog -nosplash -no$syntaxcheck -config "C:\Program
>Files\SAS\SAS
>9.1\nls\en\SASV9.CFG";
></batch file>
>
>
>How exactly the front end would pick up the result set I don't know (though
>I could kludge a sas prog to watch for it; I guess there is an analogy for
>fileexists in .NET...)
>
>Regarding response times, it might be acceptable to proof the system for a
>certain size and build in a cutoff message such as "Server response delay,
>may be because of peak demand, please contact sysadmin"...?

A key point here is that you may either:

[1]  know ahead of time what many of the most popular queries are going to
be;
or
[2] be able to collect that information over time.

That means that you have extra options for reducing server load and
increasing
response time.  The most important option is pre-processing.

Run all the 'common' queries ahead of time, and store the results on disk.
Then
check the requests and immediately answer the common quesries, while only
sending the surprises back to the server.  This will make many users think
you're
a flipping genius for getting many of their queries done in milliseconds.
"How did
he get that stupid server to generate these answers that fast?  He deserves
a
raise!  And a company car.  He can have my daughter's old Lada."  :-)

The query-checking can be done at the front end, if you want.

HTH,
David
--
David L. Cassell
mathematical statistician
Design Pathways
3115 NW Norwood Pl.
Corvallis OR 97330

_________________________________________________________________
On the road to retirement? Check out MSN Life Events for advice on how to
get there! http://lifeevents.msn.com/category.aspx?cid=Retirement