This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-01-17
Channels
- # admin-announcements (4)
- # aws (26)
- # beginners (88)
- # boot (132)
- # cljs-dev (4)
- # cljsrn (35)
- # clojars (11)
- # clojure (41)
- # clojure-art (33)
- # clojure-austin (1)
- # clojure-chicago (4)
- # clojure-dev (3)
- # clojure-russia (2)
- # clojured (3)
- # clojurescript (9)
- # community-development (19)
- # datomic (34)
- # devcards (2)
- # editors-rus (4)
- # hoplon (29)
- # leiningen (4)
- # music (2)
- # off-topic (21)
- # om (69)
- # other-lisps (1)
- # perun (6)
- # re-frame (1)
- # reagent (9)
- # spacemacs (3)
- # yada (13)
@ricardo: Sounds great. Here’s what I’m planning to test. I’m going to set up a bunch of different lambda functions, all running the same code. I’ll call them at different intervals: every 30 sec, 1 min, 5 min, 15 min and see how that affects instance startup time. I’m also going to add some metrics to the lambda function itself to see if I can see how that affects the first access to an AWS service, since that’s my current problem (not instance startup).
Any other variables? Assigned memory, perhaps? Any suggestions for more data people would like to see while I’m at it?
I’ll be driving all this from the API gateway for now - later I’m going to test other invocation methods to see if that affects things.
@cfleming: Assigned memory is definitely a factor. On the same low-memory-use operation, it’s made a significant difference on warm-up time for a Clojure lambda, since AWS also increases CPU “proportionally” (unclear what those proportions are).
So even if start up time is not your problem, it may have an effect on processing the response.
@ricardo: Ok, I’ll test that too. I’m going to use straight Java and JS to test JVM vs Node without complicating things with Clojure’s startup time.
@ricardo: FYI, this is the sort of thing I’m seeing at the moment for the licence generation:
Intervals: 139, 7159, 0, 975, 0, 786, 71, 445, 145, 2840
Total: 12564
END RequestId: 91ed667e-bce7-11e5-9160-0f34ca00b376
REPORT RequestId: 91ed667e-bce7-11e5-9160-0f34ca00b376 Duration: 12658.36 ms Billed Duration: 12700 ms Memory Size: 512 MB Max Memory Used: 122 MB
Those intervals are in ms, arbitrarily chosen as “significant” parts of the processing.
The 7159 is the code that reads a single record from DynamoDB after making the initial connection to it.
stamp[1] = System.nanoTime();
AmazonDynamoDBClient dynamoClient = new AmazonDynamoDBClient();
dynamoClient.setRegion(Region.getRegion(Regions.US_EAST_1));
DynamoDB dynamoDB = new DynamoDB(dynamoClient);
Table orderTable = dynamoDB.getTable("LicenceOrder");
Item item = orderTable.getItem("orderId", request.orderId);
if (item != null) {
logger.log("Duplicate request for order ID " + request.orderId);
return "ok";
} else {
stamp[2] = System.nanoTime();
Notice that even with a ridiculously bad response time, the difference between the entire time in the actual function and the total request duration is only about 100ms.
I can’t find the corresponding event in CloudWatch for the API gateway log - CloudWatch is hilariously bad.
Probably 50% or more of my calls time out, so I just made it idempotent so people didn’t get two licences with every order, and the payment processor just retries the webhook until it works.
do you guys know of a library for clojurescript to access ec2? and s3?
@clojuregeek: I use the official javascript SDK, no wrapper