cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Goffinet (Created) (JIRA)" <j...@apache.org>
Subject [jira] [Created] (CASSANDRA-3518) Back pressure users by request/s instead of concurrent reads/writes
Date Tue, 22 Nov 2011 06:22:40 GMT
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

        

Mime
View raw message