A persistent key-value server in 40 lines and a sad fact (2014)(java-is-the-new-c.blogspot.com)
java-is-the-new-c.blogspot.com
A persistent key-value server in 40 lines and a sad fact (2014)
http://java-is-the-new-c.blogspot.com/2014/12/a-persistent-keyvalue-server-in-40.html
35 コメント
PS. The moving gif's make it very hard to read.
If you're using Firefox, go into about:config and change image.animation_mode to none, then reload the page.
Or just use any browser's inspector to delete them.
Agreed.
Disagree, chuckles
Don't look at the "moving gif's" (sic.). Then it will be easier to read.
Except that's now how human visual perception works. Movement is distracting and one of the main reason people hate banner ads (which historically have been extremely attention grabbing, occasionally resorting to strobing for maximum attention).
Our brains are geared for paying attention to things that move, especially things that move irregularly (like poorly looped gifs).
Our brains are geared for paying attention to things that move, especially things that move irregularly (like poorly looped gifs).
We're particularly attracted to movements outside the focus point, that's what makes it distracting. The retina cells (mainly rods) further away from the fovea are bad at distinguishing things, but excellent at detecting rapid movements.
It helps noticing prey when hunting or predators when being hunted. It does not help when trying to read some text.
It helps noticing prey when hunting or predators when being hunted. It does not help when trying to read some text.
Might be quick when running but the jvm startup time is a pain.
By the time the java solution starts up, my c based solution has already finished.
http://blog.ndk.io/2014/02/11/jvm-slow-startup.html
40ms sounds okay for me, even for most command line tools. Oh and I most probably don't get a segmentation fault ;-)
40ms sounds okay for me, even for most command line tools. Oh and I most probably don't get a segmentation fault ;-)
Sure wish my JVM started in 40ms. Here's ruby:
$ time ruby -e "puts 'hello world'"
> hello world
>
> real 0m0.076s
> user 0m0.029s
> sys 0m0.017s
$ time ruby -e "puts 'hello world'"
> hello world
>
> real 0m1.161s
> user 0m2.050s
> sys 0m0.093sYour JVM does. jruby.jar is megabytes of reimplementation and mapping of the Ruby stdlib onto the JVM. Plus in this example, loading a Ruby parser and interpreter.
Here's executing an assembly (über-jar) I wrote in Scala:
A few hundred ms on my 1.2GHz MacBook. And this includes a bunch of Akka Actors.
Here's executing an assembly (über-jar) I wrote in Scala:
→ time scripts/couch
Please provide a basePath and a valid command. ("backup", "restore", "truncate", "migrate" or "migrate-all")
real 0m0.375s
user 0m0.415s
sys 0m0.073s
A few hundred ms on my 1.2GHz MacBook. And this includes a bunch of Akka Actors.
Startup time in a server is a non-issue... Those processes keep running the whole time.
Yeah, and memory is infinite, and all disks are free, and the computing fairies make all the processors super fast.
But back in the real world, startup time is a valid concern.
Don't know your "real" world. In my real world, the AWS instance takes several minutes to come up - I can spare some milliseconds on thr JVM startup.
In my real world the containers we spin up come up in seconds, but container restart is far more rare than restarting services.
If the time to restart your process or host affects the overall operation and performance of your service you're doing it wrong.
If your services consistently restart quickly, it gives you the freedom to design things differently.
E.g. doing a rolling update across a large number of instances by restarting a service at a time can become a quick enough process to be viable in instances where you'd otherwise need lots of excess capacity to be able to cycle larger proportions of instances at the same time. Making full rolling updates "cheaper" both in time and resources also translates to making rapid updates a safer choice (e.g. if I can roll back a broken release in 5 minutes, it's far safer to push out a new release than if a rollback takes hours).
E.g. doing a rolling update across a large number of instances by restarting a service at a time can become a quick enough process to be viable in instances where you'd otherwise need lots of excess capacity to be able to cycle larger proportions of instances at the same time. Making full rolling updates "cheaper" both in time and resources also translates to making rapid updates a safer choice (e.g. if I can roll back a broken release in 5 minutes, it's far safer to push out a new release than if a rollback takes hours).
That just means you expect restarting to be slow and have excluded it from your system design.
There is no problem with restarting nginx to update its config once a second, and it's even encouraged that you do so. Besides, crash-only software recovery is really the only morally sound development technique.
There is no problem with restarting nginx to update its config once a second, and it's even encouraged that you do so. Besides, crash-only software recovery is really the only morally sound development technique.
How many reboots per second are you having to endure? Maybe you should make your server process crash less often.
The test highlights an issue not covered by micro-
benchmarking: Encoding and Decoding should perform
similar, as factual throughput is determined by
Min(Encoding performance, Decoding performance).
For unknown reasons JDK serialization manages to encode
the message tested like 500_000 times per second,
decoding performance is only 80_000 per second so in
the test the receiver gets dropped quickly:
Probably he has a problem with malloc during the decoding phase. Every malloc and every free costs between 300 (best case) and several thousand cycles (syscall is required).
its not "he" that's a JDK issue
ChronicleMap looks really cool, i didn't know about it, but it seems like exactly what i've been looking for.
I've been keeping an eye on apache directmemory, but that project seems to have little activity.
does anyone here have real world experience with ChronicleMap in production systems?
I've been keeping an eye on apache directmemory, but that project seems to have little activity.
does anyone here have real world experience with ChronicleMap in production systems?
If it is only 40 lines of code, why would you even use Java instead of e.g. C?
Then its 4000 lines ..
Which is still significantly less than with java.
But what is it? The author doesn't bother to describe problem definition and context.
1. 40 lines of glue code, sure. How much external code did he pull in/write? 2. All of this is predicated on the idea that serialization/deserialization is the primary bottleneck. This becomes not your bottleneck when you've got other distributed components in play.