problema de rendimiento del programador de simultaneidad golang + redis

En un nivel superficial, lo único sobre lo que tengo preguntas es sobre el orden de incrementar el grupo de espera y encolar el trabajo:

func (s *Scheduler) Enqueue(req interface{}) {
    select {
    case s.reqChan <- req:
        s.wg.Add(1)
    }
}

No creo que lo anterior cause muchos problemas en la práctica con esta gran carga de trabajo, pero creo que puede ser una condición lógica de carrera. En niveles más bajos de simultaneidad y tamaños de trabajo más pequeños, puede poner en cola un mensaje, luego cambiar a una rutina que comienza a trabajar en ese mensaje, LUEGO el trabajo en el grupo de espera.

A continuación, ¿está seguro de process? ¿el método es seguro para subprocesos? Supongo que, según la documentación de redis go, se ejecuta con go run -race ¿Tiene alguna salida?

En algún momento, es completamente razonable y se espera que el rendimiento disminuya. Recomendaría iniciar pruebas de rendimiento para ver dónde comienzan a disminuir la latencia y el rendimiento:

tal vez un grupo de 10, 100, 500, 1000, 2500, 5000, 10000, o lo que tenga sentido. En mi opinión, parece que hay 3 variables importantes para ajustar:

• Tamaño del grupo de trabajadores
• Tamaño del búfer de cola de trabajo
• Redis MaxActive

Lo más importante que salta a la vista es que parece que redis.Pool está configurado para permitir un número ilimitado de conexiones:

 pool := &redis.Pool{
        MaxIdle:     50,
        IdleTimeout: 240 * time.Second,
        TestOnBorrow: func(c redis.Conn, t time.Time) error {
            _, err := c.Do("PING")
            return err
        },
        Dial: func() (redis.Conn, error) {
            return dial("tcp", address, password)
        },
    }