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

TTFB problems with -H #45

Open
ghost opened this issue Apr 18, 2016 · 0 comments
Open

TTFB problems with -H #45

ghost opened this issue Apr 18, 2016 · 0 comments

Comments

@ghost
Copy link

ghost commented Apr 18, 2016

I first want to say thanks for a great boot task, this is very helpful.

My current api setup does not make it easy for client-side developers. In order to get around CORS and other resource-allowed security issues, I have to proxy things around. Requests to /api are proxied to the actual development api, while all static-file requests are served from a local fileserver.

While trying to get boot-http to play this proxying role, I notice the TTFB slows dramatically (500-800ms to 2500ms). I can't see anything obvious in the source that would cause this slowdown, except for the fact that I'm using -H 'my.handler, where my-handler (and its dependencies) could be choking the pipeline:

(defroutes routes
  (route/resources "/" {:root "target"})
  (route/files "/" {:root "target"})
  (route/not-found "Page not found")
  (OPTIONS "/v1" []
           {:status 200
            :headers {"access-control-allow-origin" "*"
                      "access-control-allow-credentials" true
                      "access-control-allow-headers" "allow, content-type, cache-control, authorization, location, if-none-match"
                      "access-control-allow-methods" "GET, PUT, POST, DELETE, OPTIONS, PATCH"
                      "access-control-expose-headers" "allow, content-type, cache-control, authorization, location, etag"}}))

(def app
  (-> routes
      (wrap-proxy "/v1" "my.development.api/v1")))

This all looks like pretty standard stuff that is widely used, and I can't imagine that's what's causing the slowdown. After some more exploration I noticed that the boot task itself when declaring :reload true seems to cause the dramatic TTFB reduction.

(serve :dir "target" :handler 'proxy.core/app :reload true) <-- 2500+ ms
(serve :dir "target" :handler 'proxy.core/app) <-- 500-700ms

I guess I have two questions- 1) any idea why this is so much slower? 2) the ring-reload here is just reloading my proxy.core/app.cljs routes files if that changes, correct? If that's the case I can happily turn it off since this is just a simple dev-only proxy server.

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

No branches or pull requests

0 participants