Hi Nick. I think that you are taking wrong conclusions on wrong assumptions. IMHO
I'm not trying defend clojure or erlang, I like them both. I try to explain me: When you trying to scale one single machine to 1-2M persistent connections, the main problem will not be the virtual machine (jvm or beam), will be your operating system (among other factors mentioned later). Additionally, if you will try to scale in this manner in AWS, good luck, but I'm pretty sure you will found you pay much more that you have expected, because virtual machines on aws does not behaves like bare metal and will introduce additional IO latencies that you do not have expecting now. Scaling horizontally does not implies buy more and more expensive servers. Implies buy more cheaper servers. In my personal and real experience... we have migrated one application from one monolitic high power server to 5-10 small servers (depending on demand), and we have started to have less applications errors, less timeouts, increase the maximum number of possible persistent connections. Why? The JVM/Beam is not he only thing that runs on your machine, with bigger machine the operating system should handle much more IO, memory for connections, socket buffers, etc... that will implies big latencies and other consequences. You should do very high fine tuning of the operating system for make your OS not obstacle. And forget do it on virtual environment (aws)... Independently if you will use erlang or clojure, vertical scale is not a good approach in much of cases. Later, you are taking a decision taking microbenchmarks. Is well know that micro benchmarks are very less precise that you are expecting. Have the ability to handle 2M persistent connections does not depends only on the server/language and how they handle the "hello world" request/response, where are other players in the equation: persistence and your business logic, operating system tuning, virtual/bare metal hardware, network hardware... Do you want also have the persistence layer on the same server or in a separated one? Is a persistence layer also accepts 2M persistent connections? I don't mean nothing with it, only I want to say that 1-2M connections is very very big number of connections and is usually reached in very specific situations (for single machine). And the first challenge for to have an application that scales vertically to 2M connections is your code, not the language and its vm... And finally, having everything in one server make it less fail tolerant, if the machine is gone, everything is gone... The golden rule is: "Divide and conquer". My two cents. Andrey. On Thu, Oct 8, 2015 at 12:43 AM, Nick Pavlica <lini...@gmail.com> wrote: > Hi Timothy & Moe, > Thanks for your feedback! I realize that we are speaking very generally > on this thread, and know that there are many ways to solve the complex > problems we face as developers. I'm trying to understand the current know > limitations of using great tools like Clojure to solve the problems I'm > facing. Clojure is bound by the JVM which wasn't directly designed to > address high concurrency needs in the same way that Erlang/Go/etc. are. My > experience with Java/JVM in the past was that it was more focused on raw > throughput, and less about high levels of concurrency. I was hoping that > there were some good high concurrency solutions in place. That's what > prompted my original question about the only benchmarks that I could find. > If you have any additonal benchmarks, papers, etc., to share on this > subject, it would be great! > > Timothy Wrote: > "I'd investigate other tools (Netty?) before discounting an entire > platform" > - I'm open to any suggestions. However, I believe that Aleph is > build on Netty. > > "I question why anyone would need 200k connections on a single > box, use AWS auto scaling" > - There are many reasons, but in my case I'm paying for each > server, and I have to maintain not only the ones that I need to get the > work done, but ones I need for redundancy etc. There is a huge business > case for doing the same work on one server that would otherwise take two > or three. An AWS server equipped similarly to the one in the benchmark is > running about $1200/month, adding two more would obviously increase my > costs by $2400/month or $28,000/year. > > Mo Wrote: > "The github webserver benchmarks also contain many numbers above > 200,000 qps, for a variety of other webservers - right?" > - Yes, they are really great at throughput, but that's not > necessarily the primary metric that I'm looking for. I'm trying to > determine if they are reliable and perform reasonably well with many > connections. I realize that http-kit made a claim of 600K connections in > 2013. But I can't find any other supporting evidence that it can do that > reliably. It also seems to have stagnated a bit as a project which is > unfortunate. > > Thanks Again for your input and guidance! > -- Nick > > > > > > > > On Tuesday, October 6, 2015 at 9:57:45 PM UTC-6, Nick Pavlica wrote: > >> Dear Clojure/Java Experts, >> Earlier today I posted a question to the Immutant google group asking >> them a question about large numbers of concurrent websocket connections and >> their server. A member of the group kindly responded with a link ( >> https://github.com/ptaoussanis/clojure-web-server-benchmarks) to some >> fairly recent benchmarks that included a number of Clojure/Java servers. >> After looking at the numbers in the benchmark, I was a little disappointed >> to see that they were only serving 60K connections as compared to other >> solutions like Erlang which seem to be capable of 1-2+ million connections >> on similar hardware. The difference on the surface seems dramatic, and I >> was wondering if someone could help clarify the numbers for me. It makes >> me wounder if there is a JVM solution that can even meet these numbers half >> way, or if I'm missing something? >> >> Many Thanks! >> --Nick >> >> >> ####### Discussion from the Immutant Google group ###################### >> >> All, >> I'm a new Clojure developer, and I'm looking for a webserver that can >> handle a large number of concurrent websocket connections. I understand >> that this question is a little/very vague, and is dependent on many factors >> like the OS, it's Kernal, amount of RAM in the system, etc. However, there >> are a number of generalized claims out there, and I was wondering if anyone >> has done any basic testing/benchmarking with Immutant/Undertow? >> >> Examples: >> >> - http://www.http-kit.org/600k-concurrent-connection-http-kit.html >> >> - >> http://highscalability.com/blog/2013/5/13/the-secret-to-10-million-concurrent-connections-the-kernel-i.html >> >> - https://en.wikipedia.org/wiki/C10k_problem >> >> - https://vimeo.com/44312354 >> >> - And so on ... >> >> Thanks! >> --Nick >> >> >> -------------------------------------------------------------------------------------------------- >> >> Hi Nick, >> Here are some fairly recent benchmarks that are relevant: >> https://github.com/ptaoussanis/clojure-web-server-benchmarks >> >> --Sven >> >> ------------------------------------------------------------------------------------------------- >> > -- > 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. > -- Andrey Antukh - Андрей Антух - <n...@niwi.nz> http://www.niwi.nz https://github.com/niwinz -- 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.
