oberhamsi

3 ms·

1.
by oberhamsi 12y ago
modern browsers support webworkers so you get "threads" but still no shared memory.
2.
by oberhamsi 13y ago
ah! I didn't think of it like that. That would be interesting to see... at which concurrency level the environments crap out.
3.
by oberhamsi 13y ago
confusing but accurate :) The ability to script Java is one of Ringo's killer features - for this benchmark, for example, we dropped in two jars (JDBC myqlconnector & connection pooling from apachecommons) and glued them together with 1
4.
by oberhamsi 13y ago
I think he is too polite to say: "patch please"
5.
by oberhamsi 13y ago
I will test that. Should the latency stay more constant with higher concurrency? Or what am I searching for? Looking at the res/seq we got from round4. In order of concurrency (8, 16, 32, 64, 128, 256): nodejs (mongodb raw) 12,541 22,073 26
6.
by oberhamsi 13y ago
the source is available. as a first guess: if an ORM is the typical way to do it in an env then it was used.
7.
by oberhamsi 13y ago
If you split a single app instance onto 15 machines, you will lose some efficiency due to network communication unless those 15 instances can work isolated without any shared data (sessions). That may not be much but worst case: you have to
8.
by oberhamsi 13y ago
I implemented the Ringo app for this benchmark and of course ran it against Node and a couple of others to see how we would perform in this neighborhood before I opened the pull request. And since that day I've been wondering: why does Node
9.
by oberhamsi 13y ago
I think you ran into your own argument: if you are very read heavy (and lots of big sites are), it's all about caching and the DB becomes irrelevant. QED really hard to get right
10.
by oberhamsi 13y ago
Is there no php environment with a persistent server? Are they really all doing per request startup?
11.
by oberhamsi 13y ago
try our RingoJs: it's JS on the JVM. Scripting Java with JavaScript.