{"action":"created","issue":{"url":"https://api.github.com/repos/grpc/grpc-java/issues/502","labels_url":"https://api.github.com/repos/grpc/grpc-java/issues/502/labels{/name}","comments_url":"https://api.github.com/repos/grpc/grpc-java/issues/502/comments","events_url":"https://api.github.com/repos/grpc/grpc-java/issues/502/events","html_url":"https://github.com/grpc/grpc-java/issues/502","id":82641130,"number":502,"title":"Allow for batching writes to the framer","user":{"login":"louiscryan","id":9046588,"avatar_url":"https://avatars.githubusercontent.com/u/9046588?v=3","gravatar_id":"","url":"https://api.github.com/users/louiscryan","html_url":"https://github.com/louiscryan","followers_url":"https://api.github.com/users/louiscryan/followers","following_url":"https://api.github.com/users/louiscryan/following{/other_user}","gists_url":"https://api.github.com/users/louiscryan/gists{/gist_id}","starred_url":"https://api.github.com/users/louiscryan/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/louiscryan/subscriptions","organizations_url":"https://api.github.com/users/louiscryan/orgs","repos_url":"https://api.github.com/users/louiscryan/repos","events_url":"https://api.github.com/users/louiscryan/events{/privacy}","received_events_url":"https://api.github.com/users/louiscryan/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/grpc/grpc-java/labels/performance","name":"performance","color":"5319e7"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":5,"created_at":"2015-05-30T00:23:03Z","updated_at":"2015-06-01T21:58:50Z","closed_at":null,"body":"Need to allow applications to perform a sequence of writes that cause a single flush in the framer to improve throughput.\r\n\r\nThe typical example for this would be an application thats wants to write messages until isReady() is false and to do more writes when onReady() is called. Even if the application is not flow-control aware (i.e is not using isReady) it would still be useful to allow write batching for bursty streams\r\n\r\nOne simple option for doing this would be to delay the outbound framer flush while executing  onPayload/isReady callbacks though this would only help cases where sends are done inside these callbacks by the same thread. A more thorough API change is probably warranted.\r\n\r\nTo give some performance context the change described above allows the FlowControlledMessagesPerSecondBenchmark to go from ~700kqps to ~4Mqps on my box\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/grpc/grpc-java/issues/comments/107725433","html_url":"https://github.com/grpc/grpc-java/issues/502#issuecomment-107725433","issue_url":"https://api.github.com/repos/grpc/grpc-java/issues/502","id":107725433,"user":{"login":"ejona86","id":2811396,"avatar_url":"https://avatars.githubusercontent.com/u/2811396?v=3","gravatar_id":"","url":"https://api.github.com/users/ejona86","html_url":"https://github.com/ejona86","followers_url":"https://api.github.com/users/ejona86/followers","following_url":"https://api.github.com/users/ejona86/following{/other_user}","gists_url":"https://api.github.com/users/ejona86/gists{/gist_id}","starred_url":"https://api.github.com/users/ejona86/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ejona86/subscriptions","organizations_url":"https://api.github.com/users/ejona86/orgs","repos_url":"https://api.github.com/users/ejona86/repos","events_url":"https://api.github.com/users/ejona86/events{/privacy}","received_events_url":"https://api.github.com/users/ejona86/received_events","type":"User","site_admin":false},"created_at":"2015-06-01T21:58:50Z","updated_at":"2015-06-01T21:58:50Z","body":"I don't like `sendMessage(Collection messages)` and `sendMessage(Iterator messages)`. I agree using a Collection prevents any flow control feedback. Iterator turns message creation into a callback, which seems unnecessary and harder to use. It would also require having a different method on Call, and so would be a burden to interceptors.\r\n\r\n`boolean sendMessage(message, flush)` could work, although it is little different than having a `flush()` method that is required to be called, with the exception of the possibility of less synchronization. Since there would be many callers over time, seeing the true/false could easily be a readability issue (not knowing if it is flushing or not). Granted, not having the parameter could be a readability issue by omission (not noticing it isn't flushing), but people are pretty familiar with the need to flush on things like OutputStreams. I guess we could have `sendMessage(message)` always call `sendMessage(message, true)`, and so the second parameter is typically missing, explicit flushing unnecessary, and there would be few calls with the boolean argument. We could make an enum FLUSH/NO_FLUSH instead of boolean if we really wanted.\r\n\r\nI'm still favoring the inhibit, though, because it very simply separates the producer from the batcher, and it would allow batching at different levels (e.g., Call vs Channel)."}}