Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A persistent key-value server in 40 lines and a sad fact (2014)

java-is-the-new-c.blogspot.com

Post reply on HN
Print view View original

31–36 of 36 posts

Re: A persistent key-value server in 40 lines and a sad fact (2014)

#31

Post by juliangregorian »

sarnowski wrote: post #7
javaispoo wrote: post #4

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 ;-)

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
And here's jruby:

    $ time ruby -e "puts 'hello world'"
    > hello world
    >
    > real	0m1.161s
    > user	0m2.050s
    > sys	0m0.093s

Re: A persistent key-value server in 40 lines and a sad fact (2014)

#32

Post by ssmoot »

juliangregorian wrote: post #31
sarnowski wrote: post #7

Earlier quoted context omitted.

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 ;-)

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 And here's jruby: $ time ruby -e "puts 'hello world'" > hello world > > real 0m1.161s > user 0m2.050s > sys 0m0.093s

Your 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:

  → 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
That's basically just `java -jar couch-utils.jar`.

A few hundred ms on my 1.2GHz MacBook. And this includes a bunch of Akka Actors.

Re: A persistent key-value server in 40 lines and a sad fact (2014)

#33

Post by astrange »

thescrewdriver wrote: post #25
vidarh wrote: post #14

Earlier quoted context omitted.

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.

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.

Re: A persistent key-value server in 40 lines and a sad fact (2014)

#34

Post by bradhe »

Couple thoughts.

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.

Re: A persistent key-value server in 40 lines and a sad fact (2014)

#35

Post by vidarh »

thescrewdriver wrote: post #25
vidarh wrote: post #14

Earlier quoted context omitted.

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).

Post reply on HN