You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Chris Goffinet (Created) (JIRA)" <ji...@apache.org> on 2011/11/22 07:22:40 UTC
[jira] [Created] (CASSANDRA-3518) Back pressure users by request/s
instead of concurrent reads/writes
Back pressure users by request/s instead of concurrent reads/writes
-------------------------------------------------------------------
Key: CASSANDRA-3518
URL: https://issues.apache.org/jira/browse/CASSANDRA-3518
Project: Cassandra
Issue Type: Bug
Affects Versions: 1.0.2
Reporter: Chris Goffinet
We are running into use cases where it makes a lot of sense to have QoS at the request level per user. Imagine this case:
I have a cluster that can do 100,000 req/s. But I want to limit the user to only being able to do either 50,000 read or write/s per second in the cluster. I rather give back pressure to the user then make the cluster fall down because the user tried to take down my cluster.
Also another case we have is where you have experimental features and want to give access to certain group of customers and let them run experiments on data. You *dont* want them taking down the cluster, you rather make them fail fast, or slow them down. If I could limit a user to N req/s for reads or writes, instead of adding back pressure based on # of concurrent requests in each stage, this would go a long way for us.
We have had a few incidents where spinning up new features caused unexpected load and we couldn't stop them without turning the feature off.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3518) Back pressure users by
request/s instead of concurrent reads/writes
Posted by "Radim Kolar (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13154909#comment-13154909 ]
Radim Kolar commented on CASSANDRA-3518:
----------------------------------------
cassandra has request scheduler, look for _request_scheduler_ in config. You can even write yours.
> Back pressure users by request/s instead of concurrent reads/writes
> -------------------------------------------------------------------
>
> Key: CASSANDRA-3518
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3518
> Project: Cassandra
> Issue Type: Bug
> Affects Versions: 1.0.2
> Reporter: Chris Goffinet
>
> We are running into use cases where it makes a lot of sense to have QoS at the request level per user. Imagine this case:
> I have a cluster that can do 100,000 req/s. But I want to limit the user to only being able to do either 50,000 read or write/s per second in the cluster. I rather give back pressure to the user then make the cluster fall down because the user tried to take down my cluster.
> Also another case we have is where you have experimental features and want to give access to certain group of customers and let them run experiments on data. You *dont* want them taking down the cluster, you rather make them fail fast, or slow them down. If I could limit a user to N req/s for reads or writes, instead of adding back pressure based on # of concurrent requests in each stage, this would go a long way for us.
> We have had a few incidents where spinning up new features caused unexpected load and we couldn't stop them without turning the feature off.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-3518) Back pressure users
by request/s instead of concurrent reads/writes
Posted by "Chris Goffinet (Issue Comment Edited) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13154920#comment-13154920 ]
Chris Goffinet edited comment on CASSANDRA-3518 at 11/22/11 7:08 AM:
---------------------------------------------------------------------
Radim,
I know what the Request Scheduler is.. please read my ticket more carefully.
{noformat}
# Scheduler Options vary based on the type of scheduler
# NoScheduler - Has no options
# RoundRobin
# - throttle_limit -- The throttle_limit is the number of in-flight
# requests per client. Requests beyond
# that limit are queued up until
# running requests can complete.
# The value of 80 here is twice the number of
# concurrent_reads + concurrent_writes.
{noformat}
number of in-flight requests per client. I want to a) do this per user b) break it down so it's request/s not how many concurrent reads/writes in flight.
was (Author: lenn0x):
Radim,
I know what the Request Scheduler is.. please read my ticket more carefully.
# Scheduler Options vary based on the type of scheduler
# NoScheduler - Has no options
# RoundRobin
# - throttle_limit -- The throttle_limit is the number of in-flight
# requests per client. Requests beyond
# that limit are queued up until
# running requests can complete.
# The value of 80 here is twice the number of
# concurrent_reads + concurrent_writes.
number of in-flight requests per client. I want to a) do this per user b) break it down so it's request/s not how many concurrent reads/writes in flight.
> Back pressure users by request/s instead of concurrent reads/writes
> -------------------------------------------------------------------
>
> Key: CASSANDRA-3518
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3518
> Project: Cassandra
> Issue Type: Bug
> Affects Versions: 1.0.2
> Reporter: Chris Goffinet
>
> We are running into use cases where it makes a lot of sense to have QoS at the request level per user. Imagine this case:
> I have a cluster that can do 100,000 req/s. But I want to limit the user to only being able to do either 50,000 read or write/s per second in the cluster. I rather give back pressure to the user then make the cluster fall down because the user tried to take down my cluster.
> Also another case we have is where you have experimental features and want to give access to certain group of customers and let them run experiments on data. You *dont* want them taking down the cluster, you rather make them fail fast, or slow them down. If I could limit a user to N req/s for reads or writes, instead of adding back pressure based on # of concurrent requests in each stage, this would go a long way for us.
> We have had a few incidents where spinning up new features caused unexpected load and we couldn't stop them without turning the feature off.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3518) Back pressure users by
request/s instead of concurrent reads/writes
Posted by "Chris Goffinet (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13154920#comment-13154920 ]
Chris Goffinet commented on CASSANDRA-3518:
-------------------------------------------
Radim,
I know what the Request Scheduler is.. please read my ticket more carefully.
# Scheduler Options vary based on the type of scheduler
# NoScheduler - Has no options
# RoundRobin
# - throttle_limit -- The throttle_limit is the number of in-flight
# requests per client. Requests beyond
# that limit are queued up until
# running requests can complete.
# The value of 80 here is twice the number of
# concurrent_reads + concurrent_writes.
number of in-flight requests per client. I want to a) do this per user b) break it down so it's request/s not how many concurrent reads/writes in flight.
> Back pressure users by request/s instead of concurrent reads/writes
> -------------------------------------------------------------------
>
> Key: CASSANDRA-3518
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3518
> Project: Cassandra
> Issue Type: Bug
> Affects Versions: 1.0.2
> Reporter: Chris Goffinet
>
> We are running into use cases where it makes a lot of sense to have QoS at the request level per user. Imagine this case:
> I have a cluster that can do 100,000 req/s. But I want to limit the user to only being able to do either 50,000 read or write/s per second in the cluster. I rather give back pressure to the user then make the cluster fall down because the user tried to take down my cluster.
> Also another case we have is where you have experimental features and want to give access to certain group of customers and let them run experiments on data. You *dont* want them taking down the cluster, you rather make them fail fast, or slow them down. If I could limit a user to N req/s for reads or writes, instead of adding back pressure based on # of concurrent requests in each stage, this would go a long way for us.
> We have had a few incidents where spinning up new features caused unexpected load and we couldn't stop them without turning the feature off.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira