Fork me on GitHub
#datomic
<
2018-11-03
>
eoliphant14:11:23

@souenzzo given that Datomic cloud has some architectural differences, I'd venture that there's no easy 1 to 1 comparison in terms of instance sizes and you'll probably need to do some benchmarking, etc . Also, while query groups have looser constraints, your primary group has to be an i3 class machine. Having said that, say the i3.large has fewer vCPU's but twice as much memory as a c5.xlarge, the i3.xlarge has the same number of CPU's and nearly 4 times the ram. So, again, I'd probably just start with the default i3.large's and do some load testing

souenzzo14:11:40

@eoliphant tnks My application is CPU intensive. My transactor machine is a i3 that keeps at almost 0 even with 3x c5.xlarge peers on ~80% I already tried to scale in different forms, but I need the c5 machines because their (single) threads are faster and it enables a better user experience.

Rustem15:11:34

To @csm @steveb8n : I had warnings about :dependency-conflicts and I removed all this warning from :dependency-conflicts but unfortunately yours advice does not help me and result is the same.

eoliphant15:11:21

ah gotcha. is your i3 using the valcache setup? So, in that case, though, again, you can probably give it a shot with the default production config and test, but based on what you're saying, you can just add a query group, and to your original question, yeah I guess I'd give the m5 a try to see how it runs.

souenzzo15:11:17

I already tryied to use m5. My wrost case goes from 5s to 8s. My needs for c5 there is not related to datomic. Datomic really dictate the instance type that I use?

eoliphant16:11:15

hmm ok, yeah that sucks. yes the query group config template currently only allows for I think t2.medium, m5.medium, and i3.large and xlarge

eoliphant16:11:38

have you tried the i3's in your query group instead of the m5? They are IO vs compute optimized, but they have the local SSD caching

Rustem15:11:15

I repeat this problem again by doing this: 1) Add “buddy/buddy-sign {:mvn/version "3.0.0" }” to deps.edn 2) Create new simple lambda ‘echo-simple’ ---------- (ns topmonks.aino.skills.lambdas_echo (:require [clojure.string :as strings] [buddy.core.keys :as keys] ) ) (defn echo-simple "simple echo " [{:keys [input]}] (str "echo lambda ---" input "---") ) ------- 3) After deploying my project then I test my lambda from AWS lambda (https://eu-central-1.console.aws.amazon.com/lambda) And I got error when “[buddy.core.keys :as keys]” included --------------- { "errorMessage": "java.io.IOException: Premature EOS, presumed disconnect", "errorType": "datomic.ion.lambda.handler.exceptions.Fault", "stackTrace": [ "datomic.ion.lambda.handler$throw_anomaly.invokeStatic(handler.clj:24)", "datomic.ion.lambda.handler$throw_anomaly.invoke(handler.clj:20)", "datomic.ion.lambda.handler.Handler.on_anomaly(handler.clj:139)", "datomic.ion.lambda.handler.Handler.handle_request(handler.clj:155)", "datomic.ion.lambda.handler$fn__4075$G__4011__4080.invoke(handler.clj:70)", "datomic.ion.lambda.handler$fn__4075$G__4010__4086.invoke(handler.clj:70)", "clojure.lang.Var.invoke(Var.java:396)", "datomic.ion.lambda.handler.Thunk.handleRequest(Thunk.java:35)" ] } ------------ I got NO any error when “ ;[buddy.core.keys :as keys]” is commented Could somebody try to repeat this problem? Does it work in your environment or not?

cap10morgan16:11:41

I have a datomic-pro download in a dir (so it has the datomic-pro-version.jar at the root, a lib subdir with deps jars, etc. I am trying to setup a tools-deps project to run some clojure code using datomic and all of its deps w/o triggering a download of them. Is there a more efficient way to do it than having to specify each individual jar in the :paths vector in deps.edn?

cap10morgan16:11:20

Answering my own question: :paths ["src" "/path/to/datomic/datomic-pro-version.jar" "/path/to/datomic/lib/*"] was the answer. (Not "/path/to/datomic/lib/" nor "/path/to/datomic/lib/*.jar")