I don't know how "mainstream" solutions perform on AWS Lambda or EC2,
but this seems really fast to me. 50 ms is great, assuming it bills by
every 100ms, you still have room to perform your computation.
Thank you for pursuing this path, it could open a new territory for
using Pharo at big scale.
Esteban A. Maringolo
2017-07-17 8:32 GMT-03:00 Tim Mackinnon <tim@testit.works>:
> Well I’ve been shooting in the dark a bit - but I also left out the sound
> and display so’s (e.g. -x execlude the following and add back the null so's
>
> zip -r --symlinks ../deploy/$LAMBDA_NAME.zip * -x pharo-local/\* \*.sources
> \*.changes \*.st \*.log
> */libgit2.* */libSDL2* */B3DAccelerator* */JPEGRead* */vm-sound*
> */vm-display* tmp/\* */__MACOSX\*
> - zip -uR ../deploy/$LAMBDA_NAME.zip *-null.so
>
>
> And everything seems to run clean. (Would be useful to get some feedback
> from those in the know - does just leaving out so’s incurred a penalty if
> you don’t recompile the VM? Presumably something would get written to std
> error or pharodebug if it was an issue).
>
> In fact my run times on EC2 are pretty impressive:
>
> PharoLambdaMin]$ time ./pharo Pharo.image exec "Lambda processJSON: '{}'"
> {"outputSpeech":{"text":"Good Morning, it's eleven
> twenty-six","type":"PlainText"},"shouldEndSession":true,"card":{"content":"Operation
> Successful","title":"Pharo Lambda","type":"Simple"}}
>
> real 0m0.039s
> user 0m0.028s
> sys 0m0.000s
> [ec2-user@ip-172-31-44-73 PharoLambdaMin]$ time ./pharo Pharo.image exec
> "Lambda processJSON: '{}'"
> {"outputSpeech":{"text":"Good Morning, it's eleven
> twenty-six","type":"PlainText"},"shouldEndSession":true,"card":{"content":"Operation
> Successful","title":"Pharo Lambda","type":"Simple"}}
>
> real 0m0.039s
> user 0m0.020s
> sys 0m0.008s
>
>
> Not bad eh?
>
> Tim
>
> On 17 Jul 2017, at 07:00, Tim Mackinnon <tim@testit.works> wrote:
>
> Thanks again Pavel - I'll try the 6.0 step 4 or possibly step 5 with sunit
> (as many libraries don't separate out their tests).
>
> I've also tried leaving out libgit and libsdl2 .so's on my server build and
> that seems fine too - making me wonder what others I can safely leave out?
> Sound is a candidate (but small fry in size but do you need the null
> variant?).
>
> Libcrypto is big - but I wonder if https routines would use that (and it
> sounds server processing'y so maybe best left).
>
> I was hoping to find a list explaining them somewhere - but it remains
> rather mysterious.
>
> However, at this point, I think I may have hit the sweet spot in size where
> AWS seems to load efficiently below a zip of 10mb?
>
> Tim
>
> Sent from my iPhone
>
> On 15 Jul 2017, at 09:35, Pavel Krivanek <pavel.kriva...@gmail.com> wrote:
>
> If you want to stay with Pharo 6 image, you can try the bootstrapped version
> of the minimal image:
> https://ci.inria.fr/pharo/view/6.0-SysConf/job/Pharo-6.0-Step-04-01-ConfigurationOfMinimalPharo/
>
> -- Pavel
>
> 2017-07-15 10:33 GMT+02:00 Pavel Krivanek <pavel.kriva...@gmail.com>:
>>
>> Try the Pharo 7 metacello image (=Pharo 7 minimal image that the CI is
>> already converting to 64bit). There should be no problem with STON because
>> whole Pharo is loaded into it using metacello and filetree. Pharo 6 minimal
>> image is done differently (by shrinking) and not so well tested.
>>
>> For the conversion of 32-bit image to 64-bit image you need a VMMaker
>> image:
>>
>> https://ci.inria.fr/pharo/job/Spur-Git-Tracker/lastSuccessfulBuild/artifact/vmmaker-image.zip
>> and then evaluate:
>> ./pharo generator.image eval "[Spur32to64BitBootstrap new bootstrapImage:
>> 'conversion.image'] on: AssertionFailure do: [ :fail | fail resumeUnchecked:
>> nil ]"
>>
>> -- Pavel
>>
>>
>>
>> 2017-07-15 10:19 GMT+02:00 Tim Mackinnon <tim@testit.works>:
>>>
>>> Hi Pavel - thanks for getting me to the point where I could even have a
>>> minimal image. As I’m on the edge of my Pharo knowledge here, I’ll try and
>>> run with this as best I can.
>>>
>>> I’d been using the 6.0 image you suggested to me - but maybe I could use
>>> a 70 image with Pharo 6 for a while (until the VM diverges) right?
>>>
>>> The bit I haven’t quite understood however, is how the 64bit image is
>>> created - as your reference is to a 32bit version? Is the 64bit one
>>> converted from 32 in a later stage? (For AWS Lambda I need 64bit) - am I
>>> right in thinking the pipeline stage after this one is the one you sent me -
>>> and the travis.yml file shows me what it does? But I can’t see a trivis.yml
>>> in the conversion stage so I’m not sure how it does that. (Question - how do
>>> I see what the pipelines do to answer my own questions?)
>>>
>>> I was hoping that there was a basic image that got me up to metacello
>>> baseline level to load git file tree packages/baselines in my own repo as
>>> well baselines on the internet. The one you sent me is fairly close to that
>>> (its just missing STON in the image and seems to have an issue with
>>> resolving undeclared classes that get loaded in - should do a fogbugz on
>>> that?)
>>>
>>> The follow-on from a metacello image is how we can get people to create
>>> better baselines that give you more minimal loading options (e.g.
>>> conditionally leave out the test cases perhaps)
>>>
>>> Tim
>>>
>>> On 15 Jul 2017, at 08:24, Pavel Krivanek <pavel.kriva...@gmail.com>
>>> wrote:
>>>
>>> Hi Tim,
>>>
>>> you can base the your work on the bootstrapped image, see
>>> https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap-32bit/, file
>>> Pharo7.0-core-*.zip
>>>
>>> This image does not have a lot of basic components like Monticello or
>>> network but it has a compiler so the code can be imported as *.st files.
>>> Then we have Pharo7.0-monticello-*.zip which will be easier to use and
>>> probably can fit your needs. Monticello and network support are included.
>>> But you cannot use baselines nor configurations to load your code.
>>>
>>> -- Pavel
>>>
>>> 2017-07-14 9:59 GMT+02:00 Tim Mackinnon <tim@testit.works>:
>>>>
>>>> Hi - buoyed by the success of a minimal image (thanks Pavel), I'm
>>>> wondering if I can get even smaller.
>>>>
>>>> There are lots of .so's in the vm which wouldn't make sense on a server
>>>> once deployed - sound, maybe libgit ...
>>>>
>>>> Is there a list of the essential ones, or tips on what I can strip out
>>>> of the Linux deployment? I also recall that i can leave out .sources and
>>>> .changes as well right?
>>>>
>>>> Tim
>>>>
>>>> Sent from my iPhone
>>>>
>>>
>>>
>>
>
>
