Use of Application Server

**Nick Malik** · Nov 22 '05, 12:57 PM

Re: Use of Application Server

Boy, you must have one heck of an application to be worried about this level
of scaling...

So, if you want to scale a desktop client environment...

First off, why a desktop client environment? That's the first point in
scaling and security... in a web environment, you can hide that db server
behind a secondary firewall. With a client/server environment, you have a
db server out in the open, ready to be attacked... Web servers tend to have
more efficient interfaces... not always, but usually.

Now, assuming a desktop environment...
Sure, you can use remoting to access the application server, but you won't
see an improvement in *performance* until you scale quite a bit. A single
managed code component can not handle more concurrent connections than the
finely tuned communication layer that SQL Server uses. To see a performance
increase on an app server, you have to have three or four of them (my
guess), and you'd have to be using them in some way where they can minimize
the hits on SQL (like with caching, or async updates). No, App servers are
not normally something you do for performance. At least, not one at a time.

So, what if you do want to improve performance? For queries, you still have
to use synchronous messages, but for updates and inserts, I'd suggest async
messages, sent over HTTP, to a load-balanced array of machines using SOAP
web services. As connectionless and as stateless as you can possibly get
away with.

Does that help?
--- Nick

"Varkey" <varkeymathew@y ahoo.com> wrote in message
news:ea42eda5.0 407230016.4c1cf 96c@posting.goo gle.com...[color=blue]
> Dear friends,
>
> I am new to .NET based app development and have a pretty elementary
> query, I suppose... I have caught up with the basics of .NET pretty
> well, thanks to some Microsoft VB/ASP background and helpful
> colleagues...
> The query goes...
>
> In a DOTNET based desktop application environment, does it make sense
> to have each copy of the installed application from the different
> machines talk directly to the SQL Server Database. Or do you suggest
> the use of an Application Server??? Logically, there has to be some
> threshold after which SQL Server cannot takeup the load and the
> multiple number of connections.. So connection pooling and etc etc...
> features of App Server got to be useful, I suppose..
>
> Now coming to the most baffling part of the question. Extending the
> logic that an App Server might be needed( I had read somewhere that
> COM+ Services can act as App Server.. That is great!!!), where is this
> to be hosted?? If this is going to be a seperate server, then how are
> the different client machines to talk to the database? They will have
> to create objects of the classes and invoke methods in the App
> Server!!!! Now how is this to be done, as we are talking about
> different machines..... Is it what they use Remoting for??? If yes,
> how performance efficient is it for a realtime application with say
> 100-200 users? If no, then what is the ALTERNATIVE????
>
> Hoping to get a convincing response fro . IT would be fine if you can
> guide me to some good material to quench my curiosity..
>
>
> Thanks and regards,
>
> :)[/color]

**Varkey** · Nov 22 '05, 12:58 PM

Re: Use of Application Server

Dear Nick,

Thanks a lot for your response... It certainly has helped with a lot
of my queries.. If I read you right, you are suggesting that in such a
scenario, an APP Server need not be used and if at all scalability is
a concern, there should be multiple App Servers to cater to the
requirement.... Correct me if I am wrong...

Also can I take the liberty of going one step further and ask, "What
do you think is the scenario where an App Server is needed??"

To answer the query you had put up... Well, a desktop application is
preferred as the targetted users are more comfortable using a desktop
based application(got to do a lot with the predecessor of the
application) with a rich GUI...

The application will only be run in a LAN environment with AD based
security, and so I reckon the Security bit should not be a major
concern... Ofcourse, feel free to correct me if you feel so...

Thanks once again for the response.

Regards,

:)

"Nick Malik" <nickmalik@hotm ail.nospam.com> wrote in message news:<2R4Mc.148 488$IQ4.38512@a ttbi_s02>...[color=blue]
> Boy, you must have one heck of an application to be worried about this level
> of scaling...
>
> So, if you want to scale a desktop client environment...
>
> First off, why a desktop client environment? That's the first point in
> scaling and security... in a web environment, you can hide that db server
> behind a secondary firewall. With a client/server environment, you have a
> db server out in the open, ready to be attacked... Web servers tend to have
> more efficient interfaces... not always, but usually.
>
> Now, assuming a desktop environment...
> Sure, you can use remoting to access the application server, but you won't
> see an improvement in *performance* until you scale quite a bit. A single
> managed code component can not handle more concurrent connections than the
> finely tuned communication layer that SQL Server uses. To see a performance
> increase on an app server, you have to have three or four of them (my
> guess), and you'd have to be using them in some way where they can minimize
> the hits on SQL (like with caching, or async updates). No, App servers are
> not normally something you do for performance. At least, not one at a time.
>
> So, what if you do want to improve performance? For queries, you still have
> to use synchronous messages, but for updates and inserts, I'd suggest async
> messages, sent over HTTP, to a load-balanced array of machines using SOAP
> web services. As connectionless and as stateless as you can possibly get
> away with.
>
> Does that help?
> --- Nick
>
> "Varkey" <varkeymathew@y ahoo.com> wrote in message
> news:ea42eda5.0 407230016.4c1cf 96c@posting.goo gle.com...[color=green]
> > Dear friends,
> >
> > I am new to .NET based app development and have a pretty elementary
> > query, I suppose... I have caught up with the basics of .NET pretty
> > well, thanks to some Microsoft VB/ASP background and helpful
> > colleagues...
> > The query goes...
> >
> > In a DOTNET based desktop application environment, does it make sense
> > to have each copy of the installed application from the different
> > machines talk directly to the SQL Server Database. Or do you suggest
> > the use of an Application Server??? Logically, there has to be some
> > threshold after which SQL Server cannot takeup the load and the
> > multiple number of connections.. So connection pooling and etc etc...
> > features of App Server got to be useful, I suppose..
> >
> > Now coming to the most baffling part of the question. Extending the
> > logic that an App Server might be needed( I had read somewhere that
> > COM+ Services can act as App Server.. That is great!!!), where is this
> > to be hosted?? If this is going to be a seperate server, then how are
> > the different client machines to talk to the database? They will have
> > to create objects of the classes and invoke methods in the App
> > Server!!!! Now how is this to be done, as we are talking about
> > different machines..... Is it what they use Remoting for??? If yes,
> > how performance efficient is it for a realtime application with say
> > 100-200 users? If no, then what is the ALTERNATIVE????
> >
> > Hoping to get a convincing response fro . IT would be fine if you can
> > guide me to some good material to quench my curiosity..
> >
> >
> > Thanks and regards,
> >
> > :)[/color][/color]

**Varkey** · Nov 22 '05, 12:58 PM

Re: Use of Application Server

An additional Query on this topic

I had been going through a few websites.... and came across this
one...

http://www.eggheadcafe.com/articles/20021025.asp

Does this also state that it is not worthwhile to have an App Server
for an application like the one I have discussed below, but let the
office clients talk directly to the database....

Thanks and regards,

Varkey

"Nick Malik" <nickmalik@hotm ail.nospam.com> wrote in message news:<2R4Mc.148 488$IQ4.38512@a ttbi_s02>...[color=blue]
> Boy, you must have one heck of an application to be worried about this level
> of scaling...
>
> So, if you want to scale a desktop client environment...
>
> First off, why a desktop client environment? That's the first point in
> scaling and security... in a web environment, you can hide that db server
> behind a secondary firewall. With a client/server environment, you have a
> db server out in the open, ready to be attacked... Web servers tend to have
> more efficient interfaces... not always, but usually.
>
> Now, assuming a desktop environment...
> Sure, you can use remoting to access the application server, but you won't
> see an improvement in *performance* until you scale quite a bit. A single
> managed code component can not handle more concurrent connections than the
> finely tuned communication layer that SQL Server uses. To see a performance
> increase on an app server, you have to have three or four of them (my
> guess), and you'd have to be using them in some way where they can minimize
> the hits on SQL (like with caching, or async updates). No, App servers are
> not normally something you do for performance. At least, not one at a time.
>
> So, what if you do want to improve performance? For queries, you still have
> to use synchronous messages, but for updates and inserts, I'd suggest async
> messages, sent over HTTP, to a load-balanced array of machines using SOAP
> web services. As connectionless and as stateless as you can possibly get
> away with.
>
> Does that help?
> --- Nick
>
> "Varkey" <varkeymathew@y ahoo.com> wrote in message
> news:ea42eda5.0 407230016.4c1cf 96c@posting.goo gle.com...[color=green]
> > Dear friends,
> >
> > I am new to .NET based app development and have a pretty elementary
> > query, I suppose... I have caught up with the basics of .NET pretty
> > well, thanks to some Microsoft VB/ASP background and helpful
> > colleagues...
> > The query goes...
> >
> > In a DOTNET based desktop application environment, does it make sense
> > to have each copy of the installed application from the different
> > machines talk directly to the SQL Server Database. Or do you suggest
> > the use of an Application Server??? Logically, there has to be some
> > threshold after which SQL Server cannot takeup the load and the
> > multiple number of connections.. So connection pooling and etc etc...
> > features of App Server got to be useful, I suppose..
> >
> > Now coming to the most baffling part of the question. Extending the
> > logic that an App Server might be needed( I had read somewhere that
> > COM+ Services can act as App Server.. That is great!!!), where is this
> > to be hosted?? If this is going to be a seperate server, then how are
> > the different client machines to talk to the database? They will have
> > to create objects of the classes and invoke methods in the App
> > Server!!!! Now how is this to be done, as we are talking about
> > different machines..... Is it what they use Remoting for??? If yes,
> > how performance efficient is it for a realtime application with say
> > 100-200 users? If no, then what is the ALTERNATIVE????
> >
> > Hoping to get a convincing response fro . IT would be fine if you can
> > guide me to some good material to quench my curiosity..
> >
> >
> > Thanks and regards,
> >
> > :)[/color][/color]

Use of Application Server

Use of Application Server

Comment

Comment

Comment