akoutmos
Persistent_term for static assets using Plug?
I am curious if anyone has experimented with using persistent_term (persistent_term — OTP 29.0.2 (erts 17.0.2)) for static assets as opposed to reading from the file system? Obviously you would want to do this in production only so you are not constantly cleansing persistent_term during development. And you would want something in place to hydrate your persistent_term prior to starting your endpoint. But mostly curious if the idea is crazy or not.
I forked the Plug.Static plug and modified it to leverage persistent_term and the initial results looked good.
Most Liked
pera
Nice results. I don’t serve static assets with Cowboy but I am using persistent_term to persist some computationally intensive function calls (mostly parsing and graph construction). I wrote the following helper macro for this purpose:
defmacro defpersistent([{name, value}]) do
atom = quote(do: {__MODULE__, __ENV__.function})
function = Macro.var(name, nil)
quote do
def unquote(function) do
case :persistent_term.get(unquote(atom), nil) do
nil ->
value = unquote(value)
:persistent_term.put(unquote(atom), {value})
value
{value} ->
value
end
end
end
end
I then have function declarations that look like this:
defpersistent function_name: expensive_computation()
def expensive_computation() do
...
end
voltone
Plug.Static, through Cowboy and Ranch, offloads the actual transmission of the data to the OS, using :file.sendfile/5. I imagine it has to do more work initially than your alternative, but depending on the file size and the achievable transmission rate it may actually be more efficient when the transfer takes longer.
It might be interesting to run some more tests with different file sizes and transmission rates (preferably on a real network interface). Maybe the optimal solution is a mix, serving small files from persistent_term while falling back to sendfile/5 for large files.
voltone
Well, if the socket can accept the entire file contents at once, without blocking, then it might be faster to just dumpt the data into the socket from memory, rather than do the system call dance with sendfile.
But if the file is larger than what the socket can handle instantaneously, causing it to block on write, then the BEAM as to go off and do other work, and come back later when the socket is ready for more. That is overhead that you don’t get with sendfile. This is why I suggested to test with different file sizes, and why testing over the loopback interface is not realistic, since it probably has a humongous TCP window size, so the socket will never block for writing.
Last Post!
al2o3cr
Another potential performance pitfall with large files: getting the data from persistent_term to the socket is going to cost at least one copy of the data (from the BEAM to the kernel) where sendfile is only transmitting a “get the data from over there” message.
Popular in Discussions
Other popular topics
Latest Phoenix Threads
Chat & Discussions>Discussions
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #elixirconf-us
- #advent-of-code
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #hex
- #security










