I ran the Nginx and benchmarked it using siege. The performance was about 500 requests/second when I would have expected in the range of 5,000 to 11,000 request per second for nginx on the machine that I ran it on.
I’m currently doing more thorough and scientific testing to quantify the performance issue but I thought I’d ask does this make sense? The good news is that no socket errors were reported. thanks as On 18 Apr 2015, at 6:39 pm, Antti Kantee <[email protected]> wrote: On 17/04/15 21:24, BCG wrote: > Hi all > > First of all, I'm obviously new to the list so let me say hello and introduce > myself... Hello, my name is Ben. Now that that is out of the way... Hi Ben, pleased to make your acquaintance. > I've been following this list for a few months and I've read most of > "Flexible Operating System Internals: The Design and Implementation of the > Anykernel and Rump Kernels" (except for some of the implementation section > which was a little over my head because I'm not an OS hacker) so I think I > have a fairly good idea about what rumpkernels are and what they can do. I > think the work that you all have done is excellent, innovative and a > testament to your skills and dedication. IMHO (which is worth exactly what > you pay for it) rump kernel technology has a promising future that reaches > far beyond the NetBSD project. I think it's becoming even clearer now that they're a stepping stone between the 60s/70s style operating systems and the future way of running software. You can't just throw away the (pre)historic OS, because then you lose the drivers with the bathwater. If the first edition of the book wanted to know "how could we improve monolithic kernels to extract their maximal potential", the second edition will be more along the lines of "how do we want to run software *and how to get there*". Finding an equally accurate ending for the conclusions/futurework in the upcoming 2nd edition is going to be challenging, though ... > In any case, I'm interested in getting started with porting an application > and doing development using rump kernels. I would like to start by porting > the Avian JVM (http://oss.readytalk.com/avian/), which is a small VM that can > run Java bytecode and has a very lightweight standard library with no > external dependencies except for a POSIX-ish environment and zlib. Also it > supports embedding the Java application code into its statically linked > binary so it does not need to load code from a filesystem. I hope that I am > on the right track in believing that this is a good candidate for > "rumpification", and I would appreciate your input about that. > > Also, I am hoping that you could tell me what are the general steps for > porting an application to use a rumpkernel? I've become a little lost with > where to get started in light of the recent refactoring of the repositories. > I'm not sure if the documentation has kept up with the changes so I thought I > should ask before diving in. If the answer to my question is RTFM, I > apologize in advance. The repo rototill was unfortunate, but it was necessary, since we didn't really fully understand the scope of things until recently. The rumprun repo provides a rump kernel based unikernel for various platforms. The name is sort of a mnemonic too: instead of running an application you rumprun it. It's the only repo you really need to care about if you want to [rump]run applications. If you're confused as to why the 1st edition of the book doesn't talk about rumprun, it hadn't been invented back then. As for porting, well, porting is sort of a naughty word around here. We explicitly want to avoid the situation where you need to *port* software to rumprun. Instead, POSIX software that is unikernel-compatible (*) should just work out of the box, give or take some adjustments that should be upstreamable. The current status is that you can more or less compile simple programs with "make" and run them with "rumprun". We're still trying to figure out a number of things, like the exact syntax of rumprun, how to build unikernels with >1 application (which doesn't directly fit into the paradigm where "make" produces a [rump]runnable binary), etc. For some of those problems there are ideas floating around, but reporting experimental data in the form of "i'm trying to run this application, i'm running^Wbumping into these problems" is extremely valuable for us now. *) we don't exactly know what that means yet, but something along the lines of "doesn't fork and exec all over the place and doesn't assume virtual memory" As for concrete instructions, start by looking at the various bits that Martin has been experimenting with, e.g.: https://github.com/mato/rump-nginx https://github.com/mato/rump-php You should more or less be able to apply the same steps to Avian JVM. We'd love to hear about your successes or failures in doing so. Also, anything you can contribute towards improve "TFM" (i.e. wiki) is much appreciated. Welcome! - antti
