Ratpack talk - The story so far

I recently gave a talk to developers at Sky where I am currently working with Energized Work on the subject of our team's experience with Ratpack.



Apologies for the technical issue half way through (and also for the huge number of erms and ers). 

Slides: http://www.slideshare.net/PhillBarber/ratpack-the-story-so-far




Thanks to everyone who came along at Osterley.





...thanks also to the people watching from the Leeds office.

Comments

  1. Djasan2 August 2016 at 12:27

    Hello.
    I have seen the record of this talk on youtube and it was very interesting for me.
    So, there was some question at 54:18 (link for it https://youtu.be/q2vADSqi6XI?t=3257 ) and i could not understand what it was about (could not hear it).
    Could you repeat that question and answer for it here, please?

    ReplyDelete
    Replies
    1. Phill Barber2 August 2016 at 14:06

      Hi Djasan,
      Glad that you found the talk interesting.

      The question was "Why does ratpack default the number of threads to two times the number of CPU cores?".

      ...I had a quick check and yes indeed it does default to two threads per CPU core - see here: https://ratpack.io/manual/current/api/ratpack/server/ServerConfig.html#DEFAULT_THREADS

      My answer was "I don't know". I then went on to guess that perhaps a little bit of thread switching is ok (i.e. one cpu core switching between two threads of execution is better for performance - however in retrospect this seems wrong as the entire idea is thread switching is to be avoided).

      Someone else from the audience then said (it was very muffled so might be wrong here...) that it might be due to the fact that some CPUs will perform hyper-threading on each core which means a single core could perform more than one task in parallel. See wikipedia here: https://en.wikipedia.org/wiki/Hyper-threading

      If you are really thinking about performance (likely if you're using ratpack) perhaps the best bet is to adjust this property based on what (if any) hyper-threading your CPU will do.

      Hope this helps.

      Phill

      Delete
  2. Unknown23 August 2016 at 04:48

    Hi Phill,

    thanks for a great presentation! I am quite curious about the way who you've tested the performance. Could you please provide a bit more information (about an environment, HW, etc..)

    Thanks!

    ReplyDelete

Post a Comment

Popular posts from this blog

Lessons learned from a connection leak in production

We recently encountered a connection leak with one of our services in production.  Here's what happened, what we did and the lessons learned... Tests and Monitoring detected the issue (silently) Our automated tests (which run in production for this service) started failing soon after the incident occurred.  We didn't immediately realise since they just went red on the dashboard and we just carried on about our business.  Our monitoring detected the issue immediately and also went red but crucially didn't email us due to an environment specific config issue. The alarm is raised A tester on the team realises that the tests had been failing for some time (some time being 4 hours... eek!) and gets us to start investigating. Myself and another dev quickly looked into what was going on with our poorly  dropwizard  app.  We could see from the monitoring dashboard that the application's health check page was in error.  Viewing the page showed us tha...
Read more

How to connect your docker container to a service on the parent host

Recently I needed a docker container to access a service running on the parent host.  A lot of the examples on the internet were very close to what I needed, but not quite. First off, docker's documentation provided an example that (as far as I can see) doesn't actually work.  The following (I think) is meant to inject the src ip address of the parent host's default interface: $ alias hostip="ip route show 0.0.0.0/0 | grep -Eo 'via \S+' | awk '{ print \$2 }'" $ docker run  --add-host=docker:$(hostip) --rm -it debian What it actually does is inject the ip of the default gateway on the parent host which doesn't help us. Michael Hamrah 's blog details the " gateway approach " of getting the parent's host ip from within the docker container.  This works great, although I wanted to inject the ip on container run and not have that logic within my docker image. Inject the src ip of the docker interface I think the best ...
Read more

Client Side vs Server Side Session

Image
We recently looked at replacing our legacy session management system with a new one.  During this analysis, we came close to choosing a client side session but eventually concluded server side was better for us.  Here's why... Client side session In this model, all session state is stored in the client in a cookie.  The benefits of this are you don't need to worry about persisting and replicating state across nodes, session validation is lightning fast since you don't need to query any data store which means it's super scalable.  The session cookie must obviously be tamper proof (to prevent people creating a session of their choice) which is achieved by signing the cookie using asymmetric cryptography. The signing of a cookie value uses the private key, the validation uses the corresponding public key.  Our idea was to try and keep the private key as private as possible by storing it in memory only.  Each node (4 shown below) would create a new priva...
Read more