6 ms·
The author of Nginx on why V8 is not suitable for web servers
- baguasquirrel 15y agoIt's scary what you can do with machine translation these days...
- flipp 15y agoSeriously.. I didn't even realize that was a translation till I finished the first paragraph.
- DrJ 15y agothat or we have bad grammar sentences, sometimes.
- igorlev 15y agoNot only is the translation of a surprisingly high quality, but reading the original in Russian is more awkward since a lot of the technical terms are originally English. I needed to read a particular portion 3 times before I realized it meant memory allocation.
- rdtsc 15y agoI though the same thing. I learned all the tech terms in English, so when I read "sborka musora" instead of "garbage collection" it somehow makes me smile.
- Klinky 15y agoHaha, I thought your reply was talking about how the V8 engine worked(translating to machine specific code), instead of the language translator used on the blog post.
- spicyj 15y agoFunny how it changed: for (int i = 0; v8::V8::IdleNotification() && i < 3; i++); to: for (int i = 0; v8:: V8:: IdleNotification () & & i <3; i + +);
- naner 15y agoIt likely was not completely translated by machine. Google Translate lets anyone reading the translation edit it to fix errors. Highlight some text and notice the link that appears allowing you to "Contribute a better translation" for that particular passage.
- Sephr 15y agoIt's more likely that it only helps train Google Translate, and doesn't actually apply any changes directly to the translated text. Otherwise vandalism would be way too easy.
- Pooter 15y agoRight. I noticed a small translation error in the first paragraph. The Russian word "машина" - in the paraphrased Henry Ford quote - is translated as machine, but in the context of the sentence should be translated as "car." When I corrected it, the old one was left in place.
- merloen 15y agoWhy on earth is the comment by Pooter dead?
- alastairpat 15y agoI thought exactly the same thing! I still remember being able to play a game with one of my friends where we'd translate a sentence to German then back to English and laugh at how mangled it was…
- freakwit 15y agohttp://www.translationparty.com/#9269521 http://www.translationparty.com/#9269521
- pixdamix 15y agoAfter a bunch of English/Japanese translations: "Number of games: We, and I have learned how to use the means for translating the German text in English is still a way of encoding their friends to play with a smile. .."
- coffeemug 15y agoThat's incredible. When I read the article I didn't realize I'm reading google translated version, so I thought "Igor's english is a bit broken but relatively good". I only realized I read a translation when you pointed it out. I went back to re-read the original (I'm a native russian speaker) and it's amazing how close google got to expressing the essence of every sentence.
- gtdminh 15y agoreally good translation. i'm not aware google translate has this progress.
- ma2rten 15y agoTechnical texts like this are relatively easy to get right. English is not my native language and when I was young I could read computer related stuff, but had trouble understanding, for example Harry Potter. If Google has an example of such a text, they can learn all the translations for all the technical terms from that data. However, a news article is much more difficult because they often have lot's of metaphors, etc. If you try to translate those, you get a lot of halve finished sentences and stuff like that.
- JunkDNA 15y agoYeah, I actually found it so good it was distracting. After every sentence I kept going back and saying, "Wow, I can't believe it got that right too".
- wazoox 15y agoIndeed. However though Google translate quite correctly from most common languages to English, translation to other languages (even English to French or English to Spanish) often hardly makes any sense.
- lloeki 15y agoThe thing that led me to it was halfway through, when I moved the cursor on top of the text and there was some popup, at which point I yelled, WTH is that crap site with some broken JS advertising! I moved the mouse away but kept moving it in by pure reflex. It took me a whole minute to realize it was Google Translate. Before I actually noticed that, "snapshot'ov" actually made me laughed, genuinely (mis)taking it for some sort of pun.
- deleted 15y ago[deleted]
- daeken 15y agoWhile an interesting article in its own right, it has nothing to do with node.js, except that this happens to be a criticism of the way V8 works, which node.js is built on. However, they may not be using things in the same way he is, or there could be mitigating circumstances which make it possible for node.js to pull this off. (I don't know anything about node.js internals, I just know this article isn't about it, as the title indicates.) Edit: This was written when the title was "The author of Nginx on node.js and why V8 is not suitable for web servers". It's since been changed.
- knowtheory 15y agoI disagree. Where V8 can run is a core part of the deployment surface of node.js, so what server authors think about V8 and it's suitability for integration and deployment very much matter to node.js. Remember, 'does rails scale'? :|
- daeken 15y agoEven if every one of these issues applies to node.js, this article is not "on node.js". The title is incorrect, no matter what.
- xer0x 15y agoAgreed. The title is totally trolling for attention. Nginx and Nodejs are very different. Nodejs was built on V8 from the beginning, while it would have to be grafted into Nginx somehow. Nodejs isn't Chrome but it's willing to pretend that it is - nginx isn't.
- deleted 15y ago[deleted]
- hanszeir 15y agoThe title is a copy from a Reddit posting. I thought about changing it. Node.js is build on top of V8. It is better to get attention from Node.js experts so that others can get a clearer picture. Updated: Never mind, someone just change the title for me. The original title is "The author of Nginx on node.js and why V8 is not suitable for web servers.".
- Klinky 15y agoIt sounds like more of the concern is that V8 is/was buggy & had some situations where performance would be compromised. I don't think it's a slam saying it could never be used.
- mythz 15y agoWhen Igor speaks, I listen.
- rhasson 15y agoit's a great write up and the context issue seems interesting, however it's from Feb 2010 according to the last paragraph and a lot has changed in V8 since
- sassafras 15y agoAs I'm sure others will point out, this article has less to do with node.js as it does with embedding v8 in Nginx. Although since node.js runs in v8, I suppose you could interpret it that way.
- glesperance 15y agoThe state of todays base of node (v8) has nothing to do with the concept/paradigm its trying to put forward -- that is event driven web apps. Hence, one must not discard node as a bad solution only because v8 is not optimal in all situations. Everything is always a work in progress.
- shadowsun7 15y agoA thought: why not have node developers fork V8, and modify that to make it ready for server deployment? Has the coreteam and/or Dahl thought about this?
- cageface 15y agoThat could mean taking on a lot of extra work. One of the big selling points of Node is that it leverages all the work Google puts into V8.
- stewars 15y agoNode does not create a new V8 context for each request so the 2ms => max 500 requests per second scaling problem does not exist with Node.
- cagenut 15y agoThese only sound like problems if you need to keep it single process. If you break out the javascript interpreter via fastcgi workers just like people do with php on nginx it becomes mostly moot points right? At that point its limited to 500 req/sec/core, but frankly these days that means 4000 req/s, which, hell, I'll take it. Granted thats assuming you can actually run a fastcgi/v8 setup, I've never looked. I wonder how hard a mod_v8 for apache prefork would be.
- aidenn0 15y agoah yes, but then you aren't embedding v8 into nginx
- EGreg 15y agoSysoev brings up a couple good points that affect Node.js . 1) The fact memory allocation might crash the process is a serious problem. Is this still the case? 2) The fact that garbage collection is still stop-the-world may be a problem for server availability. Are we able to call the generational collector from node, or no? Things that don't involve node: The ability to create multiple objects in different contexts. Sysoev is thinking of the "scripting" model, like PHP, which is not how Node does things. Node just runs one process to handle thousands of requests, not thousands of processes or threads. There is no need.
- EGreg 15y agoupvotes are great :) But does anyone know the answers to 1) and 2)?
- ballard 15y agoNode.js is often used because it is cool, new and easier for front-end developers to develop a functioning backend. For more traditional uses that want something less hackish, erlang for example, crashes only a single thread not the entire vm. Functional programming languages in general like haskell and erlang are interesting for backend core services.
- daleharvey 15y agomemory allocation failures crash the erlang vm
- ballard 15y agoNode.js is often used because it is cool, new and easier for front-end developers to develop a functioning backend. For more traditional uses that want something less hackish, erlang for example, crashes only a single thread not the entire vm. Functional programming languages in general like haskell and erlang are interesting for backend core services.
- bengtan 15y agoHmmm... I read this title as 'The author of Nginx on why (Nginx) V8 is not suitable for web servers' and I'm thinking ... huh? Does someone want to change the title to be clearer?
- wrs 15y agoAt Microsoft, I watched (from afar) the incredibly painful multi-year process of making a complex language runtime intended for one environment (.NET for IIS) satisfy the requirements of a very different environment (SQL Server). When fundamental design assumptions like "memory allocation failures can kill the process" have to change, it's a big deal. Seems like process isolation a la fastcgi is the practical way to go, unless the V8 team itself wants V8 to be embeddable in a "reliable" way (meaning, it recovers from its own errors without corrupting the process it's embedded in).
- olegp 15y agoA lot of the points raised are an issue only for long running processes. Akshell (http://www.akshell.com http://www.akshell.com), for example, has synchronous I/O libraries and uses an Apache MPM like model, so for us the limits are less of a concern.
- JulianMorrison 15y agoIIRC, on Linux at least the memory allocation thing is moot. If your process runs out of memory, it dies anyway. You can't catch "malloc says no" because malloc never says no. It either says yes or blows your process's brains out.
- imurray 15y ago"malloc never says no" malloc says no if you set a ulimit in your shell. I do this on the desktop to stop myself from shooting myself in the foot. (Recent kernels also let you turn off the overcommitting behavior.)
- adobriyan 15y agoRecent is 2.6.11+ which is 6 years old.
- koenigdavidmj 15y agoNote to self: do not leave root terminal behind xlock, since I have no guarantee that xlock will stay around.
- ErikCorry 15y agoSpeaking only for myself as ever: Handling out of memory errors is a hard problem. At the point when you can't allocate more memory you are busted in most languages. For example in C a slightly deeper function call depth can cause the stack to expand at any point. If that point coincides with you running out of memory then you are busted. No program can keep running with a broken stack. If V8 were capable of recovering from out-of-memory errors then you would still have to go through all of node and all the native libraries that it uses and check that they can handle any allocation failing. And if V8 handled out-of-memory errors with exceptions then you have two choices. Either make the exceptions uncatchable, in which case the JS program running in the server has no way to recover and is probably in an inconsistent state. Or make the exceptions catchable, in which case there is no guarantee that any memory will ever be freed up and you are back to square one. I think it's possible to make V8 more resistant to out of memory situations. I don't think it's possible to make it bulletproof, and I don't think there are many server apps that have this property. Do people run Java servers in such a way that they are often getting out of memory exceptions, recovering, and then continuing to serve? I don't think so. In practice the way most servers work is that you give them plenty of memory and you write your server app in such a way that it does not use unlimited memory. If there are non-out-of-memory errors that V8 is failing to recover from then these are bugs and should be reported. I can't think of any examples off-hand. As far as the other comments go they seem to assume that you will want to use a V8 context per connection. Node uses one V8 context for all connections, so the comments don't apply. Context creation has been speeded up a lot since the article was written, but this is only for the browser. Node doesn't need it.
- JoachimSchipper 15y agoYou're being too clever - if you run out of memory, throw away the request and all associated resources and return "500: Internal server error". There are lots of reasons why this isn't perfect (if the OS overcommits memory, like Linux (typically?) does, it will have to kill you to avoid running out; if you need to use swap you're too slow to be useful; etc), but it's not impossible. node.js (one process for many requests) is a different model than the author is considering; no matter its (dis)advantages, integrating it into the server is not nearly as advantageous as for a process-per-request model (like mod_php).
- jorangreef 15y agoLikewise, Nginx is not suitable as a reverse proxy for streaming web servers, since Nginx proxies HTTP 1.0 not HTTP 1.1.
- piotrSikora 15y agoNoone is denying that. But what's the point of bringing that up here?
- mraleph 15y agoRight title for this 2 years old article is "Why V8 is not suitable for nginx". He has his own set of requirements which by no means applies to _all_ webservers.
- ma2rten 15y agoThat might as well be the best Google Translate translation I ever read.
- gtdminh 15y agoin russian : Почему Google V8 пока не подходит для встраивания в серверы in english : Why is Google V8 is not suitable for integration into servers. There is a word "integration" that the author of the post forgot to put in.
- nivertech 15y agoПочему Google V8 пока не подходит для встраивания в серверы in english : Why is Google V8 is not yet suitable for integration into servers.
- VladRussian 15y agoi'd say "for embedding"
- nivertech 15y agomy point was about "yet", though you are right about "embedding" (it wasn't my translation).
- VB6_Foreverr 15y agoMaybe it's just me but every time I see V8 i think it's VB
- IgorSysoev 15y agoThe title is "Why V8 is not suitable for EMBEDDING in servers".
- delinka 15y agoI keep seeing these replies on how well Google Translate performed. I didn't realize while reading that it was machine-translated, but my immediate thought was "this person is not a native English speaker or needs much work his attempt at Yoda-speak does."
- seats 15y agoBut still understandable, so that's a success I'd say. I remember when nginx first came out (the web server that the author built) and the biggest barrier to adoption was the fact that all the documentation was in russian. Online machine translation did not produce understandable content at that time.