If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Enjoy an ad free experience by logging in. Not a member yet? Register.

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.

Users who have thanked Old Pedant for this post:

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.

Users who have thanked Old Pedant for this post:

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.

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.

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.

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.

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!