This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-08-11
Channels
- # babashka (3)
- # beginners (70)
- # calva (15)
- # cider (34)
- # clara (10)
- # cljsrn (2)
- # clojure (28)
- # clojure-europe (21)
- # clojure-france (1)
- # clojure-uk (17)
- # clojuredesign-podcast (4)
- # clojurescript (51)
- # cursive (21)
- # data-science (1)
- # datalog (2)
- # datascript (2)
- # datomic (10)
- # emacs (5)
- # esprit (24)
- # expound (9)
- # figwheel-main (15)
- # fulcro (31)
- # graphql (3)
- # jobs-discuss (27)
- # keechma (2)
- # luminus (2)
- # malli (2)
- # minimallist (14)
- # nrepl (1)
- # off-topic (4)
- # pathom (1)
- # pedestal (8)
- # re-frame (10)
- # reagent (5)
- # reitit (2)
- # rewrite-clj (54)
- # sci (1)
- # shadow-cljs (34)
- # spacemacs (12)
- # sql (17)
- # vim (16)
- # web-security (1)
Should I expect to see a performance improvement with hugsql when switching from the default adapter to jdbc.next adapter? didn't see much difference when I tried it in a production environment.
We didn't notice any directly, but some things are nicer, like extending PG types as compared to clojure.jdbc
@ben.sless since HugSQL isn't using plan
, the only performance difference you'll see is in "large" result sets that will be constructed quite a bit faster than with c.j.j
(that can be quite a substantial difference)
Also, if you construct a datasource once from a db-spec, and then use that datasource everywhere, that should also be a bit faster (using a connection pooled datasource would be faster, of course, and that is also true of c.j.j).
Just wanted to update that I deployed next.jdbc today and I see speedups of up to 20% in some places. Thank you 🙂
Thank you for all the work you put into it and all the help you provide to the community
just wondering why my application reacts so slowly when deployed on a shared hoster. the response time locally is good
@synthomat Yes, if you use a db-spec (hash map) or connection URL string, then next.jdbc
(and c.j.j) will make a datasource from that and then call .getConnection
on it; if you use a datasource, both libraries will call .getConnection
on it. You can either use get-connection
and with-open
(as shown in the docs) to reuse a connection across multiple operations, or you can use a connection pooled datasource (the recommended approach).
next.jdbc
has built-in support for both HikariCP and c3p0 (and any others that follow the same API pattern as those two -- but those two are the supported and tested ones).
On shared hosting, it's entirely possible that standing up a new DB connection is very expensive (it's expensive, in relative terms, even locally but not so much that you really notice).
For any type of production app, I would always use connection pooling https://cljdoc.org/d/seancorfield/next.jdbc/1.1.582/doc/getting-started#connection-pooling