Obrigado pela resposta! O vídeo me ajudou a compreender melhor. Acho que a confusão é em distinguir entre multithreading e assincronia.
No vídeo, se eu entendi direito, ele menciona que Elixir é multithread e, como você disse, usa green threads. Já o JavaScript não é multithread, mas isso não significa que não seja assíncrono.
No exemplo do vídeo, ele é injusto com o JavaScript, pois utiliza uma função sleep bloqueante, que nao é parte da linguagem,mas uma biblioteca que ele installou, enquanto em Elixir ele usa uma função não bloqueante (de acordo com ele mesmo). Se ele usasse uma função bloqueante em Elixir e forçasse a execução em uma única thread, teria o mesmo problema.
Se esse é o caso e o JavaScript executa código assíncrono, então, desde que a função seja não bloqueante como a do exemplo em Elixir, deveria ser possível reproduzir o mesmo comportamento e realizar 400 chamadas em 4 segundos, correto? Decidi tentar! :)
Abaixo está a minha reprodução do código do vídeo usando a mesma função bloqueante.
var express = require("express");
var router = express.Router();
router.get("/", function (req, res) {
require("sleep").sleep(1);
res.json({ message: "Hello World!" });
});
module.exports = router;
function startServer() {
var app = express();
app.use(router);
app.listen(3002);
console.log("Server started at http://localhost:3002");
}
startServer();
E aqui está o resultado
Javascript Async siege -r 1 -c 10 http://localhost:3002
** SIEGE 4.1.6
** Preparing 10 concurrent users for battle.
The server is now under siege...
HTTP/1.1 200 1.02 secs: 26 bytes ==> GET /
HTTP/1.1 200 2.03 secs: 26 bytes ==> GET /
HTTP/1.1 200 3.03 secs: 26 bytes ==> GET /
HTTP/1.1 200 4.04 secs: 26 bytes ==> GET /
HTTP/1.1 200 5.05 secs: 26 bytes ==> GET /
HTTP/1.1 200 6.05 secs: 26 bytes ==> GET /
HTTP/1.1 200 7.05 secs: 26 bytes ==> GET /
HTTP/1.1 200 8.06 secs: 26 bytes ==> GET /
HTTP/1.1 200 9.06 secs: 26 bytes ==> GET /
HTTP/1.1 200 10.07 secs: 26 bytes ==> GET /
Transactions: 10 hits
Availability: 100.00 %
Elapsed time: 10.07 secs
Data transferred: 0.00 MB
Response time: 5.55 secs
Transaction rate: 0.99 trans/sec
Throughput: 0.00 MB/sec
Concurrency: 5.51
Successful transactions: 10
Failed transactions: 0
Longest transaction: 10.07
Shortest transaction: 1.02
Usando uma função bloqueante, consegui reproduzir a mesma lentidão mostrada no vídeo.
Agora, veja o que acontece se eu usar uma função sleep que não bloqueia:
var express = require("express");
var router = express.Router();
function sleep(ms) {
return new Promise((resolve) => {
setTimeout(resolve, ms);
});
}
router.get("/", function (req, res) {
sleep(1000).then(() => {
res.json({ message: "Hello World!" });
});
});
module.exports = router;
function startServer() {
var app = express();
app.use(router);
app.listen(3002);
console.log("Server started at http://localhost:3002");
}
startServer();
Resultado:
(base) ➜ Javascript Async siege -r 1 -c 10 http://localhost:3002
** SIEGE 4.1.6
** Preparing 10 concurrent users for battle.
The server is now under siege...
HTTP/1.1 200 1.01 secs: 26 bytes ==> GET /
HTTP/1.1 200 1.01 secs: 26 bytes ==> GET /
HTTP/1.1 200 1.01 secs: 26 bytes ==> GET /
HTTP/1.1 200 1.01 secs: 26 bytes ==> GET /
HTTP/1.1 200 1.01 secs: 26 bytes ==> GET /
HTTP/1.1 200 1.01 secs: 26 bytes ==> GET /
HTTP/1.1 200 1.01 secs: 26 bytes ==> GET /
HTTP/1.1 200 1.02 secs: 26 bytes ==> GET /
HTTP/1.1 200 1.02 secs: 26 bytes ==> GET /
HTTP/1.1 200 1.02 secs: 26 bytes ==> GET /
Transactions: 10 hits
Availability: 100.00 %
Elapsed time: 1.02 secs
Data transferred: 0.00 MB
Response time: 1.01 secs
Transaction rate: 9.80 trans/sec
Throughput: 0.00 MB/sec
Concurrency: 9.93
Successful transactions: 10
Failed transactions: 0
Longest transaction: 1.02
Shortest transaction: 1.01
Observe que cada requisição levou cerca de 1 segundo, e o tempo total foi 1.02 segundos.
Posso até reproduzir o teste mais pesado do vídeo, com 2 repetições e 200 usuários paralelos:
(base) ➜ Javascript Async siege -r 2 -c 200 http://localhost:3002
** SIEGE 4.1.6
** Preparing 200 concurrent users for battle.
The server is now under siege...
HTTP/1.1 200 1.01 secs: 26 bytes ==> GET /
HTTP/1.1 200 1.01 secs: 26 bytes ==> GET /
....
HTTP/1.1 200 1.02 secs: 26 bytes ==> GET /
HTTP/1.1 200 1.02 secs: 26 bytes ==> GET /
Transactions: 400 hits
Availability: 100.00 %
Elapsed time: 2.08 secs
Data transferred: 0.01 MB
Response time: 1.03 secs
Transaction rate: 192.31 trans/sec
Throughput: 0.00 MB/sec
Concurrency: 197.96
Successful transactions: 400
Failed transactions: 0
Longest transaction: 1.06
Shortest transaction: 1.00
Note como as requisições individuais continuam em torno de 1 segundo, e o total é 2.08 segundos, mais rápido que Elixir no vídeo.
Com relação ao primeiro ponto, o JavaScript roda código assíncrono e consegue responder a chamadas em paralelo, mesmo usando uma única thread. No entanto, é importante lembrar que, se o código for escrito de forma síncrona, ele não será executado de maneira assíncrona. Cabe ao desenvolvedor garantir que o código seja escrito para rodar assincronamente.
Quando o JavaScript encontra funções assíncronas por natureza, como operações de I/O, ele retorna a execução para o fluxo principal do código, permitindo que outras instruções continuem sem esperar. Porém, se o código nunca chegar a uma função assíncrona, ele será executado de forma totalmente síncrona. No meu código acima, essa função assíncrona é o setTimeout. Em algumas linguagem como Python, o desenvolvedor tem que fazer isto explicitamente.
JavaScript se destacou justamente por facilitar a execução de funções de I/O, como leitura de arquivos e chamadas de rede de maneira assíncrona, permitindo que o código continue avançando sem esperar pela resposta do servidor remoto.
O que JavaScript não faz é executar código em paralelo. Todo o código roda em uma única thread e em um event loop. Portanto, se houver algo pesado para processar, como uma grande quantidade de dados, o JavaScript ficará limitado pela capacidade dessa única thread.
Me fale se o que escrevi faz sentido. Estou curioso para saber se consegui entender seu ponto e se estamos alinhados na diferença entre assíncrono e paralelo.