You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I just started with Deno yesterday, and no disrespect intended, but I'm not particularly impressed given what I've encountered just a few hours in: 1.3k issues, some security related; unhelpful and/or incorrect documentation. APIs that have significant, easy to encounter bugs, or just appear incomplete, which brings me to Deno.serve (example):
const url = new URL(request.url);
let pathname = url.pathname.toLowerCase();
if (pathname.endsWith('/')) pathname += 'index.html';
const fileSize = await getFileSize(filePath);
if (!fileSize) return new Response("404 Not Found", {status:404});
const file = await Deno.open(filePath, { read: true });
const body = file.readable;
const responseInit:ResponseInit =
{
headers:
{
"content-length":fileSize.toString(),
"content-type":media_types.contentType(path.extname(filePath)) || 'application/octet-stream',
}
}
The above code using Deno.serve (just marked as stable mind you) takes about 5 seconds to load a 1.8mb js file using Google Chrome, and a few milliseconds with Safari. The difference? Safari is only accepting gzip compression while Chrome is accepting Brotli.
Anyway, while I realize this is community driven, it would be great if resolving issues (actual bugs) could be made a higher priority than new features. New users should probably not be encountering, nor having to debug, standard functionality like this right out of the gate. I experienced the same issue with CloudFlare; their code is about as alpha as it gets, which I find inexcusable given their position. Don't follow in their footsteps is all I'm asking.
The text was updated successfully, but these errors were encountered:
dkfdkdodkms
changed the title
Deno.serv br incredibly compression slow
Deno.serv Brotli compression incredibly slow
Jul 6, 2023
cat /dev/urandom | tr -dc A-Za-z0-9 | head -c 2M > words
//main.tsDeno.serve(async()=>{constfile=awaitDeno.open("words",{read: true});returnnewResponse(file.readable,{headers: {"Content-Type": "text/plain",//required to activate compression in Deno.serve},});},{port: 8000});
deno run --allow-read --allow-net main.ts
time curl -v -H "Accept-Encoding: gzip" localhost:8000 > /dev/null # takes few millisecondstime curl -v -H "Accept-Encoding: br" localhost:8000 > /dev/null # takes few seconds
Fixes#19737 by adding brotli compression parameters.
Time after:
`Accept-Encoding: gzip`:
```
real 0m0.214s
user 0m0.005s
sys 0m0.013s
```
`Accept-Encoding: br`:
Before:
```
real 0m10.303s
user 0m0.005s
sys 0m0.010s
```
After:
```
real 0m0.127s
user 0m0.006s
sys 0m0.014s
```
I just started with Deno yesterday, and no disrespect intended, but I'm not particularly impressed given what I've encountered just a few hours in: 1.3k issues, some security related; unhelpful and/or incorrect documentation. APIs that have significant, easy to encounter bugs, or just appear incomplete, which brings me to Deno.serve (example):
The above code using Deno.serve (just marked as stable mind you) takes about 5 seconds to load a 1.8mb js file using Google Chrome, and a few milliseconds with Safari. The difference? Safari is only accepting gzip compression while Chrome is accepting Brotli.
Anyway, while I realize this is community driven, it would be great if resolving issues (actual bugs) could be made a higher priority than new features. New users should probably not be encountering, nor having to debug, standard functionality like this right out of the gate. I experienced the same issue with CloudFlare; their code is about as alpha as it gets, which I find inexcusable given their position. Don't follow in their footsteps is all I'm asking.
The text was updated successfully, but these errors were encountered: