zanfranceschi / rinha-de-backend-2023-q3 Goto Github PK

Abri essa issue porquê estou confuso quando a competição irá ocorrer. Naveguei pelo twitter e só vi uma menção a "2 semanas", só para esclarecer as datas e prazos!

Ja que vai usar o badrequest, esse tipo de requisição com data no formato inválido deveria ser badrequest também. É diferente de uma validação de dados.

A especificação diz que:

Dado o termo da busca, a resposta deverá ser uma lista que satisfaça o termo informado estar contido nos atributos apelido, nome, e/ou elementos de stack. (...)

Isso significa que o termo de busca rob deve retornar uma pessoa cujo nome é Roberto ou os termos devem corresponder de forma exata?

teste de repo lockdown

Seria uma boa colocar um arquivo de licença aprovada pela OSI. Recomendo MIT.

O que acha criar um documento markdown para organizar os participantes por linguagem implementada?

O valor gerando por este repositório merece listar separadamente as implementações por linguagem para facilitar a consulta das implementações em cada linguagem.

Como a performance de uma API HTTP CRUD (bom Create, Read neste caso) é muito mais influenciada pela eficiência do banco de dados subjacente do que qualquer outra coisa não seria mais interessante testar todas as APIs contra o mesmo banco já que o objetivo é fazer a rinha de backend e não a rinha de DBAs.

Todos os principais fatores relacionados a perfomance de um teste deste tipo estão intimamente conectados ao banco de dados.

• Indexação: Sem índices adequados, qualquer API será lenta e ineficiente em operações de busca se o volume de dados for significativo.

• Cache: Os bancos de dados têm mecanismos internos extremamente sofisticados para armazenar e gerenciar os dados em memória principal.

• Escalabilidade: A capacidade do banco de dados de lidar com grandes volumes de leitura e principalmente gravações concorrentes é o fator determinante para a performance da API.

No fim vai 'vencer' quem projetar e configurar o melhor banco de dados independente da tecnologia que usar para implementar o backend.

Com o excelente método do @filhodanuvem de rodar o Gatling no GH Actions e publicar reports via GH Pages, acredito que a melhor forma de todos participarem, é com este método. Assim, todos tem o mesmo ambiente de execução, e os testes podem ser em paralelo.

Por exemplo, meus testes no MacBook M1 funcionam muito bem. Já no MacBook Intel, os resultados são diferentes.

https://github.com/filhodanuvem/rinha-backend-2023-go#github-actions--github-pages-deploy

Essa é uma categorização muito subjetiva.

Java é compilada, já que tem um processo estático (AOT) de compilação ou é interpretada já que no fim o artefato ainda é bytecode rodando numa VM e passando por um JIT (que aí sim vai de fato compilar pra machine-code)?

Eu consigo compilar OPcache do PHP de forma AOT e mandar rodar na ZendVM com JIT, igualzinho seria um processo em Java. Se Java entra pra compilada, PHP entra também?

Fora que tem linguagens, tipo Kotlin, que permitem as duas abordagens. Da pra compilar Kotlin direto pra machine-code ao invés de rodar na JVM. Pra onde Kotlin entra?

Não consigo conversar na issue #238 @Krymancer então abri uma nova mas percebi que no resultado da primeira fase não há log no contagem-pessoas.log. Talvez esse seja o problema?

Queria alguma ajuda de qualquer pessoa para entender minha situação.

Aqui esta a minha submissão.
Aqui estão os resultados da primeira fase;

Rodei meu docker-compose em dois computadores diferentes com sistemas operacionais diferentes de várias maneiras.

Inclusive rodei os comandos exatamente comem estão na rinha-primeira-fase.sh, queria entender o porquê minha API não subiu, configurei algo errado? Provavelmente, sim, contudo, não consegui achar o que era.

Se alguém tiver alguma ideia eu agradeceria muito.

Duvida sincera
Na live o teste vai checar a risca os itens especificados nas instruções ou checar o desempenho final, quantidade de KO, OK, etc.
Por exemplo, uma estratégia usada pra diminuir a latência na criação da pessoa foi colocar os inserts no banco em background, não sendo verificado unicidade do apelido na requisição, devolvendo 201 e não 422

Queria alguma ajuda de qualquer pessoa para entender minha situação.

Aqui esta a minha submissão.
Aqui estão os resultados da primeira fase;

Rodei meu docker-compose em dois computadores diferentes com sistemas operacionais diferentes de várias maneiras.

Inclusive rodei os comandos exatamente comem estão na rinha-primeira-fase.sh, queria entender o porquê minha API não subiu, configurei algo errado? Provavelmente, sim, contudo, não consegui achar o que era.

Se alguém tiver alguma ideia eu agradeceria muito.