On 16 December 2016 at 03:15, jtuc...@objektfabrik.de <jtuc...@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. Mike
