> From browsing issues, it looks like the HttpServer.jl performance issue > you referenced below should be now fixed by > https://github.com/JuliaWeb/HttpServer.jl/pull/59.
Yes, this issue has been fixed. It seems Julia can have low latency Yes, on my later tests latency was pretty good (are Flask and Splay [numbers, for it and throughput] considered > best-in-class, at least for those language?) Spray is pretty good, Flask is here just for comparison. I don't think Flask has been developed with performance in mind. Do you only disagree, then only, with the "high throughput" As you can see from results in #40, HttpServer.jl already has pretty good performance, just I believe Julia has no blockers not to get even more (comparable to best-in-class). I wander how difficult or stupid it is to support old APIs here in some > way.. In most cases it's unreasonable to keep outdated API for many reasons. But "probably comparable with Erlang" was not an error, taken > conservatively, you are probably talking about what pure benchmark numbers > of concurrency (only) might indicate. I believe Erlang has more (than > speed) currently not in Julia, while not better for non-concurrency related. When processing large number of small requests (e.g. text messages in social network or requests to API), blocking network operations become a bottleneck. E.g. if you have blocking "get()" operation, you either need to waste processing time until request is complete or switch processor context. Both of these are quite expensive and set a limit to a maximum throughput. Erlang has actor-based concurrency, which means that you can switch between tasks without switching processor context and get high utilization of CPU. Scala's Spray is built on Akka, which is an implementation of the same actor model, and gets very good performance. Julia has similar concurrency model using Tasks, and that's why I'm so optimistic regarding future of the web frameworks in Julia. Even if this would work perfectly, I'm not sure (most) Julia (or Java?) > users would want to mix (I guess ok for truly good/critical libraries..) at > least for GUI/enterprise applications.. Consider, for example, Apache Spark and the whole Hadoop infrastructure. There's nothing even close to it in non-JVM world, and that's why other languages (including Python and R) build their interfaces to JVM. On Friday, September 25, 2015 at 4:39:51 PM UTC+3, Jameson wrote: > > From browsing issues, it looks like the HttpServer.jl performance issue > you referenced below should be now fixed by > https://github.com/JuliaWeb/HttpServer.jl/pull/59. > > On Fri, Sep 25, 2015 at 5:47 AM Páll Haraldsson <pall.ha...@gmail.com > <javascript:>> wrote: > >> On Thursday, September 24, 2015 at 11:07:56 PM UTC, Andrei Zh wrote: >>> >>> >>> >>>> I find this statement highly surprising.. wander if you meant to >>>> reverse this.. My quant friend who had worked for years in Python had >>>> trouble parallelizing Python code (may be resolved now..). I'm not >>>> familiar >>>> with R, but Python has the GIL and associated problems. I also thought >>>> Erlang was best-in-class (for concurrent, not "parallel"). >>>> >>> >>> Oops, you are right, it's exactly the opposite. Consider it a result of >>> quick answer between 2 meetings. Julia's capabilities are much better for >>> concurrent and parallel programming than these in Python or R. >>> >> >> But "probably comparable with Erlang" was not an error, taken >> conservatively, you are probably talking about what pure benchmark numbers >> of concurrency (only) might indicate. I believe Erlang has more (than >> speed) currently not in Julia, while not better for non-concurrency related. >> >> >>> For those in the Java/Scala world, I'm less sure about reusing that, I >>>> know you can with JavaCall.jl, but understand there are bugs and >>>> limitations to it. >>> >>> >>> Unfortunately, that's true. @aviks has made a great work connecting >>> Julia to JVMs via Java Native Interface, but as far as I can see, JNI is >>> shitty by itself, and it's very hard to to make integration between Julia >>> and Java really stable. >>> >> >> Even if this would work perfectly, I'm not sure (most) Julia (or Java?) >> users would want to mix (I guess ok for truly good/critical libraries..) at >> least for GUI/enterprise applications.. At least for me, it seems involving >> a JVM or any VM, is outdated.. Yes, Julia has LLVM, but it's not the same. >> >>> >>> "HttpServer.jl, has low latency 0.5 ms and high throughput (latency on >>>> the same order of Python's Flask and Scala's Spray mature frameworks, and >>>> throughput also comparable[82])." >>> >>> >>> That's funny, because specified reference leads to an issue on >>> performance that was opened by me and incorrectly interpreted by the author >>> of Wikipedia page. At that test Julia outperformed Flask, but was still 3-6 >>> times slower than Spray. >>> >> >> >> Good throughput, but very high latency >> https://github.com/JuliaWeb/HttpServer.jl/issues/48 >> "At the same time, with even very naive test in Python (using requests >> library) I was able to get 1.3ms, and with Julia (Requests.jl) it was even >> lower - about 0.5ms per request." >> >> Then the issue was closed. It seems Julia can have low latency (are Flask >> and Splay [numbers, for it and throughput] considered best-in-class, at >> least for those language?). Splay has "< 1 ms" so unclear how much better, >> it may be. It seems you do not dispute the low latency claim of Julia [on >> the WP page] (any more)? >> >> Do you only disagree, then only, with the "high throughput" of >> Julia/[HttpServer.jl] (and would only change high->good)? [With 1000 >> threads] Julia beats Flask, "comparable", while a third of Splay. Maybe >> within an order of magnitude is not comparable.. Not sure about the 6 times >> slower number. >> >> I haven't looked to closely at Requests.jl, so I do not know the >> differences between it and HttpServer.jl are other libraries. It really >> only matters that one library gets good throughput and then you can use >> that one? >> >> >> >>> Seems like I need to repeat my tests to get latest results. >>> >> >> It would be interesting to know if the numbers have improved.. >> >> >>> I didn't check if this works the same, or just similarly? >>> >>> >>> They have totally different APIs and approaches in general. The main >>> point is that if you want to keep it working with updated version of Julia >>> and libraries, you have to adapt web application too. And it's really not >>> funny to come back to a code written half a year ago just because libraries >>> it used are now deprecated. >>> >> >> Yes, see your point.. I guess the stuff still works it it ever did.. I >> see for plots that there is a generic package that is supposed to hide the >> differences of six (by now) different plotting packages.. You say the API >> is totally different, I wander how difficult or stupid it is to support old >> APIs here in some way.. >> >
