Thank you for the clarifications and insights. Getting thoughts directly from the creator is always better than from any other source. Your comment on consistent and predictable memory usage is particular interesting, as I have noticed that although the event driven application environments don’t exhaust the available process or thread resources, they are particularly unpredictable when it comes to cpu and memory usage. Optimising apps to deal with that is hard, and I suspect there will be a whole new class of DDOS attacks that exploit that unpredictability to bring even the most capable event driven web servers to their knees. Any endpoint that performs mild computation or has any memory footprint is all that’s need.

SilkJS is great work, and it was refreshing to experiment with it.

Ian

When I wrote SIlkJS, I was not so much focused on the requests/second performance but concurrency. I was both surprised and pleased with the actual request/second results.

Initially, I ran ab tests against SilkJS to assure it could handle 2+ simultaneous requests. When I saw it do 2, then 10, then 50, then 5000 simultaneously, I just figured it was working pretty well.

When I saw that it was fast, I thought I’d compare against Apache. SilkJS is not as fast as Apache, but it’s pretty close (90%) for static content. For running business logic you’d do with Apache+PHP, SilkJS+V8/JavaScript is up to two orders of magnitude faster.

You mentioned many of SilkJS’s strengths. You wrote that SilkJS uses pthreads, which it doesn’t. It uses system processes via fork(), much the same way each tab in your browser is a separate system Process in Chrome. In a pthread application, a single thread can bring down the entire process (threads share the address space of the main program/process). SilkJS’s use of Processes allows any Process to die, get killed, crash, etc., and the other processes continue to run. Much like closing a tab in your browser, the other tabs continue to work.

A benefit of Processes you didn’t mention is garbage collection. The nature of V8 as a JavaScript engine is that it will choose to garbage collect freed variables and objects pretty much when it chooses. You can force a garbage collect to occur, which SilkJS does, and on a per Process basis. When one process is done serving all the keep-alive requests from a browser, it will garbage collect. Other Processes in other CPU cores will run just fine, the OS scheduler will allow a CPU core to part-time GC for one process and execute business logic for another, and so on. With a single threaded application, GC will kick in probably when you don’t want it to

As well, the SilkJS Processes will execute some predefined (configurable) number of requests from all sources/browsers and will then exit. The exit causes all memory used by V8 and your JavaScript code to be returned to the system. The other Processes continue to run, of course. The main program detects when a “child” process exits and spawns a new one to replace it. For these reasons, I believe memory usage for SilkJS may be more consistent and predictable.

I am a big fan of NodeJS. Where I think it excels is at massive numbers of long-lived connections like WebSockets or large file downloads. In production, though, I wouldn’t recommend either NodeJS or SilkJS or any other WWW server for static content. No matter how concurrent you can get NodeJS to be, a really big CDN is going to handle more connections and deliver content faster.

I’m a realist, though. Neither NodeJS nor SilkJS are going to cause major WWW sites like Yahoo! or Google or ESPN to junk their existing technology and rewrite it all in JavaScript. The trick is to figure out a place alongside that existing infrastructure to thrive, and I believe there’s room for both SilkJS and NodeJS.

Regards,
Michael Schwartz – Creator of SilkJS