tag:blogger.com,1999:blog-8508935345157628191.post8710600057853645743..comments2024-03-27T22:41:50.041-07:00Comments on Phill Barber's Blog: Choosing between Ratpack and Dropwizard. Phill Barberhttp://www.blogger.com/profile/18399785532886246472noreply@blogger.comBlogger9125tag:blogger.com,1999:blog-8508935345157628191.post-25924199196177956802017-01-16T22:09:19.930-08:002017-01-16T22:09:19.930-08:00Is it possible to get the source code?Is it possible to get the source code?Anonymoushttps://www.blogger.com/profile/05653918825252358782noreply@blogger.comtag:blogger.com,1999:blog-8508935345157628191.post-24175991592028308292016-02-16T09:33:35.972-08:002016-02-16T09:33:35.972-08:00Hi JuanPa,
Thanks for the comment.
I'll cr...Hi JuanPa,<br /> Thanks for the comment.<br /><br />I'll create a new blog post soon on this very topic.<br /><br />Thanks<br /><br /> Phill Barberhttps://www.blogger.com/profile/18399785532886246472noreply@blogger.comtag:blogger.com,1999:blog-8508935345157628191.post-26776693744218191272016-02-13T19:30:03.590-08:002016-02-13T19:30:03.590-08:00Hello Phil,
Thanks for your post. Has your team ...Hello Phil,<br /><br />Thanks for your post. Has your team been happy with the decision to use ratpack? How was productivity affected?<br /><br />BestAnonymoushttps://www.blogger.com/profile/13849861058911460222noreply@blogger.comtag:blogger.com,1999:blog-8508935345157628191.post-65696274663750690452016-01-28T00:41:45.248-08:002016-01-28T00:41:45.248-08:00Hi Anurag,
That all makes sense now.
With your fi...Hi Anurag,<br />That all makes sense now.<br /><br />With your first comment, I assumed that we were discussing only making the downstream calls async which would still result in each request being processed by it's own thread. <br /><br />However, when you use the @Suspended annotation (as explained in your 2nd comment) it seems you get the benefits of threads being able to deal with multiple requests simultaneously.<br /><br />I have to confess that I'm not that familiar with Jersey (JAX-RS's) async model and how it compares to Ratpack's model.<br /><br />Given our team's familiarity with Dropwizard it's probably something we should have looked into more.<br /><br />CheersPhill Barberhttps://www.blogger.com/profile/18399785532886246472noreply@blogger.comtag:blogger.com,1999:blog-8508935345157628191.post-90782097027409686542016-01-26T02:39:31.989-08:002016-01-26T02:39:31.989-08:00Hey, thanks for taking the time to answer my quest...Hey, thanks for taking the time to answer my question. <br /><br />I think the example of the rx-client was not a great one in this context. I consulted with a few of our team members here who have had much more experience of using async libs and programming approach in the last few months than I have had. They pointed me to the following:<br /><br />https://jersey.java.net/documentation/latest/async.html<br /><br />The server side async model is what we have successfully used in several of our dropwizard apps.<br /><br />From the intro section of the documentation<br />"It will however increase the throughput of the server, by releasing the initial request processing thread back to the I/O container while the request may still be waiting in a queue for processing or the processing may still be running on another dedicated thread."<br /><br />Would the above be useful and pertinent for your use-case?Anonymoushttps://www.blogger.com/profile/07113816105383734265noreply@blogger.comtag:blogger.com,1999:blog-8508935345157628191.post-12596274929278468812016-01-25T09:58:46.736-08:002016-01-25T09:58:46.736-08:00Hi Anurag,
Thanks for the comment. Good questio...Hi Anurag,<br /> Thanks for the comment. Good question... made me think!<br /><br />In the scenario you mentioned, I think you'd still have one Thread for every request that your server responds to. If your use case involved making multiple http calls and they could potentially be done in parallel then this approach would be a benefit. This is the situation described here with the calls to the weather service: https://jersey.java.net/documentation/latest/rx-client.html<br /><br />As it currently stands for us, each request that we process results in one request to a downstream system only. This means there would be no benefit for us just using the asynchronous http client as our threads would have nothing to do in the meantime whilst waiting for a response. We need to be asynchronous at every step of the way whilst handling our requests to get the benefit of the asynchronous model. <br /><br />Hopefully that makes sense and is correct!<br /><br />ThanksPhill Barberhttps://www.blogger.com/profile/18399785532886246472noreply@blogger.comtag:blogger.com,1999:blog-8508935345157628191.post-5221522824366037782016-01-25T06:00:21.581-08:002016-01-25T06:00:21.581-08:00Did you also compare performance with a dropwizard...Did you also compare performance with a dropwizard app that uses a reactive http client (example: https://jersey.java.net/documentation/latest/rx-client.html) to make requests to the ELB?<br /><br />I have no experience in using Ratpack, but a quick read of their doc suggests that the perf benefits you have seen are due to its non-blocking HTTP engine. So it might be possible to get comparable performance by simply using a reactive http lib to make requests to your backend (ELB in this case). <br /><br />Thoughts?Anonymoushttps://www.blogger.com/profile/07113816105383734265noreply@blogger.comtag:blogger.com,1999:blog-8508935345157628191.post-86501304131665799572016-01-20T00:35:28.759-08:002016-01-20T00:35:28.759-08:00Hi Tom,
Thanks very much for taking an interest...Hi Tom,<br /> Thanks very much for taking an interest. All good points which I'll try and answer.<br /><br />* This service will be used at very high loads. The current figures we're estimating for peak load are between 0.5 million and 3 million concurrent users. This equates to 1,750 and 10,500 calls per second respectively. This is obviously a huge range, but even at the minimum it's a huge volume so there was certainly a feeling that it was worth some level of effort to realise the benefits of ratpack.<br /><br />* The memory usage was measured via: jconsole, however only the heap memory was recorded. This isn't ideal, it would have obviously been better to measure the absolute total. If we get a chance to repeat this test, we'll make sure to do that.<br /><br />* The CPU usage was also measured via jconsole.<br /><br />* You mentioned "latency in the upstream system" - If by that you mean latency in the system we call (this is what I'd refer to as downstream so bit confused here), we simply looked at the average latency of the systems we'd be calling. If you meant something else by that, let me know.<br /><br />Regarding the decision itself, to make the most informed one I think you'd have to calculate:<br /><br />1. Extra cost of developing/maintaining ratpack app.<br />2. Extra cost of running the more CPU/Memory hungry dropwizard equivalent.<br /><br />However, these figures weren't estimated to inform our decision which in retrospect was probably a mistake. Despite now having the benefit of hindsight, I'm still not sure how you could go about estimating the extra cost of developing/maintaining the ratpack app. One possible way could be:<br /><br />1. Start off using ratpack.<br />2. Play a couple of sprints delivering stories.<br />3. Have a team retrospective which answers "How much quicker would we have been if we used dropwizard app?"<br />4. Decide on whether or not to continue with ratpack, or revert to Dropwizard.<br /><br />I think this approach has a number of problems though:<br /><br />* The team will likely assess current velocity of using ratpack as "about to improve soon as we get more familiar" - this is something we have said to our scrum master on many retrospectives when faced with slow velocity!<br />* A group of bright and tenacious individuals might view reverting to Dropwizard as "giving up"<br />* The later you ask this question, the more informed you'll be. However the later you ask, the more time you potentially waste by scraping the work done so far and the more likely you are to continue with ratpack for fear of appearing to have wasted time.<br /><br />I think that these problems could be overcome, but I think that the question(s) would have to be framed very carefully so as not to bias the outcome.<br /><br />When we started using ratpack, we said that we could revert the decision if we encountered major problems. So far we haven't but we're still not live! A situation that's far from ideal.<br /><br />If you (or anyone else out there) have any other views on how to make the best informed decision I'd be very keen to hear them!<br /><br />Let me know if this all makes sense or not.<br /><br />Thanks<br />PhillPhill Barberhttps://www.blogger.com/profile/18399785532886246472noreply@blogger.comtag:blogger.com,1999:blog-8508935345157628191.post-20078526903169364842016-01-12T05:34:06.012-08:002016-01-12T05:34:06.012-08:00Hi Phill,
Interesting article.
Can you provide s...Hi Phill,<br /><br />Interesting article.<br /><br />Can you provide some more background on the economic decisions behind this?<br />Your conclusion seems to be that 20-30% efficiency improvements on CPU utilisation and throughput measures are enough to justify taking on the engineering complexity. I'm curious what scale you're running at to justify that.<br /><br />How did you measure memory consumption? Did this include off-heap?<br /><br />How did you decide what conditions to model e.g. latency in the upstream services?<br /><br />Did you consider building an async backend on Dropwizard (i.e. doing your backend calls concurrently and syncing prior to responding)?<br /><br />Cheers,<br />TomTom Akehursthttps://www.blogger.com/profile/10228125640128062577noreply@blogger.com