Re: middle tier recommendations

• Previous message: Param R.: "Re: middle tier recommendations"
• In reply to: Nick Malik: "Re: middle tier recommendations"
• Messages sorted by: [ date ] [ thread ]

Date: Sat, 27 Nov 2004 23:38:34 -0600

Another thought I was having is to write a middle tier database layer that
basically caches records in Datasets that periodically update the backend
DB. Basically write some sort of DB emulator all residing in memory. The
question is, is this worth it or not? Am I trying to re-invent the wheel and
does SQL already do cacheing for me?

For example, app requests record with id 566 from table1. My middle tier
checks to see if already in cache and if not retrieves from cache and stores
it. Now app updates record and my middle tier saves changes in memory and
only updates after "x" mins... The reason this would be useful is my
application basically has the user go through several data capture screens
which modify several records in tables. User may go back and forth between
screens until they click "finish & submit"...

thanks!

"Nick Malik" <nickmalik@hotmail.nospam.com> 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." <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!
>> >>
>> >>
>> >
>> >
>>
>>
>
>

• Previous message: Param R.: "Re: middle tier recommendations"
• In reply to: Nick Malik: "Re: middle tier recommendations"
• Messages sorted by: [ date ] [ thread ]