Mike, I think you might be better off keeping as much as you can the same between the two test scenarios so that you are only comparing the differences between nodejs and clojure -- and not all kinds of other variables like co-located services/cpu-load on your various hosts, network latency differences, JVM/nodejs cache warm-up behaviors, memory pressure differences, backing store performance, etc. Consider running both apps separately on the same host (warmed up), against the same db, across the same network and so on. Also, I don't think heroku guarantees like-kind performance from launching dynos run to run given that your app may end up on different hosts with each test.
Good luck with your project. Alan On Wednesday, June 24, 2015 at 1:03:39 PM UTC-7, Mike Grabowski wrote: > > Thanks for the reference, I've seen it before and it looks interesting, > especially thanks to the failover built-in. It also greatly shows how > Clojure can reduce the `Java boilerplate`. > > Speaking on the performance note, I am not entirely sure what's causing my > REST API to be slower than `Node.js` one, I have two the same auth logic > implemented in both Node/Clojure. The Node.js version is running on Heroku > (London) with MongoLab hosted in (US-east-1) which can handle login in > 140ms. On the other hand, the Clojure Aleph/Compojure hosted in London on > DigitalOcean with MongoHQ database hosted in the same DigitalOcean region > handles the same thing in 350ms in the best case. This is really weird as > the `non-database` request is 40ms faster than Node.js one. I need to > investigate, but apart from that, all good so far. > > On Wednesday, 24 June 2015 20:49:40 UTC+2, Stuart Sierra wrote: >> >> On Tuesday, June 23, 2015, Mike Grabowski wrote: >> > ... I just can't stop thinking about non-blocking evented >> > IO interactions. It just does not feel right to me to >> > block the thread when e.g. logging in an user. >> > Unfortunately, there are no NIO drivers for the database >> > engines I am interested in (Neo4J, Mongo) so async >> > channels are not the way to go. >> >> This is pretty much unavoidable on the JVM. Java started >> with a multi-threaded blocking I/O model, and that's still >> how most Java code is written despite the availability of >> non-blocking I/O. >> >> The typical way to mitigate this in Java is with thread >> pools. The JVM is capable of handling hundreds of threads, >> and modern operating systems are pretty good at >> context-switching. >> >> For an extreme example, look at Netflix's [Hystrix], which >> isolates *every* library in its own thread pool, so they can >> guarantee timeouts and other bounded behaviors. Netflix >> reports that the overhead of extra threads is worth the >> more-predictable behavior. >> >> [Hystrix]: https://github.com/Netflix/Hystrix >> >> -S >> > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
