{"action":"created","issue":{"url":"https://api.github.com/repos/rabbitmq/rabbitmq-server/issues/56","labels_url":"https://api.github.com/repos/rabbitmq/rabbitmq-server/issues/56/labels{/name}","comments_url":"https://api.github.com/repos/rabbitmq/rabbitmq-server/issues/56/comments","events_url":"https://api.github.com/repos/rabbitmq/rabbitmq-server/issues/56/events","html_url":"https://github.com/rabbitmq/rabbitmq-server/issues/56","id":59077357,"number":56,"title":"Provide way to tune/adjust/manipulate flow control triggers","user":{"login":"geekpete","id":2070843,"avatar_url":"https://avatars.githubusercontent.com/u/2070843?v=3","gravatar_id":"","url":"https://api.github.com/users/geekpete","html_url":"https://github.com/geekpete","followers_url":"https://api.github.com/users/geekpete/followers","following_url":"https://api.github.com/users/geekpete/following{/other_user}","gists_url":"https://api.github.com/users/geekpete/gists{/gist_id}","starred_url":"https://api.github.com/users/geekpete/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/geekpete/subscriptions","organizations_url":"https://api.github.com/users/geekpete/orgs","repos_url":"https://api.github.com/users/geekpete/repos","events_url":"https://api.github.com/users/geekpete/events{/privacy}","received_events_url":"https://api.github.com/users/geekpete/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":1,"created_at":"2015-02-26T14:09:04Z","updated_at":"2015-02-26T14:24:53Z","closed_at":null,"body":"We have seen flow control kick in when the server itself is under no real stress. It has much more resources available yet rabbitmq has throttled the publish rate.\r\n\r\nThe workload pattern we're servicing is when generating a large (tens of millions of messages) backlog in a large somewhat prolonged burst to then be processed slowly over time, but first having the messages queued quickly and reliably.\r\n\r\nWe want the ability to do this at a decent flow rate in order to queue the workload then consume over time as it is processed. Our servers can easily take a larger backlog at full speed, but rabbit will throttle the incoming publish rate down with flow control.\r\n\r\nIt would be good to have better ways to control this behaviour to either delay/extend the time or queue sizes before this flow control kicks in, or have it flow control slowly/incrementally or in an extreme case, disable flow control all together and rely only on the high watermark to prevent server death and protect stability.\r\n\r\nOur testing is showing flow control is triggering when there is no serious load on any of memory, cpu, disk IO at the time.\r\n\r\nWhat are some thoughts around this?\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/rabbitmq/rabbitmq-server/issues/comments/76186049","html_url":"https://github.com/rabbitmq/rabbitmq-server/issues/56#issuecomment-76186049","issue_url":"https://api.github.com/repos/rabbitmq/rabbitmq-server/issues/56","id":76186049,"user":{"login":"michaelklishin","id":1090,"avatar_url":"https://avatars.githubusercontent.com/u/1090?v=3","gravatar_id":"","url":"https://api.github.com/users/michaelklishin","html_url":"https://github.com/michaelklishin","followers_url":"https://api.github.com/users/michaelklishin/followers","following_url":"https://api.github.com/users/michaelklishin/following{/other_user}","gists_url":"https://api.github.com/users/michaelklishin/gists{/gist_id}","starred_url":"https://api.github.com/users/michaelklishin/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/michaelklishin/subscriptions","organizations_url":"https://api.github.com/users/michaelklishin/orgs","repos_url":"https://api.github.com/users/michaelklishin/repos","events_url":"https://api.github.com/users/michaelklishin/events{/privacy}","received_events_url":"https://api.github.com/users/michaelklishin/received_events","type":"User","site_admin":false},"created_at":"2015-02-26T14:24:53Z","updated_at":"2015-02-26T14:24:53Z","body":"Thank you for providing background on this.\n\nCertain things related to flow control can be made tunable. These will be advanced options but I see the need for this for some users.\n\nWe'll discuss what can be made tunable  and whether disabling flow control entirely is a feature we'd feel comfortable shipping, even as an option.\n\n> On 26/2/2015, at 17:09, Peter Dyson <notifications@github.com> wrote:\n> \n> We have seen flow control kick in when the server itself is under no real stress. It has much more resources available yet rabbitmq has throttled the publish rate.\n> \n> The workload pattern we're servicing is when generating a large (tens of millions of messages) backlog in a large somewhat prolonged burst to then be processed slowly over time, but while having the work queued quickly and reliably.\n> \n> We want the ability to do this at a decent flow rate in order to process the backlog over time as it gets through it. Our servers can easily take a larger backlog at full speed, but rabbit will throttle the incoming publish rate down with flow control.\n> \n> It would be good to have better ways to control this behaviour to either delay/extend the time or queue sizes before this flow control kicks in, or have it flow control slowly/incrementally or in an extreme case, disable flow control all together and rely only on the high watermark to prevent server death and protect stability.\n> \n> Our testing is showing flow control is triggering when there is no serious load on any of memory, cpu, disk IO at the time.\n> \n> What are some thoughts around this?\n> \n> —\n> Reply to this email directly or view it on GitHub.\n> \n"}}