Web Service vs ASP page

[Krammig]

Thanks for reading. To date I have been using ASP server side pages to accept communication from my VB apps and also of late a couple of Mobile apps I have.

The ASP pages accept http / xml and do the processing, returning a response to the remote apps.

One of the mobile apps does use a web service that I set up, written in VB.Net

My question now relates specifically to the mobile apps and the expected increase in users. Specifically ;

a) response time
b) server load
c) security

What I would like to know is, taking into account the above 3 items, with the expectation of say 100,000 users devices, what is best for ;

i) minimal server load
ii) best response time
iii) best security

While I am reasonably technical I know very little about how a web service runs compared to an ASP page.

For example, is an instance of the web service loaded every time a user hits that service ?
and how does that compare to an ASP approach if say 300 requests come in at the same moment.

Appreciate any comments and thoughts,

thanks

[Old Pedant]

Ummm...doesn't a web service use an ".aspx" file name extension?

That means that it *IS* a web page. It just happens to send its data in SOAP format, not in HTML format. So there's no real change in how the page is invoked vs. a standard ASP.NET page.

It is true that a web service typically doesn't need to establish a session, so there's a (relatively minor) savings there.

But I think if you benchmarked 100,000 web service requests and compare them to 100,000 standard ASP.NET requests and did it so that the only real difference in the two was how the data is returned (SOAP vs. HTML), you'd see only the most minor of performance differences. The real performance hit on the server will usually be the database request time, not the actual generation of SOAP vs. HTML. And here is where you *can* improve things, both for a web service and for a typical ASP.NET page: Try very hard to make only one connection per request. Try very hard to optimize the queries used as far as possible (usually means using Stored Procedures vs. ad hoc SQL queries). And so on.

It's been 10 years since I benchmarked web services, and I'm sure things have improved in that time, but when I did it back then there was no truly measurable performance advantage or disadvantage.

[Old Pedant]

By the way, you kept saying "ASP pages". If you really *MEAN* classic ASP and not ASP.NET, then indeed ASP.NET for *either* web pages or web services will be much much faster than ASP in typical usage. ASP code, whether written in VBScript or JScript, will typically execute between 1 and 2 orders of magnitude slower than ASP.NET code, especially C# code or VB.NET code compiled with "option strict" (without "option strict", VB.NET can be up to twice as slow as C#, though usually it's more like 20% slower). Now, it's true that if 90% of your server-side time is spend doing database work, then even if C#/VB.NET is 100s of times vaster than VBScript/JScript your net performance gain won'e exceed 10%. Which again shows how important optimizing your DB work is.

[Krammig]

Thanks for the reply "Old Pedant" appreciated. I learnt a lot from those few para's.

Yes actually I was referring to classic ASP, should have stated that more clearly sorry.

So in summary then, I'll make sure the VB.NET code is compiled with "option strict", and I will have a closer look at the DB calls and see what I can optimize there.

You did mention Stored Procedures, a question.. Are there security exposures around using these ?
I seem to recall someone telling me a while back that these are things targeted with SQL injection hacks etc. Or did I misinterpret what I heard.

thanks

[alykins]

Originally Posted by Krammig

You did mention Stored Procedures, a question.. Are there security exposures around using these ?
I seem to recall someone telling me a while back that these are things targeted with SQL injection hacks etc. Or did I misinterpret what I heard.

thanks

Stored Procedures are an extremely efficient way to mitigate SQL injection, you must have misinterpreted.

[JohnnyCash]

Hi,
Asp dot net is also one of the most preferred scripting languages offered by Microsoft, used by thousands of developers around the world. Today, using ASP to build interactive websites has become easy with the introduction of various built-in tools and objects. Asp.net software development provides fast and concise results, in compare with other frameworks. This is because asp.net reduces the required amount of code considerably while development large applications. This further not only saves time, but also proves to be cost effective. It is also integrated with windows confirmation and per-application arrangement, which allows asp dot net software development to provide safe and secure results.

Thanks,
Johnny Cash

[Old Pedant]

Alykins speaks truth: Stored procedures used with parameterized queries (normal usage in ASP.NET) are the *BEST* way to avoid SQL Injection attacks.

Also, a properly designed SQL Server system that exclusively uses Stored Procedures for queries from ASP.NET (or any other client) provides the strongest possible data protection in many other ways.

For example, as a database administrator, you can import data and create and drop tables, create and drop indexes, etc., etc. And then you can create a *separate* user--the user account that ASP.NET will utilize--that has *ONLY* permission to execute stored procedures. And you can write the stored procedures to allow *ONLY* the actions you want to permit ASP.NET to perform. So even if some SQL Injection attack did succeed, it would not have permission to do all the really nasty things, such as drop tables and/or databases, because you don't have any Stored Procedures that will do those things.

[Old Pedant]

And, finally, all that I said about Stored Procedures with ASP.NET would still apply to Classic ASP. There's no reason you can't use Classic ASP exclusively with Stored Procedures and many reasons you should.

p.s.: And by the by, even if you are using MySQL and not SQL Server that would be true!