Re: middle tier recommendations

From: Nick Malik (nickmalik_at_hotmail.nospam.com)
Date: 11/26/04 

Date: Fri, 26 Nov 2004 19:23:53 GMT

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." <pr@nospam.com> wrote in message
news:eI363t80EHA.2624@TK2MSFTNGP11.phx.gbl...
> 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" <nickmalik@hotmail.nospam.com> 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." <pr@nospam.com> wrote in message
> > news:%23kiwNQj0EHA.804@TK2MSFTNGP12.phx.gbl...
> >> 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!
> >>
> >>
> >
> >
>
>

Relevant Pages

  • Re: Homegrown synchronization
    ... to check for update files in the Import DropBox for the server. ... similar to the import code used to update a remote backend). ... code to close the "sync" app. ... synch app, but only one at a time would be able to do synchs. ...
    (microsoft.public.access.replication)
  • RE: Beginners Questions
    ... We do use Windows form on the presentation layer which is on ... terminal server and call web services on the business logic side. ... of using "proxy" authentication on SQL Server. ... > I have written an app with a Windows Forms UI that is deployed to clients ...
    (microsoft.public.dotnet.distributed_apps)
  • Re: Ruby Enterprise App Design Advice
    ... Load balanced to send user to best server. ... FastCGI or SCGI - We would like to replace FastCGI with something ... certain instance and want to have a single session server (if I understand ... deals with login and logout and assigns an app server. ...
    (comp.lang.ruby)
  • RE: C++ Garbage Collector on VMS?
    ... And HW is usually not a problem in th app tier. ... One for App server, one for DB. ... Tiers were a great concept when HW could not keep up with the processing required by each tier and network speeds were slow and unreliable. ... In small to medium app environments, ...
    (comp.os.vms)
  • Re: Schannel and Session Renegotiation
    ... Schannel does not support the server sending app ... We are discussing the option of providing support for the client blowing off ...
    (microsoft.public.platformsdk.security)
Loading