View Issue Details

IDProjectCategoryView StatusLast Update
0009284Talerexchangepublic2024-10-22 06:55
Reporterfefe Assigned To 
PrioritynoneSeveritytrivialReproducibilityhave not tried
Status confirmedResolutionopen 
Product Versiongit (master) 
Target Versionpost-1.0 
Summary0009284: inefficient web serving in exchange mhd_spa
DescriptionThe function build_webui opens a file, reads a copy of it into malloced memory (without size restrictions), then calls zlib compress on the buffer. This appears to happen also for pre-compressed files like jpeg and png.

This is very inefficient.

Proposal 1: This is all for static files, so why not pre-compress them? Put foo.html.gz next to foo.html and if the browser supports gzip compression, just serve that file instead. No CPU cycles wasted on compression.

Proposal 2: At least use mmap instead of malloc+read. Doing malloc+read puts unnecessary pressure on the virtual memory system for no gain. The only situation where malloc+read has an advantage is if you expect a filesystem race where someone truncates a file while you have it mmapped. This does not appear to be a realistic scenario here. Downside: you need to track how to free the buffer then and can't just call free on it.
TagsNo tags attached.

Activities

Christian Grothoff

2024-10-22 05:53

manager   ~0023555

mmap always uses whole pages. That's actually inefficient for small files. Here, we do often have rather small files. So if we do this it'd mostly make sense for the one large file.

We could indeed have pre-compressed files on disk, but that'd put more requirements on the installation process. You'd either have to put both compressed and uncompressed into say the Debian package, or have the installer include extra steps to do the compression.

A bigger benefit with compression-on-disk would be that we could actually use sendfile() and avoid mmap/malloc entirely. But, regardless, optimization issue of no practical relevance in the medium term IMO.

Issue History

Date Modified Username Field Change
2024-10-21 14:30 fefe New Issue
2024-10-21 14:30 fefe Status new => assigned
2024-10-21 14:30 fefe Assigned To => Christian Grothoff
2024-10-22 05:53 Christian Grothoff Note Added: 0023555
2024-10-22 05:53 Christian Grothoff Priority normal => none
2024-10-22 05:53 Christian Grothoff Severity minor => trivial
2024-10-22 05:53 Christian Grothoff Product Version => git (master)
2024-10-22 05:53 Christian Grothoff Target Version => post-1.0
2024-10-22 06:55 Christian Grothoff Assigned To Christian Grothoff =>
2024-10-22 06:55 Christian Grothoff Status assigned => confirmed