Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?

Comment on

( #3333=superdoc: print w/replies, xml ) Need Help??
Thanks for making me think about this some more. Let's summarize things a bit.

I think that adding one ore more RPC calls to each request will add significant overhead. You think it will get lost in the noise. We probably won't agree on that, and I only have anecdotal evidence to prove my point, so agree to disagree.

I think that forcing the communication between the presentation logic, domain objects, and database layer to be done with coarse-grained calls is a problem. You don't think it matters. Fowler talks about this in his recent book, and that chapter is mostly republished in this article (which requires a free registration). Here's a relevant excerpt:

A local interface is best as a fine-grained interface. Thus, if I have an address class, a good interface will have separate methods for getting the city, getting the state, setting the city, setting the state and so forth. A fine-grained interface is good because it follows the general OO principle of lots of little pieces that can be combined and overridden in various ways to extend the design into the future.

A fine-grained interface doesnít work well when itís remote. When method calls are slow, you want to obtain or update the city, state and zip in one call rather than three. The resulting interface is coarse-grained, designed not for flexibility and extendibility but for minimizing calls. Here youíll see an interface along the lines of get-address details and update-address details. Itís much more awkward to program to, but for performance, you need to have it.

I would point out that with a fine-grained interface you could throw an error when someone passes in a bad zip code, while a coarse-grained one would necessitate gathering up all the errors from all the input, putting them in some kind of structure to pass back, and then making the client code go through the structure and respond to each issue. It just isn't as fluid. But we will probably not agree on this either. I do recognize that there are situations where everything can be summed up in a single call, but I don't think all communications between layers fit well into that.

Finally, you seem to see the primary value of a distributed architecture as the ability to isolate individual sections of the app. You are talking about fairly large sections, like entire pages, so I think this is separate from the original question of whether or not the presentation layer and application layer should be on the same machine. I agree that there are uses for this, but I still think they only apply when you are willing to let a certain section of your application perform badly as long as another section performs well. I don't see how your statement that "some parts will require resources beyond that of others" applies to this. Of course they will, and at that point you can either improve your overall capacity to handle it, or isolate the part that is performing badly and let it continue to perform badly while the rest of the application is fast.

I'll give an example of a use for this. Say you have an e-commerce site that has a feature to track a customer's packages. This involves a query to an external company's web site. It's slow, and there is nothing you can do about it since that resource is out of your control. Letting all of your servers handle requests for this could result in tying up many server processes while they wait for results and could lead to a general slowdown. You could either add resources to the whole site in order to offer the best performance possible for all requests, or you could isolate these package tracking requests on a few machines, making them incredibly slow but allowing the rest of the site (which is making you money) to stay fast. This could be a good compromise, depending on the economics of the situation.

Note that if you then go and add more machines to the slow package tracking cluster to fully handle the load, I would consider the isolation pointless. You could have simply left things all together and added those machines to the general cluster, with the exact same result.

I said this was easy to implement with mod_proxy, and it is, but you correctly pointed out that mod_proxy has significant overhead. There are some other benefits to the mod_proxy approach (caching, serving static files) but for just isolating a particular set of URLs to specific groups of machines you would probably be better off doing it with a hardware load-balancer.

In reply to Re: Re: Re: Re: Re: Re: "The First Rule of Distributed Objects is..." by perrin
in thread Multi tiered web applications in Perl by pernod

Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":

  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.
  • Log In?

    What's my password?
    Create A New User
    [erix]: sleighting, I imagine 'Schlechten' will be a german word too - probably with same meaning as in dutch (breaking down, making useless a castle / defensive structure )
    [erix]: oh... the german term is Schleifung

    How do I use this? | Other CB clients
    Other Users?
    Others perusing the Monastery: (5)
    As of 2017-05-29 15:39 GMT
    Find Nodes?
      Voting Booth?