Fork me on GitHub
Pablo Fernandez09:09:49

I’m doing some performance testing of my Clojure app, and it seems the bare minimum will happily eat 350MB of RAM (Jetty with 6 threads, the minimum). As soon as I add Nashorn, it jumps to >512MB. Is this common or am I experience a problem here? Clojure/Java being memory hungry might have an effect on whether I use Heroku or not.


u cant do ola jon. or can u? eh... :D


Or afternoon now..


@pupeno: ime the jvm isn't super fast/happy until it has ~3gb of ram. Not surprised you have issues on Heroku

Pablo Fernandez16:09:41

I just published what I think it’s the most comprehensive blog post in how to use New Relic with Clojure:

Pablo Fernandez19:09:31

tcrayford: is that personal experience?


I do actually work for Heroku as well though 😉


certainly I've run java apps on Heroku at well under the 512mb limit though

Pablo Fernandez19:09:01

For a few more experiments I think I’ll use big heroku instances for now for some experiments but then I’ll move to VPSs.

Pablo Fernandez19:09:35

Probably just deploying with capistrano.


I'd uh, recommend using bash or something over capistrano


unless you know cap real well


(it's kinda bad imo)

Pablo Fernandez19:09:07

I do know capistrano as I use it already. Using bash would mean having to build a lot of plumbing that capistrano does for me.


fair enough then simple_smile It depends how complex your deploys are. Yeller's deploy system doesn't keep around old deploy artifacts or anything like that, just shoves a file in a place and kills the existing process

Pablo Fernandez19:09:43

Well, you also need to run it on all the servers, run migrations, etc.

Pablo Fernandez19:09:13

I do like having the option to rollback, although I never used it in my life.

Pablo Fernandez19:09:55

Also, are people just deploying uberjars that run standalone? No container like Tomcat? I’m new to the Java world so I don’t know if it’s a good idea to just run the uberjar.


clojure standard is uberjar


don't have leiningen on your production machines


just embed jetty or whatever

Pablo Fernandez19:09:54

Cool. That’s simple enough.

Pablo Fernandez19:09:10

tcrayford: thanks for pointing it about 3GB of ram. I’m running with 1GB and I can’t go above 0.9 hits per second.

Pablo Fernandez19:09:16

I mean, on average.


yeah that's still very slow


I'd expect the average clojure/jetty app to hit ~10k requests/s if it's completely unperformance tuned and not doing too much weirdness with the db


maybe more like 70k-100k if it's still http and tuned somewhat

Pablo Fernandez19:09:10

I’m going to try again with up to 20 virtual concurrent users.

Pablo Fernandez19:09:40

But I do have Jetty limited to 10 threads, trying to stay within the RAM constraints.

Pablo Fernandez19:09:58

Responses are fast though, 78ms.

Pablo Fernandez19:09:46

It seems the JavaScript implementation, Nashorn, is very memory hungry.


oh, you're hitting js on each request? that's likely the problem imo

Pablo Fernandez19:09:30

tcrayford: this is what I’m testing.

Pablo Fernandez19:09:55

I will think of ways to not execute JS when it’s not really needed, but first, I want to understand the performance of it.