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.

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

Efficient static serving #123

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

Fractal147
Copy link
Contributor

Simple changes focussed on static file serving:
Drops the req table when it's never used by the fileServeFunctions, (-static and -error) by setting it to nil.
Uses the socket directly in the bulk of httpserver-static.lua to avoid using buffers.
Will reduce amount sent per packet to 1024 bytes from 1400, but will save at least that amount of active memory, or probably more since buffer manipulation, etc.
And makes bufferedConnection local, to prevent it being a global (to save memory - anything that uses it has a local copy anyway)

bufferedConnection was global and didn't have to be. Part of issue marcoskirsch#113
This is a memory optimisation. Directly send 1024 byte chunks of static file to the connection socket, without buffering.
Cost is that it never sends 1400 byte packets, but plus is that it never has to store up to 1399 bytes extra in memory.
Overall results in less memory usage for static file serving.
for httpserver-static.lua, and httpserver-error.lua, req is never called or needed, so can be set to nil, before it is passed on.
This saves memory, particularly for static files, since it never needs to store the full request header.
Req is only passed on to scripts.
@HHHartmann
Copy link
Contributor

Good findings!
I would prefer to keep the coroutine stuff visible in as few places as possible and maybe add another function to BufferedConnection. Maybe DirectSend which would first flush the old buffer and then send the new buffer.
I also thought about automatically letting Send decide whether to fragment the new buffer or if it is long enough first flush the connection and then send the new (big) buffer.
Let's say if a buffer of 900 bytes rolls in and we already have 300 bytes buffered then first send the 300 and then the 900 instead of chopping the 900 bytes apart.

That way also other applications that pump data could benefit.

@marcoskirsch
Copy link
Owner

@Fractal147 do you care to fix the merge conflicts and test? I will merge.

@Fractal147
Copy link
Contributor Author

@marcoskirsch Err, I've completely forgotten about this! I'm still pretty new to github - what do you need me to do?

@marcoskirsch
Copy link
Owner

There is a built-in online conflict editor which is enough if the conflicts are simple.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants