Why is submitting a form is slow in production?

Phoenix Forum Questions / Help
, ,
1

I’ve build a quick/simple(=10+h) application and deployed it on fly.io, but submitting a form is really slow.
I don’t think it’s related to fly.
Locally everything is really fast but once deployed it’s slow once I press the form’s submit button.
It tries to load, really slow and I guess it fails… No mails were send/received.

lib/x_web/templates/myform/myform.html.heex

<.form let={f} for={@changeset} id="form" phx-submit="new_myform" phx-hook="Form">
...
  <%= submit "Submit" %>
</.form>

lib/x_web/live/myform_live.ex

...
  def handle_event("new_myform", %{"myform" => params}, socket) do
    case Myform.create_myform(params) do
      {:error, changeset} ->
        {:noreply, assign(socket, changeset: changeset)}

      {:ok, _sub} ->
        changeset = Myform.changeset(%Myform{}, %{"email" => ""})
        {:noreply,
         socket
          |> put_flash(:info, "some info message")
          |> push_redirect(to: "/")} #BUG: I think here is the problem? but why?
      end
  end
...

I’ve done the phx.gen.auth and those forms are fast in :prod. But those are not liveview? At least they don’t look like the other ones from some tutorials.

Do you know where I should look further? push_redirect? or somewhere else?
TY

2

Did you check app logs for error messages?

1 Like
3 
 2022-09-24T07:24:09.616 app[9ce1b0ec] ams [info] 07:24:09.615 [error] Could not check origin for Phoenix.Socket transport.

2022-09-24T07:24:09.616 app[9ce1b0ec] ams [info] Origin of the request: https://mycustomdomain.com

2022-09-24T07:24:09.616 app[9ce1b0ec] ams [info] This happens when you are attempting a socket connection to

2022-09-24T07:24:09.616 app[9ce1b0ec] ams [info] a different host than the one configured in your config/

2022-09-24T07:24:09.616 app[9ce1b0ec] ams [info] files. For example, in development the host is configured

2022-09-24T07:24:09.616 app[9ce1b0ec] ams [info] to "localhost" but you may be trying to access it from

2022-09-24T07:24:09.616 app[9ce1b0ec] ams [info] "127.0.0.1". To fix this issue, you may either:

2022-09-24T07:24:09.616 app[9ce1b0ec] ams [info] 1. update [url: [host: ...]] to your actual host in the

2022-09-24T07:24:09.616 app[9ce1b0ec] ams [info] config file for your current environment (recommended)

2022-09-24T07:24:09.616 app[9ce1b0ec] ams [info] 2. pass the :check_origin option when configuring your

2022-09-24T07:24:09.616 app[9ce1b0ec] ams [info] endpoint or when configuring the transport in your

2022-09-24T07:24:09.616 app[9ce1b0ec] ams [info] UserSocket module, explicitly outlining which origins

2022-09-24T07:24:09.616 app[9ce1b0ec] ams [info] are allowed:

2022-09-24T07:24:09.616 app[9ce1b0ec] ams [info] check_origin: ["https://example.com",

2022-09-24T07:24:09.616 app[9ce1b0ec] ams [info] "//another.com:888", "//other.com"]

I’ll try to figure out what this means.

4

Basically it means that you need to update your configuration to ensure that the web socket connections from a given set of domains are allowed. It shouldn’t be the cause of your “slowness” grief however. It could be a number of variant factors, but my first guess would be a slow database connection. Besides this form submission, have you detected any slow behaviour in your queries?

Ultimately, you won’t be able to tell what’s taking so much time unless you add some Logger entries. You’ll also probably need to configure it to use a info level which by the looks of things you have. Ideally you would have some telemetry based method to check the length of the Ecto queries, but I can’t assume that you’ve got that setup.

1 Like
5
2 Likes