Então, eis o meu problema. Tenho a necessidade de, essencialmente, popular uma instância de produção do Discourse com cerca de 200 posts por vez, a partir de uma ação administrativa de um plugin. Esses posts serão ‘criados por’ 1 de 10 usuários regulares diferentes. O motivo de ser uma ação de plugin é porque os usuários dessa instância específica possuem uma equipe de moderadores que desejam treinar e querem alguns posts de teste para treiná-los, além da capacidade de gerar mais quando precisarem.
Consegui fazer isso funcionar passando skip_validations: true para PostCreator.new, mas agora surgiu a exigência de que alguns dos posts criados também sejam sinalizados (flagged).
Primeiro, tentei desabilitar o RateLimiter, mas isso acabou causando a queda do processo do servidor eventualmente, possivelmente quando eu tentava reativá-lo, e então percebi que provavelmente não era uma boa ideia de qualquer forma.
Então, minha pergunta é: existe uma maneira melhor de contornar o limitador de taxa ao executar algum código arbitrário, ou seja, algo como:
RateLimiter.bypass do
# executa algum código não afetado pelo limitador de taxa
end
Ou preciso basicamente copiar a maior parte do que o PostActionCreator faz, mas deixar de fora a linha problemática?
Qualquer ajuda seria muito apreciada! Ainda estou assimilando bastante do código do Discourse, então estou ciente de que provavelmente perdi algo que tornaria isso muito mais fácil!
Não é realmente um caminho que eu queira seguir, pois prefiro que seja iniciado pelos usuários, em vez de eles dependerem de mim para executar um script no console.
Você descobriu isso? Modificar o arquivo yaml não é ideal, pois requer uma reconstrução. Eu não sou familiar o suficiente com rails/discourse para descobrir como desativá-lo temporariamente no console.
Tentando importar 60 mil usuários via API o mais rápido possível sem fazer um rebuild. Eu também tentei em uma instalação de teste aumentar o limite da API ADMIN via YAML, mas não pareceu funcionar, mas talvez eu tenha feito algo errado. (Estou executando as importações no container, então o throttling HTTP não deveria se aplicar).
Mas você pode entrar no contêiner e editar /var/www/discourse/config/discourse.conf e definir essas variáveis lá e depois fazer um sv restart unicorn (ou talvez sv reload unicorn). Provavelmente você vai querer fazer algo como apt-get update; apt-get install -y vim para ter um editor.
Estranho. Quando visualizo o arquivo de configuração, o novo limite já está definido. Então a atualização do YAML funcionou:
max_admin_api_reqs_per_key_per_minute = '6000'
Mas parece não funcionar. Ainda há uma limitação de 60 por minuto. Quando limito as requisições para 60 por minuto, a maioria passa, mas devido a oscilações, algumas ainda acionam o limitador de taxa:
{'success': True, 'active': True, 'message': 'Sua conta está ativada e pronta para uso.', 'user_id': 3596}
{'success': False, 'message': 'Novos registros não são permitidos do seu endereço IP (limite máximo atingido). Entre em contato com um membro da equipe.', 'errors': {'ip_address': ['Novos registros não são permitidos do seu endereço IP (limite máximo atingido). Entre em contato com um membro da equipe.']}, 'values': {'name': None, 'username': 'asdfd', 'email': 'user@domain.com'}, 'is_developer': False}
{'success': True, 'active': True, 'message': 'Sua conta está ativada e pronta para uso.', 'user_id': 3597}
Eu acho que está relacionado a outro limite: acho que é o limite máximo de registros de um IP que está sendo atingido, mas não entendo por que, depois de atingir esse limite, ele não bloqueia permanentemente. Possivelmente um bug neste limite de spam?
Se todos esses usuários tiverem o mesmo IP, então aposto que você está certo. Acho que a solução é alterar essa configuração ou dar às pessoas endereços IP falsos como 127.0.0.x (ou talvez usar IPv6 para facilitar?)
Eu acho que ele está detectando de onde a solicitação está sendo feita (computador host), mas posso contornar isso adicionando um usuário TL2 no mesmo endereço IP (ou ajustar o limite de IP).
Sim, vou tentar isso. Mas não está claro como devo executar o script, onde devo copiá-lo e como devo executá-lo (depois de colocar o CSV nos lugares certos)?
Apenas como acompanhamento, dado o esforço para entender os scripts e Ruby, etc., e o desempenho provável, segui outro caminho e contornei todos os limites escrevendo diretamente no banco de dados usando SQL. Desta forma, consegui várias milhares de inserções por segundo.
Houve um tópico perguntando quais tabelas eram necessárias, ele está fechado agora, então respondo aqui que alterei as seguintes tabelas para inserir os usuários: