purplefox

5 ms·

1.
Tektite – Kafka/Flink Hybrid(tektitedb.com)
1 points by purplefox 2y ago|1 comments
2.
by purplefox 2y ago
Very excited to announce the release of a new open source project Tektite. Tektite allows you to create topics (like Kafka or RedPanda) but also do processing (like Flink) and lots of other cool stuff, but all in one database. It’s a real d
3.
by purplefox 13y ago
I haven't looked at this detail yet, but it should be noted that we haven't even optimised Vert.x yet so there should be plenty of scope for further improvement :) (Disclaimer: I'm the Vert.x project lead)
4.
Vert.x - the orgy of JVM langs continues with Python and CoffeeScript support(vertxproject.wordpress.com)
1 points by purplefox 14y ago|0 comments
5.
Vert.x 1.1.0.final is released(groups.google.com)
2 points by purplefox 14y ago|0 comments
6.
by purplefox 14y ago
The JVM does not doing any caching. And artificially crippling Vert.x to a single core does not prove anything. Anybody who cares about performance will be using more than one core.
7.
by purplefox 14y ago
I've tested several combinations of blocking, non blocking, readFile, streams (pipe) and using chunked transfer encoding. Results vary a little but all way below the Vert.x results. See blog post for the stats.
8.
by purplefox 14y ago
People have already got Vert.x running on OpenShift and Heroku, and CloudFoundry support shouldn't be too much longer.
9.
by purplefox 14y ago
Hopefully Scala won't be too long :)
10.
by purplefox 14y ago
+1. The system is in steady state, i.e. queues of requests/responses aren't growing. Therefore it doesn't actually matter if you count the requests or the responses.
11.
by purplefox 14y ago
The flaw in your argument is that the server is spending 80% of its time reading a file from disk. It's more than likely that it spends close to 0% of its time in disk access since its serving the same file, which will be cached by the OS i
12.
by purplefox 14y ago
Vert.x has a hybrid model. It has both event loops and a background thread pool, so you can choose which to run your task on depending on what kind of thing it is. E.g. it's stupid to run long running or blocking actions on an event loop.
13.
by purplefox 14y ago
It's labelled badly, what is actually measured is req/resp per second. I.e from request to corresponding response and how many of those it can do per second. If you doubt the numbers please feel free to run them yourselves, all code is in g
14.
by purplefox 14y ago
If you read the docs we specifically mention the "Fibonacci" farce. Vert.x (unlike node) does not force you to do everything on the event loop. It has a hybrid model. For things like long running calculations (e.g. Fibonacci) or calling blo
15.
by purplefox 14y ago
Agreed, it would be good to have CommonJS support. However, it's unlikely that node modules will work as is with Vert.x, since the API is different. (Unless someone writes a translation layer)
16.
by purplefox 14y ago
Yes indeed. You can mix and match Java, JavaScript, Ruby and Groovy in the same app. We hope to support more languages going ahead (e.g. Java, Scala, ...)
17.
Vert.x (JVM async) vs Node.js Http benchmarks results(vertxproject.wordpress.com)
151 points by purplefox 14y ago|118 comments
18.
Vert.x 1.0.final released. Polyglot async apps for the JVM.(vertxproject.wordpress.com)
1 points by purplefox 14y ago|1 comments
19.
by purplefox 14y ago
http://vertx.io/core_manual_js.html#serving-files-directly-d...
20.
by purplefox 14y ago
Yes, of course in a real web server you'd make sure you do the checks ;) The documentation actually mentions this point explicitly :)
21.
by purplefox 14y ago
Yes, I meant threads ;) E.g. A web server using node.js on a 32 core server. You would have to manually manage 32 instances of node, and use a load balancer or the cluster module in order to route requests to the instances. With vert.x you
22.
by purplefox 14y ago
If the wire protocol for the driver is published, then you can write a 100% async driver for it. I.e. no threads blocking, ever. In fact, I already did this for redis and vert.x (I will dig out the code for this some time). If you are deali
23.
by purplefox 14y ago
Yes, vert.x should work directly on Windows. I shall update the wiki accordingly :)
24.
by purplefox 14y ago
Fibers (or equivalent constructs) aren't supported by all the languages that Vert.x supports (e.g. Java) so we can't really support something like that until we can do it in all the langs. I know Fibers/Green threads are all the rage right
25.
by purplefox 14y ago
That's right. If you use the sendFile() method and you're on an OS that supports it, then the kernel will do the copying directly from file to socket for you. You can also serve files in the more conventional "node.js-style" way (i.e. pump
26.
by purplefox 14y ago
Works fine here: https://gist.github.com/2594983 Are you sure you're not looking at the github tags, rather than the downloads?
27.
Vert.x 1.0.beta10 released. Webapps in JS/Ruby/Groovy with no server side code(vertx.io)
1 points by purplefox 14y ago|0 comments
28.
by purplefox 14y ago
(Tim Fox here, project lead) The core api is similar to node.js, but that API is available in not just JavaScript, but in Ruby, Java and Groovy. Unlike node.js it also includes websockets and sockjs support and a distributed event bus so yo
29.
by purplefox 14y ago
If you think node.js is fast try http://vertx.io . It's like node but isn't single threaded so scales over multiple cores without having to fork. Also it's polyglot so you can don't have to use JS if you don't want. I'm hoping to publish s
30.
Vert.x - Scalable "real-time" web apps in JS, Ruby or Java. Now supports Groovy(vertx.io)
3 points by purplefox 14y ago|0 comments

More ›