Hi all, we are in the process of architecting a new application that will
have an asp.net front end & sql back end. In the past we have used
webservices as a middle tier solution but in terms of performance it has not
been upto the mark. Besides with the latest .net version there are some
known issues with calling web services (keepalives etc.). What other middle
tier solution does .net have to offer? What is .net remoting and how does it
work? Is it similar to DCOM? Does it have to run under IIS? I would like
something that is not dependent on IIS preferably. In our solution we will
be passing custom objects back and forth with the middle tier interacting
with the database.

Any help and guidance here is much appreciated!

thanks!

Remoting is certainly faster than an ASMX web service. You completely lose
the reliance on HTTP, which speeds things up quite a bit. If you want a SOA
type distributed architecture (web services style), Remoting is a good
option. It is a bit more time consuming to architect, over ASMX, but worth it
for the perf gains.

---

Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************

"Param R." wrote:

> Hi all, we are in the process of architecting a new application that will
> have an asp.net front end & sql back end. In the past we have used
> webservices as a middle tier solution but in terms of performance it has not
> been upto the mark. Besides with the latest .net version there are some
> known issues with calling web services (keepalives etc.). What other middle
> tier solution does .net have to offer? What is .net remoting and how does it
> work? Is it similar to DCOM? Does it have to run under IIS? I would like
> something that is not dependent on IIS preferably. In our solution we will
> be passing custom objects back and forth with the middle tier interacting
> with the database.
>
> Any help and guidance here is much appreciated!
>
> thanks!
>
>
>

So remoting runs independent of IIS? Does it communicate over tcp? What
port? Firewall restrictions? Also, I am a VB programmer. Could you point me
in the direction of some good articles on remoting for VB.

thanks!

"Cowboy (Gregory A. Beamer) - MVP" <(E-Mail Removed)> wrote
in message news:98915D46-6DDC-4E37-BFA8-(E-Mail Removed)...
> Remoting is certainly faster than an ASMX web service. You completely lose
> the reliance on HTTP, which speeds things up quite a bit. If you want a
> SOA
> type distributed architecture (web services style), Remoting is a good
> option. It is a bit more time consuming to architect, over ASMX, but worth
> it
> for the perf gains.
>
> ---
>
> Gregory A. Beamer
> MVP; MCP: +I, SE, SD, DBA
>
> ***************************
> Think Outside the Box!
> ***************************
>
> "Param R." wrote:
>
>> Hi all, we are in the process of architecting a new application that will
>> have an asp.net front end & sql back end. In the past we have used
>> webservices as a middle tier solution but in terms of performance it has
>> not
>> been upto the mark. Besides with the latest .net version there are some
>> known issues with calling web services (keepalives etc.). What other
>> middle
>> tier solution does .net have to offer? What is .net remoting and how does
>> it
>> work? Is it similar to DCOM? Does it have to run under IIS? I would like
>> something that is not dependent on IIS preferably. In our solution we
>> will
>> be passing custom objects back and forth with the middle tier interacting
>> with the database.
>>
>> Any help and guidance here is much appreciated!
>>
>> thanks!
>>
>>
>>

This article is an introduction to .Net remoting:

http://www.msdn.microsoft.com/librar...roremoting.asp

You will also find there is a .Net remoting newsgroup, which is very useful
(thanks to Ken Kolda and Sam Santiago). Also would recommend googling for
Ingo Rammer, who is an expert on .Net remoting and written a book on it.

To answer your questions, .Net remoted objects can communicate over http
(hosted in IIS) or tcp (hosted in windows service, console app, etc.). You
can even define your own channels. It also provides 2 in built formatters -
SOAP and binary. It is actually the formatter that makes the bigger
difference to performance (again, there is an article on MSDN comparing the
various options).

The tcp channel communicates over the port you specify. Obviously being tcp,
you will need to configure your firewalls apporpriately. One thing to note,
remoting has no built in secuirity. When hosted in IIS, you will be using
IIS's security feature. Hosting in IIS using the binary formatter will
perform better than using web services. Tcp/binary is the ultimate solution
in terms of performance.

Hope this helps
Dan

"Param R." wrote:

> So remoting runs independent of IIS? Does it communicate over tcp? What
> port? Firewall restrictions? Also, I am a VB programmer. Could you point me
> in the direction of some good articles on remoting for VB.
>
> thanks!
>
> "Cowboy (Gregory A. Beamer) - MVP" <(E-Mail Removed)> wrote
> in message news:98915D46-6DDC-4E37-BFA8-(E-Mail Removed)...
> > Remoting is certainly faster than an ASMX web service. You completely lose
> > the reliance on HTTP, which speeds things up quite a bit. If you want a
> > SOA
> > type distributed architecture (web services style), Remoting is a good
> > option. It is a bit more time consuming to architect, over ASMX, but worth
> > it
> > for the perf gains.
> >
> > ---
> >
> > Gregory A. Beamer
> > MVP; MCP: +I, SE, SD, DBA
> >
> > ***************************
> > Think Outside the Box!
> > ***************************
> >
> > "Param R." wrote:
> >
> >> Hi all, we are in the process of architecting a new application that will
> >> have an asp.net front end & sql back end. In the past we have used
> >> webservices as a middle tier solution but in terms of performance it has
> >> not
> >> been upto the mark. Besides with the latest .net version there are some
> >> known issues with calling web services (keepalives etc.). What other
> >> middle
> >> tier solution does .net have to offer? What is .net remoting and how does
> >> it
> >> work? Is it similar to DCOM? Does it have to run under IIS? I would like
> >> something that is not dependent on IIS preferably. In our solution we
> >> will
> >> be passing custom objects back and forth with the middle tier interacting
> >> with the database.
> >>
> >> Any help and guidance here is much appreciated!
> >>
> >> thanks!
> >>
> >>
> >>
>
>
>

What is driving the architecture? What are the key constraints?

Honestly, most applications are fine with an ASP.NET layer that calls a
simple middle layer, written as DLLs, that call SQL. That said, most
applications have fewer than 100 concurrent users. I'm going to venture a
guess that this doesn't apply to you.

How many servers have you set aside for this application?
How many users do you plan to serve with this application?
What is the nature of their use (continuous use for business day, occasional
light use, occasional heavy use, receiving a stream of information)?

In addition, you didn't provide the key constraints that drives the
architecture.
Do you have high uptime requirements (99.9% or better)?
Do you have variable scalability issues (sudden spikes that increase traffic
by an order of magnitude or more for a sustained period)?
Do you need to be able to modify the behavior of the system while it is
running due to the nature of competition in your business?
Do you have existing systems that you need to communicate with? If so, are
these systems designed for real-time communication or do you need to batch
things up?

Without at least a little of this information, my answer would be too vague
to be useful.

As for .NET remoting, it is a useful mechanism for designs that need to
partition the execution of the application onto multiple servers. The
marshalling is far more efficient than with web services, but it is still
marshalling... and if you are sending data sets across a marshalling
boundary, you are probably not designing your interfaces correctly.

An excellent book: Advanced .NET Remoting by Ingo Rammer.

HTH,
---- Nick

"Param R." <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
> Hi all, we are in the process of architecting a new application that will
> have an asp.net front end & sql back end. In the past we have used
> webservices as a middle tier solution but in terms of performance it has
not
> been upto the mark. Besides with the latest .net version there are some
> known issues with calling web services (keepalives etc.). What other
middle
> tier solution does .net have to offer? What is .net remoting and how does
it
> work? Is it similar to DCOM? Does it have to run under IIS? I would like
> something that is not dependent on IIS preferably. In our solution we will
> be passing custom objects back and forth with the middle tier interacting
> with the database.
>
> Any help and guidance here is much appreciated!
>
> thanks!
>
>

But I guess to setup TCP/binary there would be extra work needing to be done
in terms of writing my own listener etc? There is also a certain essence of
time in this project. I basically have 3 weeks. Could I start off with
running it in IIS and then moving to TCP later if needed?


thanks!

"Dan Kelley" <(E-Mail Removed)> wrote in message
news:01781DDF-385F-4CA1-8957-(E-Mail Removed)...
> This article is an introduction to .Net remoting:
>
> http://www.msdn.microsoft.com/librar...roremoting.asp
>
> You will also find there is a .Net remoting newsgroup, which is very
> useful
> (thanks to Ken Kolda and Sam Santiago). Also would recommend googling for
> Ingo Rammer, who is an expert on .Net remoting and written a book on it.
>
> To answer your questions, .Net remoted objects can communicate over http
> (hosted in IIS) or tcp (hosted in windows service, console app, etc.). You
> can even define your own channels. It also provides 2 in built
> formatters -
> SOAP and binary. It is actually the formatter that makes the bigger
> difference to performance (again, there is an article on MSDN comparing
> the
> various options).
>
> The tcp channel communicates over the port you specify. Obviously being
> tcp,
> you will need to configure your firewalls apporpriately. One thing to
> note,
> remoting has no built in secuirity. When hosted in IIS, you will be using
> IIS's security feature. Hosting in IIS using the binary formatter will
> perform better than using web services. Tcp/binary is the ultimate
> solution
> in terms of performance.
>
> Hope this helps
> Dan
>
> "Param R." wrote:
>
>> So remoting runs independent of IIS? Does it communicate over tcp? What
>> port? Firewall restrictions? Also, I am a VB programmer. Could you point
>> me
>> in the direction of some good articles on remoting for VB.
>>
>> thanks!
>>
>> "Cowboy (Gregory A. Beamer) - MVP" <(E-Mail Removed)>
>> wrote
>> in message news:98915D46-6DDC-4E37-BFA8-(E-Mail Removed)...
>> > Remoting is certainly faster than an ASMX web service. You completely
>> > lose
>> > the reliance on HTTP, which speeds things up quite a bit. If you want a
>> > SOA
>> > type distributed architecture (web services style), Remoting is a good
>> > option. It is a bit more time consuming to architect, over ASMX, but
>> > worth
>> > it
>> > for the perf gains.
>> >
>> > ---
>> >
>> > Gregory A. Beamer
>> > MVP; MCP: +I, SE, SD, DBA
>> >
>> > ***************************
>> > Think Outside the Box!
>> > ***************************
>> >
>> > "Param R." wrote:
>> >
>> >> Hi all, we are in the process of architecting a new application that
>> >> will
>> >> have an asp.net front end & sql back end. In the past we have used
>> >> webservices as a middle tier solution but in terms of performance it
>> >> has
>> >> not
>> >> been upto the mark. Besides with the latest .net version there are
>> >> some
>> >> known issues with calling web services (keepalives etc.). What other
>> >> middle
>> >> tier solution does .net have to offer? What is .net remoting and how
>> >> does
>> >> it
>> >> work? Is it similar to DCOM? Does it have to run under IIS? I would
>> >> like
>> >> something that is not dependent on IIS preferably. In our solution we
>> >> will
>> >> be passing custom objects back and forth with the middle tier
>> >> interacting
>> >> with the database.
>> >>
>> >> Any help and guidance here is much appreciated!
>> >>
>> >> thanks!
>> >>
>> >>
>> >>
>>
>>
>>

Nick, to answer your questions:-

1. 2 Web Servers & 1 Database
2. Starting out 2000+ users.
3. Continuous business use M-S 8-7.
4. 99.99% (8 a.m. - 10 p.m.)
5. During peak times we could see a sudden spike in usage.
6. YES. Realtime modification is a necessity.
7. Limited communication with existing systems - in realtime.

It is all about speed for this project. If the web pages are slow and the
apps take time to execute then the business starts losing $$...

thanks!

"Nick Malik" <(E-Mail Removed)> wrote in message
news:FKqpd.565167$mD.516047@attbi_s02...
> What is driving the architecture? What are the key constraints?
>
> Honestly, most applications are fine with an ASP.NET layer that calls a
> simple middle layer, written as DLLs, that call SQL. That said, most
> applications have fewer than 100 concurrent users. I'm going to venture a
> guess that this doesn't apply to you.
>
> How many servers have you set aside for this application?
> How many users do you plan to serve with this application?
> What is the nature of their use (continuous use for business day,
> occasional
> light use, occasional heavy use, receiving a stream of information)?
>
> In addition, you didn't provide the key constraints that drives the
> architecture.
> Do you have high uptime requirements (99.9% or better)?
> Do you have variable scalability issues (sudden spikes that increase
> traffic
> by an order of magnitude or more for a sustained period)?
> Do you need to be able to modify the behavior of the system while it is
> running due to the nature of competition in your business?
> Do you have existing systems that you need to communicate with? If so,
> are
> these systems designed for real-time communication or do you need to batch
> things up?
>
> Without at least a little of this information, my answer would be too
> vague
> to be useful.
>
> As for .NET remoting, it is a useful mechanism for designs that need to
> partition the execution of the application onto multiple servers. The
> marshalling is far more efficient than with web services, but it is still
> marshalling... and if you are sending data sets across a marshalling
> boundary, you are probably not designing your interfaces correctly.
>
> An excellent book: Advanced .NET Remoting by Ingo Rammer.
>
> HTH,
> ---- Nick
>
> "Param R." <(E-Mail Removed)> wrote in message
> news:%(E-Mail Removed)...
>> Hi all, we are in the process of architecting a new application that will
>> have an asp.net front end & sql back end. In the past we have used
>> webservices as a middle tier solution but in terms of performance it has
> not
>> been upto the mark. Besides with the latest .net version there are some
>> known issues with calling web services (keepalives etc.). What other
> middle
>> tier solution does .net have to offer? What is .net remoting and how does
> it
>> work? Is it similar to DCOM? Does it have to run under IIS? I would like
>> something that is not dependent on IIS preferably. In our solution we
>> will
>> be passing custom objects back and forth with the middle tier interacting
>> with the database.
>>
>> Any help and guidance here is much appreciated!
>>
>> thanks!
>>
>>
>
>

Nick -

Along the lines of what Param said -- remoting & web services would be
useful if your middle tier were on its own machine, but IMO the MT should
only be its own box if you are doing some serious CPU-intensive tasks in
your middle tier (which I am assuming you are not) or if you have some other
reason.

So IMO your middle tier should be .NET assemblies/DLLs & be on the web
server (i.e. the same machine as the ASP.NET pages), referenced & called
from ASP.NET just like other assemblies. No web services, no soap, no
remoting. That keeps it simpler, faster, more reliable.

We did the whole 3 physical tier thing years ago & it was not worth it.

--
Ben Strackany
www.developmentnow.com

<a href="http://www.developmentnow.com">dn</a>


"Param R." <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Nick, to answer your questions:-
>
> 1. 2 Web Servers & 1 Database
> 2. Starting out 2000+ users.
> 3. Continuous business use M-S 8-7.
> 4. 99.99% (8 a.m. - 10 p.m.)
> 5. During peak times we could see a sudden spike in usage.
> 6. YES. Realtime modification is a necessity.
> 7. Limited communication with existing systems - in realtime.
>
> It is all about speed for this project. If the web pages are slow and the
> apps take time to execute then the business starts losing $$...
>
> thanks!
>
> "Nick Malik" <(E-Mail Removed)> wrote in message
> news:FKqpd.565167$mD.516047@attbi_s02...
> > What is driving the architecture? What are the key constraints?
> >
> > Honestly, most applications are fine with an ASP.NET layer that calls a
> > simple middle layer, written as DLLs, that call SQL. That said, most
> > applications have fewer than 100 concurrent users. I'm going to venture
a
> > guess that this doesn't apply to you.
> >
> > How many servers have you set aside for this application?
> > How many users do you plan to serve with this application?
> > What is the nature of their use (continuous use for business day,
> > occasional
> > light use, occasional heavy use, receiving a stream of information)?
> >
> > In addition, you didn't provide the key constraints that drives the
> > architecture.
> > Do you have high uptime requirements (99.9% or better)?
> > Do you have variable scalability issues (sudden spikes that increase
> > traffic
> > by an order of magnitude or more for a sustained period)?
> > Do you need to be able to modify the behavior of the system while it is
> > running due to the nature of competition in your business?
> > Do you have existing systems that you need to communicate with? If so,
> > are
> > these systems designed for real-time communication or do you need to
batch
> > things up?
> >
> > Without at least a little of this information, my answer would be too
> > vague
> > to be useful.
> >
> > As for .NET remoting, it is a useful mechanism for designs that need to
> > partition the execution of the application onto multiple servers. The
> > marshalling is far more efficient than with web services, but it is
still
> > marshalling... and if you are sending data sets across a marshalling
> > boundary, you are probably not designing your interfaces correctly.
> >
> > An excellent book: Advanced .NET Remoting by Ingo Rammer.
> >
> > HTH,
> > ---- Nick
> >
> > "Param R." <(E-Mail Removed)> wrote in message
> > news:%(E-Mail Removed)...
> >> Hi all, we are in the process of architecting a new application that
will
> >> have an asp.net front end & sql back end. In the past we have used
> >> webservices as a middle tier solution but in terms of performance it
has
> > not
> >> been upto the mark. Besides with the latest .net version there are some
> >> known issues with calling web services (keepalives etc.). What other
> > middle
> >> tier solution does .net have to offer? What is .net remoting and how
does
> > it
> >> work? Is it similar to DCOM? Does it have to run under IIS? I would
like
> >> something that is not dependent on IIS preferably. In our solution we
> >> will
> >> be passing custom objects back and forth with the middle tier
interacting
> >> with the database.
> >>
> >> Any help and guidance here is much appreciated!
> >>
> >> thanks!
> >>
> >>
> >
> >
>
>

Hi Param,

1. Do not seperate your application into physical tiers. Use logical
tiers. You do not need physical tiers. The cost of marshalling will far
exceed the benefit of multi-processing. SOAP won't help, Remoting won't
help. They are both forms of marshalling. Besides, you don't have an
application server on which to put the remoted component!

2. You are about three machines short in your configuration. If the usage
and uptime are what you say they are, you need one more database server as
failover, one more web server (at least) to support the load, especially to
cope with sudden spikes, and you need a load balancer in front of your web
servers. I hope that your web servers are dual proc, with 2GB of RAM
running Windows Server 2003. Your DB servers should be quad-proc running
Windows Advanced Server 2003 Datacenter Edition with SQL Server 2000 EE (at
least until Yukon comes out). This version of SQL provides some interesting
possibilities when it comes to failover, which is like insurance... you
complain about the cost until you need it, and they you consider yourself
smart for having bought it.

3. Real-time modification can be done, but it requires some forethought.
Most modifications will require you to stop and restart your system, which
ruins that 99.99% uptime record. (4 nines, in your window = 26 minutes of
downtime per year). If you can wait until after 10pm to make a code change,
your app is easier to create and update because you can simply replace a
component, restart IIS, and you are done. On the other hand, if you can
code some rules in the database, you can make immediate changes by making
sure that your app reads the rules periodically. (Downside: you won't know
which transactions took place under the old rules and which under the new
rules... This little tidbit is chewing on one of the apps that my team is
currently supporting. Not fun.) The third possibility, and the hardest to
do well, is a pluggable architecture. You have to have some form of
reliable communication mechanism between components if you want to do this
(either using LoadLibrary to bring components into play, or MSMQ to allow
messages to pile up while you replace a component, or using a web service
that you can bring down, replace the component and bring back up while your
application copes.). This is hard stuff. Don't do it if you can avoid
it... the bugs alone can eat your budget.

4. If speed is of the essence, take as much processing out of the critical
path as possible. If there is something that can be done by a service, on
the side, or even in a seperate thread, that's better than making the user
wait. Burden the user as little as possible with a complicated user
interface. For speed, you need simple, even if it means that you have
different screens that appear for different people to do similar things.
Tailor the interface to the user's typing styles, mouse usage styles, and
normal points where they would wait for something, and you will gain more
speed than worrying about multi-processing designs.
If your app is a web app, minimize the size of the pages. Reduce the amount
of javascript. Don't download huge lists of items for a drop down control.
Even on a LAN, a big page takes a second to download, and those seconds add
up.

I hope this is helpful.

--- Nick

"Param R." <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Nick, to answer your questions:-
>
> 1. 2 Web Servers & 1 Database
> 2. Starting out 2000+ users.
> 3. Continuous business use M-S 8-7.
> 4. 99.99% (8 a.m. - 10 p.m.)
> 5. During peak times we could see a sudden spike in usage.
> 6. YES. Realtime modification is a necessity.
> 7. Limited communication with existing systems - in realtime.
>
> It is all about speed for this project. If the web pages are slow and the
> apps take time to execute then the business starts losing $$...
>
> thanks!
>
> "Nick Malik" <(E-Mail Removed)> wrote in message
> news:FKqpd.565167$mD.516047@attbi_s02...
> > What is driving the architecture? What are the key constraints?
> >
> > Honestly, most applications are fine with an ASP.NET layer that calls a
> > simple middle layer, written as DLLs, that call SQL. That said, most
> > applications have fewer than 100 concurrent users. I'm going to venture
a
> > guess that this doesn't apply to you.
> >
> > How many servers have you set aside for this application?
> > How many users do you plan to serve with this application?
> > What is the nature of their use (continuous use for business day,
> > occasional
> > light use, occasional heavy use, receiving a stream of information)?
> >
> > In addition, you didn't provide the key constraints that drives the
> > architecture.
> > Do you have high uptime requirements (99.9% or better)?
> > Do you have variable scalability issues (sudden spikes that increase
> > traffic
> > by an order of magnitude or more for a sustained period)?
> > Do you need to be able to modify the behavior of the system while it is
> > running due to the nature of competition in your business?
> > Do you have existing systems that you need to communicate with? If so,
> > are
> > these systems designed for real-time communication or do you need to
batch
> > things up?
> >
> > Without at least a little of this information, my answer would be too
> > vague
> > to be useful.
> >
> > As for .NET remoting, it is a useful mechanism for designs that need to
> > partition the execution of the application onto multiple servers. The
> > marshalling is far more efficient than with web services, but it is
still
> > marshalling... and if you are sending data sets across a marshalling
> > boundary, you are probably not designing your interfaces correctly.
> >
> > An excellent book: Advanced .NET Remoting by Ingo Rammer.
> >
> > HTH,
> > ---- Nick
> >
> > "Param R." <(E-Mail Removed)> wrote in message
> > news:%(E-Mail Removed)...
> >> Hi all, we are in the process of architecting a new application that
will
> >> have an asp.net front end & sql back end. In the past we have used
> >> webservices as a middle tier solution but in terms of performance it
has
> > not
> >> been upto the mark. Besides with the latest .net version there are some
> >> known issues with calling web services (keepalives etc.). What other
> > middle
> >> tier solution does .net have to offer? What is .net remoting and how
does
> > it
> >> work? Is it similar to DCOM? Does it have to run under IIS? I would
like
> >> something that is not dependent on IIS preferably. In our solution we
> >> will
> >> be passing custom objects back and forth with the middle tier
interacting
> >> with the database.
> >>
> >> Any help and guidance here is much appreciated!
> >>
> >> thanks!
> >>
> >>
> >
> >
>
>

Hi Nick, thanks a bunch for the useful info.

1. I forgot to mention I do have a standby database server for failover. The
only thing is that it is a cold standby. We are running Standard Edition.
Currently we cannot afford EE.
2. We use Windows Load Balancing between the 2 webservers. They are single
CPU with 1GB RAM. I am planning on adding 1GB more of RAM. Unfortunately I
do not have a budget for a 3rd box and a load balancer.
3. I agree with you on the pages being "skinny". The customer base we are
targeting, if the pages are slow, they will go elsewhere.A lot of them are
on dialups.
4. I can get away with realtime modifications after 10, so I can keep it
simple for now.
5. I know the cost of marshalling is high. I was coming from a "code
re-usability" / plug-n-play standpoint. If tomorrow I need to expose an
interface to an external partner I can simply write a web service layer over
the business logic/data layer to exchange data? OR if the growth is
tremendous then I can go get servers that will just run the middle tier? I
come from the good old days of COM/COM+ where MS was pushing the whole
n-tier philosophy. Does the same apply to .net 1.1 and the upcoming 2.0?
6. Talking about server 2003, we just recently upgraded a few of our apps
from 2000 to 2003 and have begun to see significant slow page load &
response times. Most of our sites run over SSL and we cant seem to find the
problem. Same hardware. Our network guys are working on it but havent struck
gold as yet. From reading various posts on these NGs it seems 2003 has some
inherent performance issues with IIS

thanks!


"Nick Malik" <(E-Mail Removed)> wrote in message
news:dpLpd.671757$8_6.668758@attbi_s04...
> Hi Param,
>
> 1. Do not seperate your application into physical tiers. Use logical
> tiers. You do not need physical tiers. The cost of marshalling will far
> exceed the benefit of multi-processing. SOAP won't help, Remoting won't
> help. They are both forms of marshalling. Besides, you don't have an
> application server on which to put the remoted component!
>
> 2. You are about three machines short in your configuration. If the
> usage
> and uptime are what you say they are, you need one more database server as
> failover, one more web server (at least) to support the load, especially
> to
> cope with sudden spikes, and you need a load balancer in front of your web
> servers. I hope that your web servers are dual proc, with 2GB of RAM
> running Windows Server 2003. Your DB servers should be quad-proc running
> Windows Advanced Server 2003 Datacenter Edition with SQL Server 2000 EE
> (at
> least until Yukon comes out). This version of SQL provides some
> interesting
> possibilities when it comes to failover, which is like insurance... you
> complain about the cost until you need it, and they you consider yourself
> smart for having bought it.
>
> 3. Real-time modification can be done, but it requires some forethought.
> Most modifications will require you to stop and restart your system, which
> ruins that 99.99% uptime record. (4 nines, in your window = 26 minutes of
> downtime per year). If you can wait until after 10pm to make a code
> change,
> your app is easier to create and update because you can simply replace a
> component, restart IIS, and you are done. On the other hand, if you can
> code some rules in the database, you can make immediate changes by making
> sure that your app reads the rules periodically. (Downside: you won't
> know
> which transactions took place under the old rules and which under the new
> rules... This little tidbit is chewing on one of the apps that my team is
> currently supporting. Not fun.) The third possibility, and the hardest
> to
> do well, is a pluggable architecture. You have to have some form of
> reliable communication mechanism between components if you want to do this
> (either using LoadLibrary to bring components into play, or MSMQ to allow
> messages to pile up while you replace a component, or using a web service
> that you can bring down, replace the component and bring back up while
> your
> application copes.). This is hard stuff. Don't do it if you can avoid
> it... the bugs alone can eat your budget.
>
> 4. If speed is of the essence, take as much processing out of the critical
> path as possible. If there is something that can be done by a service, on
> the side, or even in a seperate thread, that's better than making the user
> wait. Burden the user as little as possible with a complicated user
> interface. For speed, you need simple, even if it means that you have
> different screens that appear for different people to do similar things.
> Tailor the interface to the user's typing styles, mouse usage styles, and
> normal points where they would wait for something, and you will gain more
> speed than worrying about multi-processing designs.
> If your app is a web app, minimize the size of the pages. Reduce the
> amount
> of javascript. Don't download huge lists of items for a drop down
> control.
> Even on a LAN, a big page takes a second to download, and those seconds
> add
> up.
>
> I hope this is helpful.
>
> --- Nick
>
> "Param R." <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> Nick, to answer your questions:-
>>
>> 1. 2 Web Servers & 1 Database
>> 2. Starting out 2000+ users.
>> 3. Continuous business use M-S 8-7.
>> 4. 99.99% (8 a.m. - 10 p.m.)
>> 5. During peak times we could see a sudden spike in usage.
>> 6. YES. Realtime modification is a necessity.
>> 7. Limited communication with existing systems - in realtime.
>>
>> It is all about speed for this project. If the web pages are slow and the
>> apps take time to execute then the business starts losing $$...
>>
>> thanks!
>>
>> "Nick Malik" <(E-Mail Removed)> wrote in message
>> news:FKqpd.565167$mD.516047@attbi_s02...
>> > What is driving the architecture? What are the key constraints?
>> >
>> > Honestly, most applications are fine with an ASP.NET layer that calls a
>> > simple middle layer, written as DLLs, that call SQL. That said, most
>> > applications have fewer than 100 concurrent users. I'm going to
>> > venture
> a
>> > guess that this doesn't apply to you.
>> >
>> > How many servers have you set aside for this application?
>> > How many users do you plan to serve with this application?
>> > What is the nature of their use (continuous use for business day,
>> > occasional
>> > light use, occasional heavy use, receiving a stream of information)?
>> >
>> > In addition, you didn't provide the key constraints that drives the
>> > architecture.
>> > Do you have high uptime requirements (99.9% or better)?
>> > Do you have variable scalability issues (sudden spikes that increase
>> > traffic
>> > by an order of magnitude or more for a sustained period)?
>> > Do you need to be able to modify the behavior of the system while it is
>> > running due to the nature of competition in your business?
>> > Do you have existing systems that you need to communicate with? If so,
>> > are
>> > these systems designed for real-time communication or do you need to
> batch
>> > things up?
>> >
>> > Without at least a little of this information, my answer would be too
>> > vague
>> > to be useful.
>> >
>> > As for .NET remoting, it is a useful mechanism for designs that need to
>> > partition the execution of the application onto multiple servers. The
>> > marshalling is far more efficient than with web services, but it is
> still
>> > marshalling... and if you are sending data sets across a marshalling
>> > boundary, you are probably not designing your interfaces correctly.
>> >
>> > An excellent book: Advanced .NET Remoting by Ingo Rammer.
>> >
>> > HTH,
>> > ---- Nick
>> >
>> > "Param R." <(E-Mail Removed)> wrote in message
>> > news:%(E-Mail Removed)...
>> >> Hi all, we are in the process of architecting a new application that
> will
>> >> have an asp.net front end & sql back end. In the past we have used
>> >> webservices as a middle tier solution but in terms of performance it
> has
>> > not
>> >> been upto the mark. Besides with the latest .net version there are
>> >> some
>> >> known issues with calling web services (keepalives etc.). What other
>> > middle
>> >> tier solution does .net have to offer? What is .net remoting and how
> does
>> > it
>> >> work? Is it similar to DCOM? Does it have to run under IIS? I would
> like
>> >> something that is not dependent on IIS preferably. In our solution we
>> >> will
>> >> be passing custom objects back and forth with the middle tier
> interacting
>> >> with the database.
>> >>
>> >> Any help and guidance here is much appreciated!
>> >>
>> >> thanks!
>> >>
>> >>
>> >
>> >
>>
>>
>
>