[
https://issues.apache.org/jira/browse/HBASE-11598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14081353#comment-14081353
]
Jonathan Hsieh edited comment on HBASE-11598 at 7/31/14 7:55 PM:
-----------------------------------------------------------------
Thanks matteo -- I want to make sure we are on the same page for expected
behavior from a user's point of view before I go into the guts of the code.
{quote}You have all the combinations in the implementation. (Exposed at the
moment you have only req/time and req-size, I was waiting for comments) {quote}
I think just doing r+w is a good start -- the question is my ind from a user
pov is how would the admin commands be for specifying r-only and w-only
throttles? Do the would we have to add yet more admin commands for
"types"/"whats" to the throttle command?
>From a user's point of view would it make sense to say throttle_table or
>throttle_namespace as opposed to throttle 'table' or throttle 'namespace'?
>(currently it would seem you would need throttle 'tableReads' and throttle
>'tableWrites' as as new types etc.. )
{quote}
What is "available capacity"? you send your request and when you have consumed
the quota you get an exception.
{quote}
I'm trying to extract expected behavior from a user's point of view. Let me
frame it in two scenarios.
1: Let's say you the rs can handled a total of 10MB/s of throughput (the
available capacity). User 'jon' is restricted to 1mb/s. This is not a
reservation of 1MB/s throughput for jon -- jon gets to use 1mb/s and then gets
an exception despite there being 9MB of capacity remaiing..
2: Let's say you the rs can handled a total of 10MB/s of throughput (the
available capacity). There are many users -- u001-u100 each restricted to
1mb/s. This is not a reservation for 1MB/s throughput for each user -- each
user would be fighting for a chunk of the 10MB/s capacity.
{quote}
What do you mean by global across the cluster? you mean something like 1 global
limit max 10/sec?
or you mean "Across the cluster" as in QuotaScope.CLUSTER? In the description I
said that you have stuff like throttleUser() and throttleTable() and the quota
will be per-machine. There will be a flag "QuotaScope" that will be used in the
future to specify the quota at "cluster level" instead of per machine. (A limit
of 100req/min means that each machine can execute 100req/min with a scope
per-machine).
{quote}
Sounds good. I didn't see quotaScope in the admin commands code so I'm
wondering how that would fit in from a users's point of view. Where would it
go wrt to the current ruby commands you are proposing to add?
was (Author: jmhsieh):
Thanks matteo -- I want to make sure we are on the same page for expected
behavior from a user's point of view before I go into the guts of the code.
{quote}You have all the combinations in the implementation. (Exposed at the
moment you have only req/time and req-size, I was waiting for comments) {quote}
I think just doing r+w is a good start -- the question is my ind from a user
pov is how would the admin commands be for specifying r-only and w-only
throttles? Do the would we have to add yet more admin commands for
"types"/"whats" to the throttle command?
>From a user's point of view would it make sense to say throttle_table or
>throttle_namespace as opposed to throttle 'table' or throttle 'namespace'?
>(currently it would seem you would need throttle 'tableReads' and throttle
>'tableWrites' as as new types etc.. )
{quote}
What is "available capacity"? you send your request and when you have consumed
the quota you get an exception.
{quote}
I'm trying to extract expected behavior from a user's point of view. Let me
frame it in two scenarios.
1: Let's say you the rs can handled a total of 10MB/s of throughput (the
available capacity). User 'jon' is restricted to 1mb/s. This is not a
reservation of 1MB/s throughput for jon -- jon gets to use 1mb/s and then gets
an exception despite there being 9MB of capacity remaiing..
2: Let's say you the rs can handled a total of 10MB/s of throughput (the
available capacity). There are many users -- u001-u100 each restricted to
1mb/s. This is not a reservation for 1MB/s throughput for each user -- each
user would be fighting for a chunk of the 10MB/s capacity.
{quote}
What do you mean by global across the cluster? you mean something like 1 global
limit max 10/sec?
or you mean "Across the cluster" as in QuotaScope.CLUSTER? In the description I
said that you have stuff like throttleUser() and throttleTable() and the quota
will be per-machine. There will be a flag "QuotaScope" that will be used in the
future to specify the quota at "cluster level" instead of per machine. (A limit
of 100req/min means that each machine can execute 100req/min with a scope
per-machine).
{quote}
Sounds good. I'd didn't see quotaScope in the admin commands code so I'm
wondering how that would fit in from a users's point of view. Where would it
go wrt to the current ruby commands you are proposing to add?
> Add simple rpc throttling
> -------------------------
>
> Key: HBASE-11598
> URL: https://issues.apache.org/jira/browse/HBASE-11598
> Project: HBase
> Issue Type: New Feature
> Reporter: Matteo Bertozzi
> Assignee: Matteo Bertozzi
> Priority: Minor
> Fix For: 1.0.0, 2.0.0
>
>
> Add a simple version of rpc throttling.
> (by simple I mean something that requires less changes as possible to the
> core)
> The idea is to add a hbase:quota table to store the user/table quota
> information.
> Add a couple of API on the client like throttleUser() and throttleTable()
> and on the server side before executing the request we check the quota, if
> not an exception is thrown.
> The quota will be per-machine. There will be a flag "QuotaScope" that will be
> used in the future to specify the quota at "cluster level" instead of per
> machine. (A limit of 100req/min means that each machine can execute
> 100req/min with a scope per-machine).
> This will be the first cut, simple solution that requires verify few changes
> to the core.
> Later on we can make the client aware of the ThrottlingException and deal
> with it in a smarter way.
> Also we need to change a bit the RPC code to be able to yield the operation
> if the quota will be
> available not to far in the future, and avoid going back to the client for
> "few seconds".
> REVIEW BOARD: https://reviews.apache.org/r/23981
--
This message was sent by Atlassian JIRA
(v6.2#6252)
