Así que aquí está mi problema. Tengo la necesidad de generar esencialmente una instancia de Discourse en producción con alrededor de 200 publicaciones a la vez desde una acción de administrador de un plugin. Estas publicaciones serán ‘creadas por’ 1 de 10 usuarios regulares diferentes. La razón por la que es una acción de plugin es porque los usuarios de esta instancia en particular tienen un equipo de moderadores que quieren capacitar, y querían algunas publicaciones de prueba para entrenarlos, así como la capacidad de generar más cuando las necesiten.
Logré que esto funcionara correctamente pasando skip_validations: true a PostCreator.new, pero ahora hay un requisito de que algunas de las publicaciones creadas también sean reportadas.
Primero intenté desactivar el RateLimiter, pero eso hizo que mi acción eventualmente bloqueara el proceso del servidor, posiblemente cuando intentaba volver a activarlo, y luego me di cuenta de que probablemente no era una buena idea de todos modos.
Así que mi pregunta es: ¿hay una mejor manera de eludir el limitador de velocidad al ejecutar algún código arbitrario, es decir, algo como:
RateLimiter.bypass do
# ejecutar algún código no afectado por el limitador de velocidad
end
¿O necesito básicamente copiar la mayor parte de lo que hace PostActionCreator pero omitir la línea problemática?
¡Cualquier ayuda sería muy apreciada! Aún estoy absorbiendo gran parte del código de Discourse, así que soy consciente de que probablemente me haya perdido algo que haría esto mucho más fácil!
Esta no es realmente una ruta que quiera seguir, ya que prefiero que sea iniciada por los usuarios en lugar de depender de que yo ejecute un script en la consola.
¿Descubriste esto? Modificar el archivo yaml no es ideal ya que requiere una reconstrucción. No estoy lo suficientemente familiarizado con rails/discourse para descubrir cómo deshabilitarlo temporalmente en la consola.
Intentando importar 60 000 usuarios a través de la API lo más rápido posible sin reconstruir. También intenté en una instalación de prueba aumentar el límite de la API de ADMIN a través de YAML, pero no pareció funcionar, aunque quizás hice algo mal. (Estoy ejecutando importaciones en el contenedor, por lo que la limitación de HTTP no debería aplicarse).
Pero puedes entrar en el contenedor y editar /var/www/discourse/config/discourse.conf y establecer esas variables allí y luego hacer un sv restart unicorn (o quizás sv reload unicorn). Probablemente querrás hacer algo como apt-get update; apt-get install -y vim para tener un editor.
Extraño. Cuando veo el archivo de configuración, el nuevo límite ya está establecido. Así que la actualización de YAML funcionó:
max_admin_api_reqs_per_key_per_minute = '6000'
Pero no parece funcionar. Todavía hay una limitación de 60 por minuto. Cuando limito las solicitudes a 60 por minuto, la mayoría se procesa, pero debido a la fluctuación, algunas aún activan el limitador de velocidad:
{'success': True, 'active': True, 'message': 'Your account is activated and ready to use.', 'user_id': 3596}
{'success': False, 'message': ' New registrations are not allowed from your IP address (maximum limit reached). Contact a staff member.', 'errors': {'ip_address': ['New registrations are not allowed from your IP address (maximum limit reached). Contact a staff member.']}, 'values': {'name': None, 'username': 'asdfd', 'email': 'user@domain.com'}, 'is_developer': False}
{'success': True, 'active': True, 'message': 'Your account is activated and ready to use.', 'user_id': 3597}
Creo que está relacionado con otro límite: creo que es el límite de registros máximos desde una IP el que está alcanzando, pero no entiendo por qué después de alcanzarlo no se bloquea permanentemente. ¿Posiblemente un error en este límite de spam?
Si todos esos usuarios tienen la misma IP, entonces apuesto a que tienes razón. Creo que la solución es cambiar esa configuración o dar a la gente direcciones IP falsas como 127.0.0.x (¿o quizás usar IPv6 para que sea más fácil?).
Creo que está detectando desde dónde se realiza la solicitud (computadora host), pero puedo evitarlo agregando un usuario TL2 en la misma dirección IP (o ajustando el límite de IP).
Sí, lo intentaré. Pero no tengo claro cómo se supone que debo ejecutar el script, ¿dónde debo copiarlo y cómo lo ejecuto (una vez que ponga el CSV en los lugares correctos)?
Como seguimiento, dado el esfuerzo para comprender los scripts y Ruby, etc., y el rendimiento probable, tomé otra ruta y evité todos los límites escribiendo directamente en la base de datos usando SQL. De esta manera, pude obtener varios miles de inserciones por segundo.
Había un tema preguntando qué tablas se requerían, ahora está cerrado, así que respondo aquí que cambié las siguientes tablas para insertar los usuarios: