Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / .NET Framework / Performance / January 2005

Tip: Looking for answers? Try searching our database.

three physical layers performance issue

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Oscar Nieto - 05 Jan 2005 19:51 GMT
Hey folks! I need some light with this...

I have a big three layer application with a Web interface... once it was
built the webforms where using the dlls of the bussines logic in the same
server (bin directory of the virtual folder on IIS). However, a few weeks ago
we needed to separate them in to a diferent server to demostrate that it is
possible to get a three physical layer model. We used com+ instead of a web
service approach because of performance and our desire of rebuild at least as
possible, but even using this stuff the respose time of our application
decreased more than we expected... The problem could be anything, but I've
heard that it is not recommended to separate the physical layers in dotnet
cause performance decreases... i dont know if this is true and im a little
lost in this matter, so if any of you could give a clue to read an understand
better this issue i would be really greatfull.

Thanks and good luck!
Joerg Jooss - 05 Jan 2005 22:29 GMT
> Hey folks! I need some light with this...
>
[quoted text clipped - 4 lines]
> server to demostrate that it is possible to get a three physical
> layer model.

To *demonstrate*? What ever happened to business value ;-)

> We used com+ instead of a web service approach because
> of performance and our desire of rebuild at least as possible, but
[quoted text clipped - 4 lines]
> im a little lost in this matter, so if any of you could give a clue
> to read an understand better this issue i would be really greatfull.

It's true that in most cases collocated components perform way better
than distributed components. That's true for J2EE, and .NET isn't any
differrent. Remember Fowler's 1st Law of Distribution: *Don't*. It's
quite possible that you're flogging a dead horse =:-O

Cheers,
Signature

http://www.joergjooss.de
mailto:news-reply@joergjooss.de

Oscar Nieto - 06 Jan 2005 19:25 GMT
Thanks Joerg, i know it sounds stupid, but my problem is actually a little
stupid... look:

We built the application for an organization that has no confidence in the
layered model and no matter what we say they dont trust our new application,
and have made as they can to break it. One day they decided that the only way
they could approve our programming of the layered model was to separate the
logical layers into physical layers, using diferent servers of course... they
made us distribute the components into diferent machines and some load
balancers in the middle, the app worked fine but of course the performance
was affected, they claim that the performance should be the same and we are
not such experts to say "thats impossible". So I am looking for some paper or
text that help me prove the performance is affected because of bla bla bla...
and we souldnt expect response times lower than bla bla bla... I do know that
the simple separation into different machines includes delays like the
network, the load balancer, and technologies involved etc etc... but i need
to prove it whit some expert opinion, or at least build a document including
different opinions an experiences that help me make a point... Im not a
expert and im not completely sure where to look or who should i ask.

Thanks for your help.

> > Hey folks! I need some light with this...
> >
[quoted text clipped - 22 lines]
>
> Cheers,
Joerg Jooss - 07 Jan 2005 07:16 GMT
> Thanks Joerg, i know it sounds stupid, but my problem is actually a
> little stupid... look:
>
> We built the application for an organization that has no confidence
> in the layered model and no matter what we say they dont trust our
> new application, and have made as they can to break it.

OK, that is quite weird :-(

> One day they
> decided that the only way they could approve our programming of the
> layered model was to separate the logical layers into physical
> layers, using diferent servers of course...

That's utter nonsense. Layering is a proven design technique since, um,
way before I ever touched a keyboard. If they want to review your
architecture, give 'em your source code and design documents ;-)

Distributing layers on *tiers* (what you called physical layers) is a
significant architectural decision. There's no such things as
transparent distributed objects -- parameter passing semantics may
change, the network introduces a single point of failure, the network
introduces latency, you may need distributed garbage collection, ...
all this needs to be taken into account.

> they made us distribute
> the components into diferent machines and some load balancers in the
> middle, the app worked fine but of course the performance was
> affected, they claim that the performance should be the same

Why? It's insane to assume there's a zero-latency, fail-safe network in
between. Even if there was, the effort to serialize and deserialize
objects to and from the network is significant, a process that is
magnitudes slower than a normal (i.e. local) method call. It is no
surprise that distributed object technologies like Remote EJBs are
fallen from grace. Scalability and performance are not the same thing.

> and we
> are not such experts to say "thats impossible". So I am looking for
> some paper or text that help me prove the performance is affected
> because of bla bla bla...  and we souldnt expect response times lower
> than bla bla bla...

Get Martin Fowler's "Patterns of Enterprise Application Architecture"
(Addison-Wesley).

> I do know that the simple separation into
> different machines includes delays like the network, the load
> balancer, and technologies involved etc etc... but i need to prove it
> whit some expert opinion, or at least build a document including
> different opinions an experiences that help me make a point... Im not
> a expert and im not completely sure where to look or who should i ask.

The question is whether this weird client will ever believe you. Maybe
some external consultant can provide some sanity.

Cheers,
Signature

http://www.joergjooss.de
mailto:news-reply@joergjooss.de

Jim Brandley - 18 Jan 2005 01:02 GMT
In our experience Com+ was the big hitter. I would do about anything to keep
it out of DotNet applications.

> Hey folks! I need some light with this...
>
[quoted text clipped - 12 lines]
>
> Thanks and good luck!
Alvin Bruney [MVP] - 18 Jan 2005 14:12 GMT
The problem could be anything, but I've
>> heard that it is not recommended to separate the physical layers in
>> dotnet
>> cause performance decreases...

No, that is not true in my experience. .NET is especially built for tiering.
You need to find where the performance bottle neck is by using tracing.

Signature

Regards,
Alvin Bruney
[ASP.NET MVP http://mvp.support.microsoft.com/default.aspx]
Got tidbits? Get it here... http://tinyurl.com/27cok

> In our experience Com+ was the big hitter. I would do about anything to
> keep
[quoted text clipped - 25 lines]
>>
>> Thanks and good luck!

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.