- Pharo-users - lists.pharo.org

Re: [Pharo-users] real world pharo web application set ups

by Sven Van Caekenberghe

Mike, > On 17 Dec 2016, at 22:48, Michael J. Forster <mike(a)sharedlogic.ca> wrote: > > On 17 December 2016 at 14:09, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > [...] >> >> 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. >> > > > Hi Sven, > > No disagreement. I should clarify that, although I'm writing these > from my old email address, I'm not talking about a software > development company these days. I am now the analyst, programmer, and > system administrator for a long time client, and software is at the > heart of what we do, but we don't make money from it directly. We have > 2.2MLOC of Smalltalk, Common Lisp, Erlang, and PostgreSQL spread over > 30 systems, 20 databases, and 160 data entry terminals. Sounds quite familiar, real world stuff. > So, for example, while we need to sell concert tickets at an opening > peak of 10,000 seats in the first hour 10 times per year, and while we > deploy a dozen hardware-constrained gate admission nodes in a > distributed cluster that must validate up to 1000 tickets per second, > we also have some really complicated personnel scheduling and customer > reporting applications. The former really can't be done in anything > but Erlang where not just hardware but sysadmin cost is a factor. For > the latter, I wouldn't choose anything other than Pharo+Seaside--for > the same reasons you give. Yeah, such peaks are a special case indeed (having been on the buyer side end as well), I would not use Pharo in the direct path there either. > In a nutshell, we have, at times, startup/enterprise-class computing > problems and costs funded by small business revenue. > > Mike It would be interesting to hear more from your applications - please consider contributing a story to http://pharo.org/success - we need them. Thanks for this discussion. Sven

Dec. 18, 2016

Re: [Pharo-users] real world pharo web application set ups

by Michael J. Forster

On 17 December 2016 at 14:09, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: [...] > > 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. > Hi Sven, No disagreement. I should clarify that, although I'm writing these from my old email address, I'm not talking about a software development company these days. I am now the analyst, programmer, and system administrator for a long time client, and software is at the heart of what we do, but we don't make money from it directly. We have 2.2MLOC of Smalltalk, Common Lisp, Erlang, and PostgreSQL spread over 30 systems, 20 databases, and 160 data entry terminals. So, for example, while we need to sell concert tickets at an opening peak of 10,000 seats in the first hour 10 times per year, and while we deploy a dozen hardware-constrained gate admission nodes in a distributed cluster that must validate up to 1000 tickets per second, we also have some really complicated personnel scheduling and customer reporting applications. The former really can't be done in anything but Erlang where not just hardware but sysadmin cost is a factor. For the latter, I wouldn't choose anything other than Pharo+Seaside--for the same reasons you give. In a nutshell, we have, at times, startup/enterprise-class computing problems and costs funded by small business revenue. Mike

Dec. 17, 2016

Re: [Pharo-users] real world pharo web application set ups

by Sven Van Caekenberghe

> On 17 Dec 2016, at 19:39, Michael J. Forster <mike(a)sharedlogic.ca> wrote: > > On 16 December 2016 at 03:15, jtuchel(a)objektfabrik.de > <jtuchel(a)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

Dec. 17, 2016

Re: [Pharo-users] real world pharo web application set ups

by Michael J. Forster

On 16 December 2016 at 03:15, jtuchel(a)objektfabrik.de <jtuchel(a)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

Dec. 17, 2016

Re: [Pharo-users] Unscheduled outage for http://ss3.gemtalksystems.com/ and http://seaside.gemtalksystems.com/ss

by Dale Henrichs

sites are back on-line ... On 12/17/16 9:09 AM, Dale Henrichs wrote: > The colo where the hardware is located had announced scheduled > maintenance for our cluster, but there was not supposed to be any > downtime ... we are looking into the problem > > Dale >

Dec. 17, 2016

Re: [Pharo-users] [Vm-dev] ptsd rage

by Tudor Girba

Hi Robert, I am really sorry to hear your condition, and indeed, I hope you will find a remedy. Thank you very much for this email. I can imagine it was hard to write it. Cheers, Tudor > On Dec 17, 2016, at 2:57 AM, Robert Withers <robert.w.withers(a)gmail.com> wrote: > > I need to apologize for all my dread behavior. Here is the reason, and I am on service-connected disability. Current diagnosis is Complex PTSD. Sorry about all my sturm und drang. > > http://www.ptsd.va.gov/public/problems/anger-and-trauma.asp > > > Sincerely, > > Robert > -- www.tudorgirba.com www.feenk.com "Reasonable is what we are accustomed with."

Dec. 17, 2016

Re: [Pharo-users] [Stupid Benchmarks] C++ vs Pharo

by Dimitris Chloupis

no its not the loop i tried changing the computation and printing the sum the loops is definetly executed and I am also getting *time_spent=0.000001* ok this is insane but i found what is wrong with your code your loop is for (long i = 1; i <= 1000000000; ++i) but my loop is for (int i = 0; i <= 1000000000; ++i) no its not the long that causes the problem its the fact that you star counting from 1 no idea why but if you start counting from 0 it reports sensible numbers in the case of long sum = 0; for (long i = 0; i <= 1000000000; ++i) { sum = 0+i; } it reports the reasonable *time_spent=0.397446* so maybe its some optimisation it does when the counting starts from 1 not executing the loop in its entirety ? On Sat, Dec 17, 2016 at 6:33 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > On 17 Dec 2016, at 15:52, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> >> On 17 Dec 2016, at 15:23, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> >>> On 17 Dec 2016, at 14:28, Henrik Nergaard <henrik.nergaard(a)uia.no> wrote: >>> >>> This is not a comparable benchmark as the sum in Smalltalk keeps on growing and ends up doing LargeInteger calculations and thus the speed loss, while the c the int just rolls over. >>> >>> Sum in Smalltalk = 500000000500000000 >>> Sum in C = -1243309312 >> >> Yes, I realised afterwards. Shame on me. >> >> Now, in Pharo 64 bits: >> >> [ >> | sum | >> sum:= 0. >> 1 to: 1e9 do: [ :i | sum := sum + i ]. >> self assert: sum = (1e9 * (1e9 + 1) / 2) ] timeToRun. >> >> "0:00:00:03.379" >> >> (1e9 * (1e9 + 1) / 2) < SmallInteger maxVal. >> >> "true" >> >> So there the speed difference is way smaller. > > And here is a correct C99 version > > $ cat bench.c > #include <stdio.h> > #include <time.h> > #include <assert.h> > > int main() { > clock_t begin = clock(); > > long sum = 0; > for (int i = 1; i <= 1000000000; i++) > sum += i; > > assert(sum == ((1000000000*1000000001)/2)); > > clock_t end = clock(); > double time_spent = (double)(end - begin) / CLOCKS_PER_SEC; > printf("time_spent=%f\n", time_spent); > } > > prometheus:tmp sven$ ./a.out > time_spent=2.393986 But, $ cat bench.c #include <stdio.h> #include <time.h> #include <assert.h> int main() { clock_t begin = clock(); long sum = 0L; for (long i = 1; i <= 1000000000; i++) sum += i; assert(sum == ((1000000000L*1000000001L)/2L)); clock_t end = clock(); double time_spent = (double)(end - begin) / CLOCKS_PER_SEC; printf("time_spent=%f\n", time_spent); return (int)sum; } $ cc -O2 bench.c $ ./a.out time_spent=0.000002 Who knows what optimisation was applied ? Maybe the loop wasn't executed at all ... (but I did add the return statement). >>> Best regards, >>> Henrik >>> >>> -----Original Message----- >>> From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Sven Van Caekenberghe >>> Sent: Saturday, December 17, 2016 2:15 PM >>> To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> >>> Subject: Re: [Pharo-users] [Stupid Benchmarks] C++ vs Pharo >>> >>> Like this: >>> >>> [ | sum | sum:= 0. 1 to: 1e9 do: [ :i | sum := sum + i ]. sum ] timeToRun. >>> >>> "0:00:00:39.305" >>> >>> cat bench.c >>> >>> #include <stdio.h> >>> #include <time.h> >>> >>> int main() { >>> clock_t begin = clock(); >>> >>> int sum = 0; >>> for (int i = 0; i < 1000000000; i++) >>> sum += i; >>> >>> clock_t end = clock(); >>> double time_spent = (double)(end - begin) / CLOCKS_PER_SEC; >>> printf("time_spent=%f\n", time_spent); } >>> >>> ./a.out >>> >>> time_spent=2.370234 >>> >>> That is C being 16 times faster ... >>> >>>> On 17 Dec 2016, at 13:49, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>> >>>> Hmm, this sounds wrong (C++ should be (a lot) faster on such micro benchmarks). >>>> >>>> You should exclude the executable startup time. >>>> >>>> In Pharo you should do [ .. ] timeToRun and something similar in C/C++. >>>> >>>>> On 17 Dec 2016, at 13:41, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: >>>>> >>>>> in multiplication pharo is around 2 times slower compared to C++ >>>>> >>>>> #include <stdio.h> >>>>> >>>>> int main() >>>>> { >>>>> double x=1; >>>>> for(double i; i<1000000000 ; ++i) >>>>> { >>>>> x = 0.1*i; >>>>> } >>>>> >>>>> return 1; >>>>> } >>>>> >>>>> time ./testMul >>>>> 3.13 real 3.13 user 0.00 sys >>>>> >>>>> time ./pharo Ephestos.image eval "|x| x := 1. 1 to: 1000000000 do:[:each| x := 0.1 * each]" >>>>> 1 >>>>> 4.97 real 4.48 user 0.09 sys >>>>> >>>>> On Sat, Dec 17, 2016 at 2:16 PM Dimitris Chloupis < kilon.alios(a)gmail.com> wrote: >>>>> So I was bored and decided to test how fast pharo is compared to C++. >>>>> >>>>> so I tested addition >>>>> >>>>> C++ version: >>>>> >>>>> #include <stdio.h> >>>>> >>>>> int main() >>>>> { >>>>> double x=0; >>>>> while(x<1000000000) >>>>> { >>>>> x = x+1; >>>>> } >>>>> >>>>> return 1; >>>>> } >>>>> >>>>> time ./test1 >>>>> 2.84 real 2.84 user 0.00 sys >>>>> >>>>> Pharo version: >>>>> >>>>> time ./pharo Ephestos.image eval "|x| x := 0. 1 to: 1000000000 do:[:each| x := x +1]" >>>>> 1 >>>>> 2.09 real 1.94 user 0.08 sys >>>>> >>>>> Pharo is +50% faster than C++ ... o_O ... that's suprising, I assume here Pharo VM probably does some kind of optimisation.

Dec. 17, 2016

Unscheduled outage for http://ss3.gemtalksystems.com/ and http://seaside.gemtalksystems.com/ss

by Dale Henrichs

The colo where the hardware is located had announced scheduled maintenance for our cluster, but there was not supposed to be any downtime ... we are looking into the problem Dale

Dec. 17, 2016

Re: [Pharo-users] How to edit an element with Teapot

by stepharong

Hi sven so I studied your code and I got a solution working. Tx for your support. Now I do not know if what I did is correct. registerRoutes teapot GET: '/' -> '<h1>My game collection</h1>'; output: #html; GET: '/games' -> [ :reg | (self htmlListFor: self games)]; output: #html; GET: '/findDetails/<title>' -> [ :req | collector findMatchingTitle: (req at: #title) ]; output: #json; GET: '/find/<title>' -> [ :req | TeaResponse ok body: (self htmlListFor: (collector findMatchingTitle: (req at: #title))) ]; output: #html; GET: '/add' -> [ :req | self edit: req ]; GET: '/create' -> (Send message: #create: to: self) So I used /add to enter the parameter and pass them to the /create page. in the /create I created the new item and I could redirect to game list (I imagine that this is possible). So now I see tht I could merge add and create into a single page (as you did) and edit: request | title page | title := 'Enter a title'. page := ZnHtmlOutputStream streamContents: [ :html | html page: 'Create game named' do: [ html tag: #form attributes: #(#action 'create' 'accept-charset' 'utf-8' #method #GET) do: [ html str: 'Title'; space; tag: #input attributes: {#type. #input. #name. #input. #value. title}; space; tag: #input attributes: #(#type #submit) ] ] ]. ^ ZnResponse new statusLine: ZnStatusLine ok; entity: (ZnEntity html: page); yourself create: aRequest collector addGame: (GameItem new title: (aRequest at: #input)). ^ ZnResponse new statusLine: ZnStatusLine ok; entity: (ZnEntity html: 'Created!'); yourself

Dec. 17, 2016

Re: [Pharo-users] [Stupid Benchmarks] C++ vs Pharo

by Sven Van Caekenberghe

> On 17 Dec 2016, at 15:52, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> >> On 17 Dec 2016, at 15:23, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> >>> On 17 Dec 2016, at 14:28, Henrik Nergaard <henrik.nergaard(a)uia.no> wrote: >>> >>> This is not a comparable benchmark as the sum in Smalltalk keeps on growing and ends up doing LargeInteger calculations and thus the speed loss, while the c the int just rolls over. >>> >>> Sum in Smalltalk = 500000000500000000 >>> Sum in C = -1243309312 >> >> Yes, I realised afterwards. Shame on me. >> >> Now, in Pharo 64 bits: >> >> [ >> | sum | >> sum:= 0. >> 1 to: 1e9 do: [ :i | sum := sum + i ]. >> self assert: sum = (1e9 * (1e9 + 1) / 2) ] timeToRun. >> >> "0:00:00:03.379" >> >> (1e9 * (1e9 + 1) / 2) < SmallInteger maxVal. >> >> "true" >> >> So there the speed difference is way smaller. > > And here is a correct C99 version > > $ cat bench.c > #include <stdio.h> > #include <time.h> > #include <assert.h> > > int main() { > clock_t begin = clock(); > > long sum = 0; > for (int i = 1; i <= 1000000000; i++) > sum += i; > > assert(sum == ((1000000000*1000000001)/2)); > > clock_t end = clock(); > double time_spent = (double)(end - begin) / CLOCKS_PER_SEC; > printf("time_spent=%f\n", time_spent); > } > > prometheus:tmp sven$ ./a.out > time_spent=2.393986 But, $ cat bench.c #include <stdio.h> #include <time.h> #include <assert.h> int main() { clock_t begin = clock(); long sum = 0L; for (long i = 1; i <= 1000000000; i++) sum += i; assert(sum == ((1000000000L*1000000001L)/2L)); clock_t end = clock(); double time_spent = (double)(end - begin) / CLOCKS_PER_SEC; printf("time_spent=%f\n", time_spent); return (int)sum; } $ cc -O2 bench.c $ ./a.out time_spent=0.000002 Who knows what optimisation was applied ? Maybe the loop wasn't executed at all ... (but I did add the return statement). >>> Best regards, >>> Henrik >>> >>> -----Original Message----- >>> From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Sven Van Caekenberghe >>> Sent: Saturday, December 17, 2016 2:15 PM >>> To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> >>> Subject: Re: [Pharo-users] [Stupid Benchmarks] C++ vs Pharo >>> >>> Like this: >>> >>> [ | sum | sum:= 0. 1 to: 1e9 do: [ :i | sum := sum + i ]. sum ] timeToRun. >>> >>> "0:00:00:39.305" >>> >>> cat bench.c >>> >>> #include <stdio.h> >>> #include <time.h> >>> >>> int main() { >>> clock_t begin = clock(); >>> >>> int sum = 0; >>> for (int i = 0; i < 1000000000; i++) >>> sum += i; >>> >>> clock_t end = clock(); >>> double time_spent = (double)(end - begin) / CLOCKS_PER_SEC; >>> printf("time_spent=%f\n", time_spent); } >>> >>> ./a.out >>> >>> time_spent=2.370234 >>> >>> That is C being 16 times faster ... >>> >>>> On 17 Dec 2016, at 13:49, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>> >>>> Hmm, this sounds wrong (C++ should be (a lot) faster on such micro benchmarks). >>>> >>>> You should exclude the executable startup time. >>>> >>>> In Pharo you should do [ .. ] timeToRun and something similar in C/C++. >>>> >>>>> On 17 Dec 2016, at 13:41, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: >>>>> >>>>> in multiplication pharo is around 2 times slower compared to C++ >>>>> >>>>> #include <stdio.h> >>>>> >>>>> int main() >>>>> { >>>>> double x=1; >>>>> for(double i; i<1000000000 ; ++i) >>>>> { >>>>> x = 0.1*i; >>>>> } >>>>> >>>>> return 1; >>>>> } >>>>> >>>>> time ./testMul >>>>> 3.13 real 3.13 user 0.00 sys >>>>> >>>>> time ./pharo Ephestos.image eval "|x| x := 1. 1 to: 1000000000 do:[:each| x := 0.1 * each]" >>>>> 1 >>>>> 4.97 real 4.48 user 0.09 sys >>>>> >>>>> On Sat, Dec 17, 2016 at 2:16 PM Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: >>>>> So I was bored and decided to test how fast pharo is compared to C++. >>>>> >>>>> so I tested addition >>>>> >>>>> C++ version: >>>>> >>>>> #include <stdio.h> >>>>> >>>>> int main() >>>>> { >>>>> double x=0; >>>>> while(x<1000000000) >>>>> { >>>>> x = x+1; >>>>> } >>>>> >>>>> return 1; >>>>> } >>>>> >>>>> time ./test1 >>>>> 2.84 real 2.84 user 0.00 sys >>>>> >>>>> Pharo version: >>>>> >>>>> time ./pharo Ephestos.image eval "|x| x := 0. 1 to: 1000000000 do:[:each| x := x +1]" >>>>> 1 >>>>> 2.09 real 1.94 user 0.08 sys >>>>> >>>>> Pharo is +50% faster than C++ ... o_O ... that's suprising, I assume here Pharo VM probably does some kind of optimisation.

Dec. 17, 2016