I create a dummy client that uses the same arguments but overrides :credentials-provider (not sure why - just in case, probably) and :http-client with this:

(reify cognitect.aws.http/HttpClient
  (-submit [_ _request channel]
    (a/go
      (a/>! channel {:status  200
                     :headers {}}))
    channel)
  (-stop [_]))

(defn get-public-object-url [bucket key s3-dummy]
  (let [result (aws/invoke s3-dummy {:op      :GetObject
                                     :request {:Bucket bucket
                                               :Key    key}})
        {:keys [scheme server-name server-port uri]} (-> result check-aws-result meta :http-request)
        ;; Having the default port in there interferes with the URL signing algorithm of the client apps.
        default-port (case scheme
                       :http 80
                       :https 443
                       nil)
        colon+port (when (not= server-port default-port)
                     (str ":" server-port))
        slash+uri (cond->> uri
                    (not (str/starts-with? uri "/"))
                    (str "/"))]
    (str (name scheme) "://" server-name colon+port slash+uri)))

Oh, hold on. That code is probably not what you're looking for. I think I started writing it as an attempt to get a presigned URL but ended up just making the specific objects public (was OK in that case) and just didn't want to generate the whole URL myself.

Yeah, I remember now. Instead of presigning URLs for private objects, I ended up proxying the data. That particular project works only with small objects, and proxying also gave me a bit of flexibility in how I deal with the data. Sorry for misleading. :)

There might be some relevant information here as well: https://github.com/cognitect-labs/aws-api/issues/5

I guess .generatePresignedUrl takes an AmazonS3Client (whatever that is), and it might be stored somewhere inside Cognitect client (`(def s3 (aws/client {:api :s3}))`) on which you can extract some data like https://github.com/cognitect-labs/aws-api/blob/main/src/cognitect/aws/client/api.clj#L66 E.g. (:service s3) Presigning does not require a HTTP client because it doesn't talk contact AWS to sign a URL. It does the signing entirely client side, by using the access key, secret key and session token. I ended up creating a small lib that does only that for some GET URL's because I wanted a "slim" Babashka script without a lot of external dependencies (read no AWS Java SDK): https://github.com/jacobemcken/aws-simple-sign (it does not support PUT URLs though).

I have been able to do presigned PUT requests with the code here https://gist.github.com/jeroenvandijk/516e13fd9ee3b7adbe010455dc128d8c#file-presigned_aws_api-clj-L21-L78 (also in the PR mentioned above). The aws-lib doesn't support it yet. This can easily be ported to the babashka aw-yeah too

How?

just a random not-well-formed thought 🙂 was thinking that most often use uuid as a key, the above -> navigation can be done with get-in

user=> (let [uuid (random-uuid)]
  #_=>   (get-in {:a {uuid {:b 1}}} [:a uuid :b]))
1

user=> (let [uuid (random-uuid)]
  #_=>   (-> {:a {uuid {:b 1}}} :a (get uuid) :b))
1

well, maybe too random thought

In this example:

user=> (let [uuid (random-uuid)]
  #_=>   (-> {:a {uuid {:b 1}}} :a uuid :b))
Execution error (ClassCastException) at user/eval62321 (REPL:2).
class java.util.UUID cannot be cast to class clojure.lang.IFn

(let [uuid (random-uuid)]
  (-> {:a {uuid {:b 1}}} :a (get uuid) :b))
;; => 1

I also struggle to grok exactly what you were thinking about!

To be callable, an object has to implement clojure.lang.IFn interface. Since java.uil.UUID is not a Clojure-defined class, it can't implement extra interfaces after the fact.

yup

faint memory that was the situation different in ClojureScript?

I'd try profiling.

have you run entirely sequentially to see if the runtime is two seconds?

do time measure only on SQL query part, here you count more, than just SQL query. Not fair comparison.

plus there is network latency anyway

UUID uses a single SecureRandom, so your threads are contending on getting random bytes from that, you'd hope getting the random bytes would be fast, but I dunno, so maybe try bench marking with the uuids all pre-allocated

https://www.postgresql.org/docs/current/functions-uuid.html it is also possible to do it in SQL

but anyway, you should benchmark a sequential run, and the difference between that and your parallel run will tell you how much overhead you have when doing it in parallel

where overhead when doing things in parallel is things like contending on shared locks (the SecureRandom case involves calling some synchronized methods), spinning up new threads, etc

In case it's relevant, (str "SELECT '" (java.util.UUID/randomUUID) "'") was chosen to avoid potential caching (e.g. instead of doing SELECT 1) in my production system I need to concurrently fire several independent queries and I'm trying to tune performance

https://en.wikipedia.org/wiki/Amdahl's_law might be an interesting read in this context if you are not already familiar with it

At what layer would that Postgres query get cached? At the DB?

I have a select ‘ok’ as part of a health check and don’t really care about the timings. What is the random uuid supposed to surface performance wise?

I’ve been in pg performance tuning mode here and there recently but it’s never been at the level you’re describing, but perhaps it would be interesting! Mostly just reading explain analyze buffers etc plans and checking the stats to figure how to make the planner play nice or to identify a possible index.

Between Hikari, rds proxy, Aurora, I dont know how much I’d get from throwing a random uuid in with network jitter and all the indirection, but am here to learn!

If I remember correctly, future uses an agent threadpool with an upper bound on threads. Instead of future, try doing (.start (Thread. (fn [] ...)))

that is incorrect

there are two agent threadpools an unbounded and a bounded one, futures use the unbounded one

Oh, ok. Thought it used the latter 🤷

I’ve been confused by that more than once. Ain’t no shame there.

of course, the unbounded has its own “is this a good idea for performance” associated with it :)

the reason I brought up https://en.wikipedia.org/wiki/Amdahl's_law is because it looks like the question basically comes down to "why am I not seeing a linear speed up when I parallelize this?"

and the commentary explaining the law makes it clear that generally you will never see a linear speed up, and the amount of speed up you see is determined by how much is actually serialized (waiting on locks, other shared resources, etc)

I was writing up a crude version of “spending time spawning threads and doing uuid gen…” which is basically that :D

I have the smooth brain version lol

there is a newer thing(from 1993) the Universal Law of Computational Scalability, which uh, if I understand it is sort of https://en.wikipedia.org/wiki/Amdahl's_law but more fine grained, you get other factors to account for other kinds of delays and overhead, where Amdahl's law just has p

some quick playing around with criterium.core/quick-bench shows creating 1e6 uuids in parallel (no database access at all) is much slower than creating them sequentially

Hey team, wanted to followup: 1. UUIDs and SELECT 1 made no difference The parallel versions both took around ~100ms

(def conn-pool-size 50)
(defn random-q []  [(str "SELECT '" (java.util.UUID/randomUUID) "'")])
(defn same-q [] ["SELECT 1"])

(time
   (->> (range 0 1000)
        (mapv (fn [x]
                (future (next.jdbc.sql/query conn-pool (random-q)))))
        (mapv deref)))

(time
   (->> (range 0 1000)
        (mapv (fn [x]
                (future (next.jdbc.sql/query conn-pool (same-q)))))
        (mapv deref)))

(comment

  (defn same-q [] ["SELECT 1"])

  (defn run-timer [pool-size]
    (when (bound? #'conn-pool)
      (.close conn-pool))
    (def conn-pool
      (let [pool (next.jdbc.connection/->pool
                  com.zaxxer.hikari.HikariDataSource
                  (assoc (instant.config/get-aurora-config)
                         :maxLifetime (* 10 60 1000)
                         :maximumPoolSize pool-size))]
        (.close (next.jdbc/get-connection pool))
        pool))
    ;; Capture the time without printing
    (let [start-time (System/currentTimeMillis)
          _ (->> (range 0 10000)
                 (mapv (fn [x]
                         (future (next.jdbc.sql/query conn-pool (same-q)))))
                 (mapv deref))
          end-time (System/currentTimeMillis)]
      (- end-time start-time)))

  (defn output-data []
    (let [pool-sizes [20 40 200]
          results (for [p pool-sizes
                        _ (range 0 20)]
                    [p (run-timer p)])]
      results))

  ;; This will return the vector of results
  (def res  (output-data)))

size of pool consume server too, each connection is not free

Question: Why is it that increasing conn pool size in this scenario is not helpful? Is 10x speedup of sequential the best we can do?

this is expected to work in that way

potentially try better hardware (like increase memory)

Do you track the timing distribution on the SQL server as well?

Ah, you do, saw it in the initial message.

also SQL server configuration can limit operations

I would indeed try profiling with some wall-clock profiler like e.g. VisualVM. It might tell you where the threads spend the most time waiting.

In first row I would bet on: • SQL server configuration which limit resources or parallel queries • not enough memory / CPU in server or in clj app • I am not sure if poll :maximumPoolSize go up to 50, this is max after all and can be limited by resources under the hood or server reject more

In terms of specs we are using: Aurora on rds https://instances.vantage.sh/aws/rds/db.t3.medium (2 vCPU, 4GB mem) Clojure on ec2 https://instances.vantage.sh/aws/ec2/t4g.xlarge (4 vCPU, 16GB mem) Now reading through this article on https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing.

(Appreciate all the engagement team)

Is optimizing the parallellization the right thing to optimize? You're optimizing the latency of a request to the database. However, for most any database workloads it's far more rewarding to optimize the queries. Check also the AWS configurations. Login to the EC2 machine and see what the ping time is to the DB host. Trace the route if necessary. Look at VPC configuration attached. There are a lot of knobs on AWS database instances, and a lot of knobs for the network.

In our case, we have a bunch of very simple queries hitting the DB. We'll look into the AWS configuration. Is there some resource you would recommend?

Most of my experience for AWS docs is really via Terraform, which are better organized than AWS docs IMO. Also, I remember reading this article[1] about RDS Postgres vs. Aurora awhile back, and anecdotally we found Aurora to be somewhat slower for our workload than straight RDS Postgres without any special tuning. You'll likely want to look at IOPS tuning. [1] https://www.migops.com/blog/is-aurora-postgresql-really-faster-and-cheaper-than-rds-postgresql-benchmarking/

RDS proxy is a thing as well

sizing your connection pool is also a weird science that hikari directs based on platter drives and logical cores, but in rds and Aurora land vcpus and ssd storage is a different matter

https://aws.amazon.com/rds/proxy/

Closing loop on thiis, we'll take a pause on our pg investigation to move on to other things, but here's where we've left things for now.

Appreciate all the engagement!

Since you mention RDS sizing having a material impact, what are the query plans that are slow?