Hey Chris,
A couple ideas about how to help us help you help us get better load
balancing.
If it were possible to define different classes of instances to target,
perhaps we could use a request header?
Either an X-AE-Expected-Latency or X-AE-Instance-Class;
The former to let an auto-balancer know that if it's a small or large
request so it can send small requests to fresher instances,
the latter would require the client to specify specific instance classes to
target.
This is similar to the way we target non-default versions of the app in
task queues.
In fact, it would be an ENORMOUS help to my load balancing if I could send
some requests to default frontend, and others to different versions.
Alas, ssl certificates do not allow me to request from
msg.appid.appspot.com without an ugly, unacceptable, "please click this and
confirm the security exception".
Allowing us to target different versions with a request header through the
main url would bypass this limitation, and allow us easy "large and small
request" distribution.
Anyway, if you guys decide to implement this,
out of gratitude, I will personally write the gwt generator patch to apply
@Instance(target="messaging") or @Latency(expected=2500) annotations to rpc
methods
and have the generator apply the headers for each method.
{as opposed to having RpcAsync methods return RequestBuilder instead of
void, and then manually applying the headers and hitting .call()}
Perhaps a whole Rpc interface could target a specific instance as well,
with per-method overrides....
In regard to having multiple apps share data, I would think a reserved id
namespace {something not currently allowed} would be the easiest.
Link the apps in the admin console, and when any of those apps interact
with the Entity.SHARED_NAMESPACE ns, it will be a common big table
namespace.
...Shouldn't be *too* hard.
Treat the shared ds like it's own app, with it's own appid, and use the
SHARED_NAMESPACE to route to a different app-id.
Most of the client-library would never need to know it's a different appid.
Work a little magic in KeyFactory and DatastoreServiceImpl, and boom;
instance shared data.
...Would also make a great tool for migrating to HR. Just encode your
namespace as a parent key, copy over, demux in HR, win! ;-}
--
You received this message because you are subscribed to the Google Groups
"Google App Engine" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/google-appengine/-/AOYGg36Ex9UJ.
To post to this group, send email to google-appengine@googlegroups.com.
To unsubscribe from this group, send email to
google-appengine+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en.
