cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Goffinet (Commented) (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-3518) Back pressure users by request/s instead of concurrent reads/writes
Date Tue, 22 Nov 2011 07:08:39 GMT


Chris Goffinet commented on CASSANDRA-3518:


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:
>             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:!default.jspa
For more information on JIRA, see:


View raw message