Update req/sec benchmark with actual comparisons #1205
Comments
|
Deno performs at levels far below what modern software that's this overhyped should ever do. Old ancient versions of Node.js 0.8.x performs better or equal to new Node.js versions in IO, they did not perform this bad ever in history. Not even close. Ever. It's blatantly obvious something is horribly wrong the the design of Deno and if things don't start getting better very soon it's going to be locked down for the future. It's an architectual flaw in the very frame of Deno that needs to see significant and fundamental changes for this project to have any kind of relevance in a world where Golang is a thing. Deno is far below Apache-like performance from early 1990s. What's even the point of Deno?
|
|
Some info: #1003 |
|
So it's going to be lowered by yet another 50%? Is that the plan? |
|
@vcarl Do you have any motivation for that downvote of my post? What's bad in your view? You don't like scientific, historically correct measurements? If you're trying to point something out, I'm ready to read your text. I cannot read what a 👎 is supposed to mean. |
it's very premature to say this about a project that still has a long road ahead of it. and equally silly to claim that deno will never be able to perform as fast as Node - of course it will, it's built atop the same v8 as Node, plus Rust. it will certainly be capable of delivering at least Node-level performance when it's finished, so your FUD is just that. performance optimization is usually last thing that's done when the primary goal of a project isnt to win at benchmarks. no one has ever claimed a v8-based server can ever beat even Nginx; they cater to very different use-cases. nobody's choosing either Node or Nginx as a sole solution for one multi-faceted problem. EDIT: also, looking at your chart here [1], it's hard to believe that the battle-tested Nginx codebase leaves so much performance on the table vs μWS. are Nginx programmers really that terrible? Or is μWS cutting corners somewhere to win an i'm not trying to diminish your work, just saying that a single contrived throughput chart is not enough to illustrate the full scope of even just the performance aspect of any software. |
Off-topic, click to expandJust because you asked: the tone in certain parts of your posts isn't fun, and probably even repels some amount of capable performance-interested readers who are here to collaborate for fun. "below what modern software that's this overhyped should ever do", "is far below Apache-like performance from early 1990s. What's even the point of Deno?". It's hard to criticize tone in places like this. It usually de-rails conversations and invites new ones that no one actually wants, so in meatspace, people generally just gravitate to a different area of the room with different people, and online, people quietly downvote and move on. I'm not sure I want this conversation or that this is the place for it, but you asked, and I think a reply to me like this would have been useful to me in the past. I'm more interested in reading more about Deno performance. I do like the focus on measuring and improving performance. That's not the part I'd have downvoted. Of that post, I'm literally just criticizing the quoted parts. Sometimes when I come into a place where I'm better at a subject than others and problems exist, I get a little surprised and outraged that the place didn't already prioritize the subject higher, and I let some of that outrage shine through while I'm trying to communicate to others the improvements that ought to be made in that subject. At the time, it feels like it will make my point more motivating, or it feels like witty banter. (Generally for me, the subject is exploitable security vulnerabilities.) I'm pretty sure I've been off-putting in the past about that and burned some bridges, which I'm sorry about. (I wasn't the one to thumbs-down that post so obviously I can't speak for them, but I considered it and have thumbs-downed one or more of your previous posts here for the reasons above, so I speak for that.) |
Sorry to be direct, but your commentary has been very adversarial. It may not be intended that way, but that is the way it comes across. The way you are presenting your arguments are like a prophet who says the sky is falling. If you want to contribute to Deno, then I think there are far more constructive ways. Your commentary seems to indicate that some of your observations are not self evident to those working on Deno. I know personally that the team are very concerned about performance. Deno at this stage is an experiment. Ry had some theories to what would work for HTTP, but the performance didn't work. You basically have rubbished any thoughts and continued your "sky is falling" diatribe. You really devalue any contribution you are trying to make. |
|
@alexhultman, you're the only programmer I know who's famous for being angry. |
|
@leeoniya This post of yours is very ignorant and very classic for someone who has no idea about performance work and never done any of it. First off, V8-bindings exist and has been presented that very clearly demonstrate you can easily outperform NGINX, significantly many times over, from within V8. Second, every single project that's about performance starts out from the ground up with performance in mind. You can NEVER EVER achieve good performance of an entire stack of software as an afterthought. Performance characeristics are ESSENTIAL to the very fundamental design of the entire stack and is not something you can just "tweak" in the end of the project timeline. You can tweak it somewhat but not to such an fundamentally flawed degree Deno is in now. Node.js was from the very start essentially constant in IO performance. It has, as you can scientifically and historically prove, only somewhat degraded by time. It was the same from the start to the end, simply because the fundamental design has been the same and cannot change any more now. You talk about performance as if you have any kind of idea yet there's just copy-paste regurgitated nonsenseical bullshit that everyone who had no fucking idea about anything spews out. It's like the classic template response. |
|
Please keep the discussion professional. |
|
@leeoniya Reading your edit, you're now making the argument fallacy of "No true Scotsman". It's a classic fallacy you can find everywhere; https://en.wikipedia.org/wiki/No_true_Scotsman Basically, yes, NGINX is a market brand that is subject to commercial marketing. Guess what? Marketing is not reality. It's marketing. You expect Loreal face cream to actually make your skin 10 years younger too? Also, I'm not making any kind of case about me, you can take Lwan for example if you want some third-party proof. If you want more thorough comparison you can see this image thoroughly checking all sizes:
|
|
Maybe it's not exactly no true Scotsman but I have forgotten the name of the other thing. Something about a king. Anyways, it's still a stupid fucking thing to say. Point is, Deno is slow af. |
|
@kitsonk You're making the completely wrong assessment here. I criticize things, I'm not a socialist. Not looking to "contribute" other than to point out that Deno is on course for disaster. I don't mind disaster. Just saying, it's going to be a disaster unless someone puts in some kind of quality control.
Hahahaha, did you even see the graph? CLEARLY nobody cares the slightest around here. |
ok, it wasnt always just marketing. it was faster than Apache for a long time, and still is faster than Node. if i remember it was shown to be faster using the same types of throughput graphs and benchmarks done by third parties. anyways, ok. does a "slow" http implementation that can only do 25k req/s really matter in the context of having to execute almost-certainly sub-optimal business logic js code in v8? i mean if you're a CDN hosting static assets or serving from an in-memory cache, then maybe - but then why would you run a layer of v8? as soon as you need to hit a db or do anything beyond trivial logic, http speed will be far from the bottleneck. i imagine that an exceedingly small number of companies that actually see loads of 25k req/s are also starved by a slow http server (because at minium they're distributed and using an nginx or faster reverse proxy for serving static assets). i'm asking because i'm a genuinely curious idiot, not to continue an argument. where i work we don't even see loads of 100 req/s, and we do use nginx in front of node on a $40 linode vps that peaks at 20% cpu utilization and 10% ram use.
what's special about "now"? is there a deadline by which deno needs to be released? |
|
One can offer a pure typescript API like https://deno.land/x/net/http.ts, and later change the implementation (without changing the API) to use tighter v8 bindings, perhaps even similar to uws. The http API is not wedded to typescript, or hyper. At the moment it's 113 LOC (kinda)!
Everyone is in agreement here, it is essential performance is vastly improved. The disagreement seems to be whether there is value in releasing a POC http server that isn't as performant as node. You seem to be asserting that this is locking us down to a slow implementation and demonstrates an architectural flaw in deno. I don't buy it. (Perhaps I am misconstruing your point and this is a https://en.wikipedia.org/wiki/Straw_man?) |
I would say that your input is not welcome here. Please go criticise somewhere else. |
|
Not really how the internet works, of you publicly publish things they are subject to open criticism. Well, unless we're taking North Korea kind of internet. Anyways, you have the numbers and know what to do. I'll come back in a few months and keep doing my finger pointing. If you don't like that you should probably get off the internet. |
I had once doubted the need for community standards. It is attitudes like this that demonstrate why such things are needed. There is a difference between being critical and being critical and insulting. Insulting criticism is almost never universally welcomed. You presume too much about my personal ability to take criticism. It is a fallacy though to believe you can say whatever you want on the internet anyway you want to. |
|
If you don't want input from people who disagree with you (which is known in democratic societies as free speech and/or discussion) then don't hang around a publicly published 30k-something GitHub repo. You are going to find people who disagree with you on the internet. You can go unplug your Ethernet and live like that if you find that more settling. It's as simple as that. |
|
@alexhultman I hate arguing with others and I do agree that optimizations is really important, but I have to say your words are a bit too strong to @kitsonk . Especially considering you said that you don’t want input from others who disagrees with you before in #162 yourself.
If you really care about specific optimization strategies, you could make a PR yourself. If you think there is no way you are bound to this project so you would not contribute, then please do not badger other contributors and Ryan as Deno slowly make progress. As you know, there was a fire in California recent days. Simply shouting at the firefighters does not help. Especially now this fire is not burning down your house in Sweden. |
|
Wow! My post all the way back from June 6th perfectly predicted the exact performance outcome of Deno! Man, I told you all so long ago and now we stand here knee deep in shit. Just like I said way back then. I'm proud! 👏 👏 to me |
|
I'm all for having frank discussions about perf - but not in this way. I've banned this user. Note that #726 is open. |
|
There are now comparisons on the website. Yes, deno is still slow (addressing this is important and a 1.0 blocker). |
|
@pirix-gh It got much better than when this issue is opened. Kind of waiting for the upstream Tokio 0.3 to stabilize. They have implemented a much better scheduler in their alpha preview |
With deno 0.2.0 I can get the Http server from denoland/net working enough to benchmark it.
This means we can finally show and track accurate numbers comparing apples to apples in that req/sec benchmark graph.
Performance loss is major, so current numbers are completely misleading, esp. since what is essentially "deno_tcp" is named "deno" which misrepresents "node" numbers. This because it's not obvious one needs to compare "deno" with "node_tcp" to get apples to apples.
Rename "deno" to "deno_tcp", add an actual http server using denoland/net and have it named "deno".
The text was updated successfully, but these errors were encountered: