How well will IIS scale up

[Guess]

The situation is as follows:
1. I would like to serve a web page that takes considerable time to
process.
2. While the page is processing, the client displays an appropriate wait
message.

What are the consequences of having this long processing page when there
are many simultaneous requests from many clients for the same page (say
75+).

I appreciate any opinions or suggestions.

Thanks

[This followup was posted to microsoft.public.dotnet.general and a copy
was sent to the cited author.]

[Cor Ligthert]

Guess,

Whatever you do, a page that is not showing new information in 3 seconds,
will let your user to go browsing or doing some other things, notifying him
will not help you with that.

When this is forever, it irritates and he stops going to your page.

(Assuming that he should not however has alternatives)

Just my thought,

Cor

[John Timney \(Microsoft MVP\)]

It all come down to how you scale your arhcitecture. You need to work out
your expected hit rate, and get some load testing software and simulate your
hits. When the server falls over with server 500 messages you have exceeded
your maximum hits. If it is greater than your expected hit rate then you
need to scale out or up, or rework your application.

--
Regards

John Timney
Microsoft Regional Director
Microsoft MVP

"Guess" <in******@aol.com> wrote in message
news:MP************************@news-server.socal.rr.com...

The situation is as follows:
1. I would like to serve a web page that takes considerable time to
process.
2. While the page is processing, the client displays an appropriate wait
message.

What are the consequences of having this long processing page when there
are many simultaneous requests from many clients for the same page (say
75+).

I appreciate any opinions or suggestions.

Thanks

[This followup was posted to microsoft.public.dotnet.general and a copy
was sent to the cited author.]

[Guess]

[This followup was posted to microsoft.public.dotnet.general and a copy
was sent to the cited author.]

In article <ul**************@TK2MSFTNGP15.phx.gbl>, "John Timney
\(Microsoft MVP\)" <ti*****@despammed.com> says...

It all come down to how you scale your arhcitecture. You need to work out
your expected hit rate, and get some load testing software and simulate your
hits. When the server falls over with server 500 messages you have exceeded
your maximum hits. If it is greater than your expected hit rate then you
need to scale out or up, or rework your application.

--
Regards

John Timney
Microsoft Regional Director
Microsoft MVP

"Guess" <in******@aol.com> wrote in message
news:MP************************@news-server.socal.rr.com...

The situation is as follows:
1. I would like to serve a web page that takes considerable time to
process.
2. While the page is processing, the client displays an appropriate wait
message.

What are the consequences of having this long processing page when there
are many simultaneous requests from many clients for the same page (say
75+).

I appreciate any opinions or suggestions.

Thanks

[This followup was posted to microsoft.public.dotnet.general and a copy
was sent to the cited author.]

Thanks for your thoughts!

So, you are saying that IIS is capable holding a large number of waiting
threads?. The processes that I plan to wait for a Web Services running
on some other farm of servers.
I am thinking of using BigIP to manage the farm of IIS boxes, as well as
another BigIP box to manage the farm of Web Services handlers. When the
number of requests is not over a threshold, we will process by letting
the thread wait for the Web Service response before responding to the
client.
If however, the number of requests is over the thresshold, we will make
an appropriate entry in a database, and immediatelly return to the
client. The processing will still be done, but now instigated by some
process in SQL Server that will interact with the Web Service.

[John Timney \(Microsoft MVP\)]

IIS can scale a server farm to a massive level, so technically it could
scale out to whatever your requriements are - but with scale out comes
expense. This is where you have to consider how your app is architected,
and if your propsed design is appropriate.

--
Regards

John Timney
Microsoft Regional Director
Microsoft MVP
"Guess" <in******@aol.com> wrote in message
news:MP************************@news-server.socal.rr.com...

[This followup was posted to microsoft.public.dotnet.general and a copy
was sent to the cited author.]

In article <ul**************@TK2MSFTNGP15.phx.gbl>, "John Timney
\(Microsoft MVP\)" <ti*****@despammed.com> says...

It all come down to how you scale your arhcitecture. You need to work out your expected hit rate, and get some load testing software and simulate your hits. When the server falls over with server 500 messages you have exceeded your maximum hits. If it is greater than your expected hit rate then you need to scale out or up, or rework your application.

--
Regards

John Timney
Microsoft Regional Director
Microsoft MVP

"Guess" <in******@aol.com> wrote in message
news:MP************************@news-server.socal.rr.com...

The situation is as follows:
1. I would like to serve a web page that takes considerable time to
process.
2. While the page is processing, the client displays an appropriate wait message.

What are the consequences of having this long processing page when there are many simultaneous requests from many clients for the same page (say 75+).

I appreciate any opinions or suggestions.

Thanks

[This followup was posted to microsoft.public.dotnet.general and a copy was sent to the cited author.]

Thanks for your thoughts!

So, you are saying that IIS is capable holding a large number of waiting
threads?. The processes that I plan to wait for a Web Services running
on some other farm of servers.
I am thinking of using BigIP to manage the farm of IIS boxes, as well as
another BigIP box to manage the farm of Web Services handlers. When the
number of requests is not over a threshold, we will process by letting
the thread wait for the Web Service response before responding to the
client.
If however, the number of requests is over the thresshold, we will make
an appropriate entry in a database, and immediatelly return to the
client. The processing will still be done, but now instigated by some
process in SQL Server that will interact with the Web Service.

[Guess]

[This followup was posted to microsoft.public.dotnet.general and a copy
was sent to the cited author.]

In article <eL**************@TK2MSFTNGP15.phx.gbl>, "John Timney
\(Microsoft MVP\)" <ti*****@despammed.com> says...

IIS can scale a server farm to a massive level, so technically it could
scale out to whatever your requriements are - but with scale out comes
expense. This is where you have to consider how your app is architected,
and if your propsed design is appropriate.

--
Regards

John Timney
Microsoft Regional Director
Microsoft MVP
"Guess" <in******@aol.com> wrote in message
news:MP************************@news-server.socal.rr.com...

[This followup was posted to microsoft.public.dotnet.general and a copy
was sent to the cited author.]

In article <ul**************@TK2MSFTNGP15.phx.gbl>, "John Timney
\(Microsoft MVP\)" <ti*****@despammed.com> says...

It all come down to how you scale your arhcitecture. You need to work out your expected hit rate, and get some load testing software and simulate your hits. When the server falls over with server 500 messages you have exceeded your maximum hits. If it is greater than your expected hit rate then you need to scale out or up, or rework your application.

--
Regards

John Timney
Microsoft Regional Director
Microsoft MVP

"Guess" <in******@aol.com> wrote in message
news:MP************************@news-server.socal.rr.com...
> The situation is as follows:
> 1. I would like to serve a web page that takes considerable time to
> process.
> 2. While the page is processing, the client displays an appropriate wait > message.
>
> What are the consequences of having this long processing page when

there

I appreciate your comments. Currently our code makes and entry in the
database and responds immediatelly to the client. The reason is that we
feared that waiting threads (or isolated waiting processes) would bog
down the server requiring more processors. This was the case in IIS3.5
and IIS4.
I am not sure that it would not be so in IIS5, and that is the answer I
seek. Whether IIS5 (or 6), would have equivalent number of connections
per CPU when there are waiting threads or processes.

Thanks