The change adding Min Pending Latency is pretty huge, actually. This is a 1.6 release in feature terms.
The 3 reserved instance idea was, obviously, which was less than ideal in terms of scalability. This is beautifully simple, yet enough to describe when exactly you want to scale up (most importantly, in user experience terms).
The scaling down, Max Idle Instances, just doesn't seem so cute to me, however. It strikes me as going back to the absolute measuring of the reserved instances. And the best setting probably varies by time of day.
The number I pick for Max Idle Instances depends on how traffic I get, the boundary case of this being -> I have no clue. It's kinda like being able to set the number of reserved instances, above that number, like previous above 3 instance, the scalability degrades.
Isn't the scale down just the opposite of the scale up with some Hysteresis? i.e. "Min Pending Latency High" and "Min Pending Latency Low". Add a bit of smoothing to calculating what the current low is (and smooth the high calculation if you're not already).
Translate to:
Scale Up if the user isn't getting a response fast enough. Scale Down if there's excess capacity and scaling down won't cause anyone to notice.
Google is still using cpu hours pricing model. How it will deal where user reserves maximum 100 instances for his application with the current pricing model.
Guys, very much anticipating that "upcoming article" to explain just what you mean by "removing the need for exploding indexes".
I'm currently developing an app and having to go through lots of hoops to provide a 5-way search filter.
I tried searching without including list properties in indexes and that didn't work, so I've added indexes with multiple list properties for now, but I know this won't work in production because it will explode over 5000 real quick.
Follow
The change adding Min Pending Latency is pretty huge, actually. This is a 1.6 release in feature terms.
ReplyDeleteThe 3 reserved instance idea was, obviously, which was less than ideal in terms of scalability. This is beautifully simple, yet enough to describe when exactly you want to scale up (most importantly, in user experience terms).
The scaling down, Max Idle Instances, just doesn't seem so cute to me, however. It strikes me as going back to the absolute measuring of the reserved instances. And the best setting probably varies by time of day.
The number I pick for Max Idle Instances depends on how traffic I get, the boundary case of this being -> I have no clue. It's kinda like being able to set the number of reserved instances, above that number, like previous above 3 instance, the scalability degrades.
Isn't the scale down just the opposite of the scale up with some Hysteresis? i.e. "Min Pending Latency High" and "Min Pending Latency Low". Add a bit of smoothing to calculating what the current low is (and smooth the high calculation if you're not already).
Translate to:
Scale Up if the user isn't getting a response fast enough.
Scale Down if there's excess capacity and scaling down won't cause anyone to notice.
Google is still using cpu hours pricing model. How it will deal where user reserves maximum 100 instances for his application with the current pricing model.
ReplyDeletegood !
ReplyDeletehttp://www.gocasa.ro
Guys, very much anticipating that "upcoming article" to explain just what you mean by "removing the need for exploding indexes".
ReplyDeleteI'm currently developing an app and having to go through lots of hoops to provide a 5-way search filter.
I tried searching without including list properties in indexes and that didn't work, so I've added indexes with multiple list properties for now, but I know this won't work in production because it will explode over 5000 real quick.