No throughput difference between sync and async producers
Hi,
I thought the throughput would be better for async operations but for the given configurations, there is barely any difference at all between sync (30932 requests) and async (31274 requests) producers. Testing with 99 virtual users sending concurrent requests for 10 seconds to both endpoints. Topic has 3 partitions on a single broker.
Am I using producers wrong or, is it a configuration issue, or is there a bug in the library?
Thanks
| Sarama | Kafka | Go |
|---|---|---|
| v1.43.2 | v3.3.2 | 1.22 |
package main
import (
"log"
"net/http"
"github.com/IBM/sarama"
)
func main() {
apro, err := Async()
if err != nil {
log.Fatalln(err)
}
defer apro.AsyncClose()
spro, err := Sync()
if err != nil {
log.Fatalln(err)
}
defer spro.Close()
hnd := Handler{
AyncProducer: apro,
SyncProducer: spro,
}
rtr := http.DefaultServeMux
rtr.HandleFunc("GET /async", hnd.Async)
rtr.HandleFunc("GET /sync", hnd.Sync)
http.ListenAndServe(":8080", rtr)
}
func Async() (sarama.AsyncProducer, error) {
cfg := sarama.NewConfig()
cfg.ClientID = "test-client"
cfg.Version = sarama.V3_3_2_0
cfg.Metadata.AllowAutoTopicCreation = false
cfg.Producer.Return.Successes = true
cfg.Producer.Return.Errors = true
cfg.Producer.Retry.Max = 30
cfg.Producer.Retry.Backoff = time.Millisecond * 10
cfg.Producer.Compression = sarama.CompressionZSTD
cfg.Producer.RequiredAcks = sarama.WaitForAll
cfg.Net.MaxOpenRequests = 1
return sarama.NewAsyncProducer([]string{":9093"}, cfg)
}
func Sync() (sarama.SyncProducer, error) {
cfg := sarama.NewConfig()
cfg.ClientID = "test-client"
cfg.Version = sarama.V3_3_2_0
cfg.Metadata.AllowAutoTopicCreation = false
cfg.Producer.Return.Successes = true
cfg.Producer.Retry.Max = 30
cfg.Producer.Retry.Backoff = time.Millisecond * 10
cfg.Producer.Compression = sarama.CompressionZSTD
cfg.Producer.Idempotent = true
cfg.Producer.RequiredAcks = sarama.WaitForAll
cfg.Net.MaxOpenRequests = 1
return sarama.NewSyncProducer([]string{":9093"}, cfg)
}
type Handler struct {
SyncProducer sarama.SyncProducer
AyncProducer sarama.AsyncProducer
}
// GET /async
func (e Handler) Async(w http.ResponseWriter, r *http.Request) {
msg := sarama.ProducerMessage{Topic: "errors", Value: sarama.StringEncoder("hi")}
e.AyncProducer.Input() <- &msg
select {
case <-e.AyncProducer.Successes():
case <-e.AyncProducer.Errors():
}
}
// GET /sync
func (e Handler) Sync(w http.ResponseWriter, r *http.Request) {
msg := sarama.ProducerMessage{Topic: "errors", Value: sarama.StringEncoder("hi")}
_, _, _ = e.SyncProducer.SendMessage(&msg)
}
SYNC
running (10.0s), 00/99 VUs, 30932 complete and 0 interrupted iterations
default ✓ [======================================] 99 VUs 10s
✓ 200 OK
✗ response < 100 ms
↳ 99% — ✓ 30884 / ✗ 48
checks.........................: 99.92% ✓ 61816 ✗ 48
data_received..................: 2.3 MB 232 kB/s
data_sent......................: 2.7 MB 271 kB/s
http_req_blocked...............: avg=13.6µs min=1µs med=3µs max=10.12ms p(90)=5µs p(95)=7µs
http_req_connecting............: avg=6.95µs min=0s med=0s max=7.32ms p(90)=0s p(95)=0s
http_req_duration..............: avg=31.79ms min=5.96ms med=29.78ms max=116.49ms p(90)=44.98ms p(95)=51.59ms
{ expected_response:true }...: avg=31.79ms min=5.96ms med=29.78ms max=116.49ms p(90)=44.98ms p(95)=51.59ms
http_req_failed................: 0.00% ✓ 0 ✗ 30932
http_req_receiving.............: avg=57.05µs min=11µs med=22µs max=17.25ms p(90)=60µs p(95)=103µs
http_req_sending...............: avg=32.92µs min=5µs med=11µs max=38.6ms p(90)=26µs p(95)=42µs
http_req_tls_handshaking.......: avg=0s min=0s med=0s max=0s p(90)=0s p(95)=0s
http_req_waiting...............: avg=31.7ms min=5.92ms med=29.7ms max=116.46ms p(90)=44.82ms p(95)=51.46ms
http_reqs......................: 30932 3086.507218/s
iteration_duration.............: avg=32ms min=6.06ms med=29.95ms max=116.61ms p(90)=45.25ms p(95)=51.92ms
iterations.....................: 30932 3086.507218/s
vus............................: 99 min=99 max=99
vus_max........................: 99 min=99 max=99
ASYNC
running (10.0s), 00/99 VUs, 31274 complete and 0 interrupted iterations
default ✓ [======================================] 99 VUs 10s
✓ 200 OK
✗ response < 100 ms
↳ 99% — ✓ 31178 / ✗ 96
checks.........................: 99.84% ✓ 62452 ✗ 96
data_received..................: 2.3 MB 234 kB/s
data_sent......................: 2.7 MB 271 kB/s
http_req_blocked...............: avg=43.02µs min=1µs med=3µs max=249.78ms p(90)=5µs p(95)=8µs
http_req_connecting............: avg=35.48µs min=0s med=0s max=224.07ms p(90)=0s p(95)=0s
http_req_duration..............: avg=31.38ms min=10.48ms med=29.06ms max=141.05ms p(90)=43.09ms p(95)=50.2ms
{ expected_response:true }...: avg=31.38ms min=10.48ms med=29.06ms max=141.05ms p(90)=43.09ms p(95)=50.2ms
http_req_failed................: 0.00% ✓ 0 ✗ 31274
http_req_receiving.............: avg=65.87µs min=11µs med=23µs max=52.8ms p(90)=64µs p(95)=119µs
http_req_sending...............: avg=37.3µs min=5µs med=12µs max=63.66ms p(90)=28µs p(95)=47µs
http_req_tls_handshaking.......: avg=0s min=0s med=0s max=0s p(90)=0s p(95)=0s
http_req_waiting...............: avg=31.27ms min=10.45ms med=28.98ms max=141.01ms p(90)=42.96ms p(95)=50.06ms
http_reqs......................: 31274 3122.225847/s
iteration_duration.............: avg=31.62ms min=10.58ms med=29.24ms max=359.58ms p(90)=43.47ms p(95)=50.57ms
iterations.....................: 31274 3122.225847/s
vus............................: 99 min=99 max=99
vus_max........................: 99 min=99 max=99
Because this library uses async for sync under the hood! https://github.com/IBM/sarama/discussions/2912#discussioncomment-9555131
Thank you for taking the time to raise this issue. However, it has not had any activity on it in the past 90 days and will be closed in 30 days if no updates occur. Please check if the main branch has already resolved the issue since it was raised. If you believe the issue is still valid and you would like input from the maintainers then please comment to ask for it to be reviewed.