On 17 Dec 2016, at 19:39, Michael J. Forster <mike@sharedlogic.ca> wrote:
On 16 December 2016 at 03:15, jtuchel@objektfabrik.de <jtuchel@objektfabrik.de> wrote:
Sven,
Am 16.12.16 um 10:05 schrieb Sven Van Caekenberghe:
I did not say we are the fastest, for from it. I absolutely do not want to go into a contest, there is no point in doing so.
Absolutely right.
(The dw-bench page was meant to be generated dynamically on each request without caching, did you do that too ?).
My point was: Pharo is good enough for most web applications. The rest of the challenge is standard software architecture, design and development. I choose to do that in Pharo because I like it so much. It is perfectly fine by me that 99.xx % of the world makes other decisions, for whatever reason.
Exactly. Smalltalk and Seaside are perfectly suited for web applications and are not per se extremely slow or anything. Raw benchmarks are some indicator, but whether a web applicaton is fast or slow depends so much more on your applications' architecture than the underlying HTTP handling stuff.
The important question is not "how fast can Smalltalk serve a number of bytes?" but "how fast can your application do whatever is needed to put those bytes together?".
So your benchmarks show that Smalltalk can serve stuff more than fast enough for amost all situations (let's be honest, most of us will never have to server thousands of concurrent users - of course I hope I am wrong ;-) ). The rest is application architecture, infrastructure and avoiding stupid errors. Nothing Smalltalk specific.
Joachim
[...]
In our benchmarking and production experience, Pharo--even with Seaside--has fared well against Common Lisp, Java, Ruby, and Erlang web applications in terms of _page delivery speed_. Erlang positively embarrasses the others at handling concurrent requests, and it does so extremely cost-effectively in terms of hardware. Pharo (and Seaside) does likewise, at the other end of the spectrum, when developing sophisticated application workflow.
And that's the inflection point--a painful one--for us. To experience such effective time to market and maintenance, grow, and then trade it all to scale to 500+ concurrent users on a single t2.medium instance to keep hardware costs in check.
I think I understand your point, and in some specific situations that might be true. But if you can only afford to pay $35 a month for your hardware, how low must your income be ? Are you in a commercially viable enterprise then ? For a couple of $1000s you can get the equivalent of 10s if not up to 100 of those instances. And that is still much less than office rent, let alone 1 employee. The challenge today is not the cost of cloud hardware, it is simply building and operating your application. That is assuming you can sell it enough to make a living from it.
Mike