Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

correção link repositório api e troca texto twitter #1691

Closed
wants to merge 1 commit into from
Closed

correção link repositório api e troca texto twitter #1691

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 7 additions & 7 deletions participantes/guaracy-nim/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -16,15 +16,15 @@ Submissão feita com:
- [mummy](https://github.com/guzba/mummy) para o servidor
- [waterpark](https://github.com/guzba/waterpark) para pool de conexões com o BD
- [jsony](https://github.com/treeform/jsony) para serialização/deserialização de JSON
- [repositório da api](https://github.com/guaracy)
- [repositório da api](https://github.com/guaracy/rinha-de-backend-2024-nim)

[@zanfranceschi](https://twitter.com/guaracybm) @ twitter
[@guaracybm](https://twitter.com/guaracybm) @ twitter

## Considerações

- A utilização de **Nim** é para sair um pouco do convencional. Uma linguagem compilada com sintaxe semelhante ao Python.

- A escolha por **Mummy** se deve a facilidade além de ser relativamente rápido. Não se preocupar com `{.async.}`, `Future[]` e `await` é muito legal para quem não gosta de se preocupar com as [cores das funções](https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/).
- A escolha por **Mummy** se deve a facilidade além de ser relativamente rápido. Não se preocupar com `{.async.}`, `Future[]` e `await` é muito legal para quem não gosta de se preocupar com as [cores das funções](https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/).

- Da mesma forma, **Waterpark** fornece facilidades para trabalhar com um pool de conexões com um BD (MySQL, PostgreSQL e SQlite).

Expand All @@ -51,13 +51,13 @@ Ao executar os testes no Docker, provavelmente por restrições da rinha ou desc
- Para o problema de concorrência no saldo, utilizei `SELECT ... FOR UPDATE` com um `COMMIT` logo após a gravação do saldo para liberar nova leitura da linha. A movimentação e feita logo após, não se preocupando com a concorrência.

- O programa tratou **61503** requisições e todas as respostas foram abaixo de 800ms. Alterando um pouco as configurações (memória e cpu), obtive os seguintes resultados (quanto mais rápido melhor mas, um usuário real não veria muita diferença entre 0,097s e 0,036s):

- sem alterar as configurações, o tempo máximo para resposta foi de **97ms**(0,81%) e 64,2% foram completadas em até **5ms**.

- tirando 20M dos aplicativos e colocando 40M para a base de dados o tempo máximo de resposta caiu para **43ms** (1,62%) e 63,39% foram completadas em até 5ms.

- tirando 0.05 de CPU para os aplicativos e e colocando 0.1CPU na base de dados, o tempo máximo de resposta caiu para **36ms** (0,81%) e o percentual de requisições atendidas em até 5ms foi de 64,21%.

- Em vez de MVC e outras coisas parecidas, como o assunto me lembou bancos e, consequentemente COBOL, resolvi fazer um programa monolítico com DATA DIVISION, PROCEDURE DIVISION, etc.

- `docker-compose build` `docker-compose up` `docker-compose down`
- `docker-compose build` `docker-compose up` `docker-compose down`