Upgrade simple HTTP server to run multi-threaded - Errors

[wmwsagara]

Hi all

I'm trying to make a simple HTTP server to run multi-threaded.

Guide: https://deno.land/manual/examples/http_server

server.ts:

import { delay } from "https://deno.land/std@0.136.0/async/mod.ts";

const worker = new Worker(new URL("./worker.ts", import.meta.url).href, {type: "module", deno: {permissions: "inherit",}, });

// First await: waits for a second, then continues running the module.
await delay(1000);

// Start listening on port 8080 of localhost.
const server = Deno.listen({ port: 8080 });
console.log(`HTTP webserver running.  Access it at:  http://localhost:8080/`);

// Connections to the server will be yielded up as an async iterable.
for await (const conn of server) 
{
  // In order to not be blocking, we need to handle each connection individually
  // without awaiting the function
  worker.postMessage(conn);
}

worker.ts:

self.onmessage = async (conn: Deno.Conn) =>
{
  // This "upgrades" a network connection into an HTTP connection.
  const httpConn = Deno.serveHttp(conn);

  // Each request sent over the HTTP connection will be yielded as an async
  // iterator from the HTTP connection.
  for await (const requestEvent of httpConn) 
  {
    // The native HTTP server uses the web standard `Request` and `Response`
    // objects.
    const body = `Your user-agent is:\n\n${
      requestEvent.request.headers.get("user-agent") ?? "Unknown"
    }`;

    // The requestEvent's `.respondWith()` method is how we send the response
    // back to the client.
    requestEvent.respondWith(
      new Response(body, {
        status: 200,
      }),
    );
  }
}

I run the server as follows:

$ deno run --allow-read --allow-net --unstable server.ts

Access as follows:

$ curl -i http://localhost:8080 -d '{"name"="Sagara"}

When try to access, server prints the following error:

error: Uncaught (in worker "") (in promise) BadResource: Bad resource ID
  const httpConn = Deno.serveHttp(conn);
                        ^
    at Object.opSync (deno:core/01_core.js:170:12)
    at Object.serveHttp (deno:runtime/js/40_http.js:9:22)
    at self.onmessage (file:///home/sagara/study/Deno/worker.ts:5:25)
    at wrappedHandler (deno:ext/web/02_event.js:1302:14)
    at innerInvokeEventListeners (deno:ext/web/02_event.js:754:9)
    at invokeEventListeners (deno:ext/web/02_event.js:794:7)
    at dispatch (deno:ext/web/02_event.js:663:11)
    at dispatchEvent (deno:ext/web/02_event.js:1036:14)
    at pollForMessages (deno:runtime/js/99_main.js:157:9)
error: Uncaught (in promise) Error: Unhandled error in child worker.
    at Worker.#pollControl (deno:runtime/js/11_workers.js:152:21)

How can I fix this error?

Best regards
Sagara

[bartlomieju]

You cannot, Deno doesn't allow to send Deno.Conn objects to Web Workers.

[wmwsagara]

Thank you bartlomieju, in that case, what could be done then? If not, how to support large number of concurrent connections?

[bartlomieju]

You could create listeners in each worker instead. Deno doesn't have an equivalent of cluster module from Node, but HTTP performance is very important to us and we are dedicating more resources to improve the performance. CC @littledivy any ideas here?

[kedicesur]

Actually if you use a load balancer like GoBetween then you may perhaps utilize the pooledMap function in std/async/pool.ts module to spawn multiple servers. I think.

[jtoppine]

Thank you bartlomieju, in that case, what could be done then? If not, how to support large number of concurrent connections?

Is your workload bottlenecked by the HTTP handling itself, or the contained userland code that generates the responses? In the latter case, you could keep all the HTTP related stuff in the main thread, keep it lightweight, and only do the actual response generation in workers. So in the main thread you would generate a message object like {action: 'dostuff', path: 'foo', data: 'bar'}, then pass that to your worker pool. Worker would then respond with something like {status: 200, type: 'text/html', body: 'lorem impsum'}, and the HTTP handler in main thread would send a response based on that.