On Tue, Aug 3, 2010 at 1:18 PM, Eric Day <e...@oddments.org> wrote: > > 2. Jorge and I would suggest making the request chain longer when > > possible to simplify each part, while you would suggest collapsing > it > > to reduce the number of hops. > > I suggest only making it longer when it is necessary, don't require > components to span multiple layers. Having all services as modules > will will make it trivial to split layers as we need. I see splitting > things into a longer chain as a pre-optimization, and in some cases > not an optimization at all. For example, the overhead of splitting > out a proxy layer for something like rate limiting may not make > sense. The overhead of the proxy (two extra sockets, buffer copying, > ...) is fairly expensive compared to just having the check in the API > endpoint directly (consulting a shared data store for current limit > and increment current request type). >
It's a trade-off -- there is the overhead of extra sockets, copying, network bandwidth; but there is the benefit of the API endpoint having less code in it, less complexity, fewer variables in the same scope. If you need to fix a rate limiting bug and I need to fix an API endpoint bug, we can work on completely separate pieces of code. I think we're just seeing different sides of the trade-off as more important. Luckiy, I think you just said in #openstack that WSGI meets your needs, so this may be a moot point :) > In the .png, imagine the separate boxes inside the API Endpoint > box that represents the different steps, not as a single blob. :) > I understand your concern about keeping the layers separate, and I > completely agree we don't want any spaghetti code/arch coming out of > this. I think place where we don't align yet is how these layers talk > to each other. > > Thinking of the request as a state machine and a series of > transformations, I think we all agree that the states need to > Ah hah! That does help. Thanks. be well defined and each state can depend on external services > (like auth). Where I see our difference is how we go about the > transformations from one state to the next. I'm advocating we keep > this generic, and allow for in-process transformations, where the > multi-layer proxy example is forcing a HTTP proxy layer for each > transformation. > Hooray again for WSGI solving this problem :) In-process transformations that can become HTTP proxies as needed! > Once we get to load testing we should be able to get a good picture > on what we need to break out, if anything. We'll want to capture some > stats on out current production API traffic, see the limits of the > new system, and go from there. > Sounds good. > > Hope this helped and didn't muddy the waters, > > It did, thanks for helping break things down! I think we're about on > the same page now, I'm going to go look at how WSGI layers can stack > to see if that is a good fit. :) > Great :) Michael
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
