- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Using ZnLogEvents to build a live updating requests per second monitor for an HTTP server

by Tudor Girba

Very nice example! Doru On Mon, Jun 16, 2014 at 5:29 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > Here is a concrete example of how cool object logging can be. In the > current development version, Zinc HTTP Components announces a number of > ZnLogEvent objects while either ZnClient or ZnServer operates. One of those > is ZnServerTransactionEvent, which signals the completion of a single HTTP > transaction (request/response pair) by the server. By subscribing to this > specific event through Zinc's Announcer, we can simply count the number of > transactions. If we report and reset this counter every second, we get a > rudimentary live updating requests per second monitor, in about ten lines > of code in a workspace ! > > Here is the setup: > > | transactionCount transactionsPerSecond | > transactionCount := 0. > transactionsPerSecond := 0 asValueHolder inspectWithLabel: 'HTTP req/s'. > ZnLogEvent announcer > when: ZnServerTransactionEvent > do: [ :each | transactionCount := transactionCount + 1 ] > for: #transactionCountDemo. > [ [ > 1 second asDelay wait. > transactionsPerSecond value: transactionCount. > transactionCount := 0 ] repeat ] > forkAt: Processor userBackgroundPriority > named: #transactionCountDemo. > > Then we start the server: > > ZnServer startDefaultOn: 8080. > > In a terminal, we use ab (the Apache Benchmark tool) to generate some load > on the server (10K requests for 1K random data, using 4 concurrent threads): > > $ ab -k -n 10240 -c 4 http://localhost:8080/random/1024 > > Here is a short 2 minute screencast showing this little demo in action (be > sure to select the HD version): > > https://www.youtube.com/watch?v=gaUxPNq6_7c > > It starts by showing how a AnnouncementSpy can be used to monitor the > server starting up and handling a single request - the logging from the > client is visible as well. The lines in the AnnouncementSpy are not just > text, but full, detailed objects. We inspect and explore the same > transaction from both the client and server perspective. > > Next is the demo of the live updating requests per second monitor with the > load described above. You can see that both our counter and ab report > approximately the same number: about 800-900 req/s. > > And finally, here is the cleanup code: > > ZnLogEvent announcer unsubscribe: #transactionCountDemo. > ZnServer stopDefault. > Process allInstances select: [ :each | each name = #transactionCountDemo ] > thenDo: #terminate. > > Note that by using other data elements in the ZnServerTransactionEvent we > could track bytes transferring in or out, rates of failure, slow requests > and so. There are lots of possibilities with object logging left to > explore, as well as lots to learn. > > Sven > > > -- www.tudorgirba.com "Every thing has its own flow"

June 16, 2014

Re: [Pharo-dev] strange difference between localhost and 127.0.0.1 with a Zinc server on mac

by Sven Van Caekenberghe

Thanks for the explanation, Eliot. I am not sure there is a problem resolving localhost and binding to it, as the server did work in the case described, it was just not accessible by curl. I guess we might have to shake down some issue with ipv6 in the future, we'll see. On 14 Jun 2014, at 16:17, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Sven, > > > On Sat, Jun 14, 2014 at 4:09 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 14 Jun 2014, at 12:18, Ben Coman <btc(a)openInWorld.com> wrote: > > > Sven Van Caekenberghe wrote: > >> In any case, the server socket used is normally listening on all interfaces [0.0.0.0] > >> > >> Sven > >> > >> > > > > Maybe it matters that [0.0.0.0] is the IPv4-Unspecified-Address > > and it might make a difference to use IPv6-Unspecified-Address [0:0:0:0:0:0:0:0] or [::] > > > > cheers -ben > > I guess it all depends on the Socket plugin. ZnServer has #bindingAddress: which eventually calls Socket>>#listenOn:backlogSize:interface: but the question is, what is acceptable as last argument. And how is the difference between v4 and v6 handled. There is a 'primitives-ipv6' category, but no #listenOn with an interface there. > > I wonder whether this commit is relevant: > > r2552 | eliot | 2012-05-02 16:13:02 -0700 (Wed, 02 May 2012) | 19 lines > > CogVM source as per VMMakerr.oscog-eem.159 > ... > > Fix limitation in platforms/unix/plugins/SocketPlugin/sqUnixSocket.c which could > cause NetNameResolver localHostAddress to answer 0 (if host has a set hostname > not being honoured by local DNS servers). Fix falls back to localhost. > ... > > Here's the relevant part of the platforms/unix/plugins/SocketPlugin/sqUnixSocket.c change: > > -sqInt sqResolverLocalAddress(void) { return nameToAddr(localHostName); } > +sqInt sqResolverLocalAddress(void) > +{ sqInt localaddr = nameToAddr(localHostName); > + if (!localaddr) > + localaddr = nameToAddr("localhost"); > + return localaddr; > +} > > This fixed several socket tests on my Mac OS box. I think it affects systems behind a broadband router, at least that's how it asffected me on my laptop at home. And here's what is probably the root cause in platforms/unix/plugins/SocketPlugin/sqUnixSocket.c: > > ... > static char localHostName[MAXHOSTNAMELEN]; > static u_long localHostAddress; /* GROSS IPv4 ASSUMPTION! */ > ... > /* start a new network session */ > > sqInt sqNetworkInit(sqInt resolverSemaIndex) > { > if (0 != thisNetSession) > return 0; /* already initialised */ > gethostname(localHostName, MAXHOSTNAMELEN); > localHostAddress= nameToAddr(localHostName); > thisNetSession= clock() + time(0); > if (0 == thisNetSession) > thisNetSession= 1; /* 0 => uninitialised */ > resolverSema= resolverSemaIndex; > return 0; > } > ... > and so if gethostname answers something weird, attempts to access localHost are screwed from initialization on. > > HTH > -- > best, > Eliot

June 16, 2014

Re: [Pharo-dev] [PROVENANCE INTERNET] Re: Brainstorming Pharo4

by Tudor Girba

I do :) Doru On Mon, Jun 16, 2014 at 4:35 PM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > > > Le 16/06/2014 16:24, Goubier Thierry a Ã©crit : > >> >> >> Le 16/06/2014 16:13, Esteban A. Maringolo a Ã©crit : >> >>> Add this to the wishlist: >>> >>> >>> - Scoped refactorings. Particularly method renames. I'd like to scope >>> the refactorings to class, hierarchy, package or global level. :) >>> >> >> I think it's already there :) >> >> Just need a way to use them. I may already have that, need to test >> (scoped system browser with refactorings coupled to the scope). Try >> scoped browsing with Nautilus and apply refactorings... >> > > And once you're in there, you can refine by cascading scopes. > > In package X, along hierarchy of class Y, find all methods with name > containing visit, rename #visitRootNode: as #acceptRootNode: > > Can also be combined with RB pattern matching for searching in code, but > I'd like to see the GUI for that last one :) Who was said to be working on > that? > > > Thierry > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > > -- www.tudorgirba.com "Every thing has its own flow"

June 16, 2014

Re: [Pharo-dev] New Cog & Spur VMs available

by Esteban Lorenzano

not yet On 16 Jun 2014, at 14:12, Pablo R. Digonzelli <pdigonzelli(a)gmail.com> wrote: > thanks!, a question is there a spur-format based image for pharo? > > TIA > > Ing. Pablo Digonzelli > Software Solutions > IP-Solutiones SRL > Metrotec SRL > 25 de Mayo 521 > Email: pdigonzelli(a)softsargentina.com > pdigonzelli(a)gmail.com > Cel: 5493815982714 > > De: "Eliot Miranda" <eliot.miranda(a)gmail.com> > Para: "Squeak Virtual Machine Development Discussion" <vm-dev(a)lists.squeakfoundation.org>, "The general-purpose Squeak developers list" <squeak-dev(a)lists.squeakfoundation.org>, "Discusses Development of Pharo" <pharo-dev(a)lists.pharo.org> > Enviados: Domingo, 15 de Junio 2014 21:58:04 > Asunto: [Pharo-dev] New Cog & Spur VMs available > > in http://www.mirandabanda.org/files/Cog/VM/VM.r3003/. > > Apologies for the non-Spur VMs in r3000 which should have had the "relocating call to invalid address" bug fixed but I made a mistake. It is fixed in 3003. > > Further, those who got crashes running the test suite due to the Aio tests should now find the VM does not crash. > > > CogVM source as per VMMaker.oscog-eem.774/r3003 > > Remember to regenerate the cogit.c's from the non-Spur configurations to fix the > "relocating call to invalid address" bug. > > Add a hack to link the XDisplayControlPlugin against vm-display-X11 (a hack > because it assumes paths etc). But at least the plugin works. > > Add an initial revision of platforms/unix/plugins/UUIDPlugin/acinclude.m4 to > search for uuid.h in either /usr/include/uuid or /usr/include and use either > uuidgenerate or uuidgen. > -- > best, > Eliot >

June 16, 2014

Re: [Pharo-dev] New Cog & Spur VMs available

by Pablo R. Digonzelli

thanks!, a question is there a spur-format based image for pharo? TIA Ing. Pablo Digonzelli Software Solutions IP-Solutiones SRL Metrotec SRL 25 de Mayo 521 Email: pdigonzelli(a)softsargentina.com pdigonzelli(a)gmail.com Cel: 5493815982714 ----- Mensaje original ----- De: "Eliot Miranda" <eliot.miranda(a)gmail.com> Para: "Squeak Virtual Machine Development Discussion" <vm-dev(a)lists.squeakfoundation.org>, "The general-purpose Squeak developers list" <squeak-dev(a)lists.squeakfoundation.org>, "Discusses Development of Pharo" <pharo-dev(a)lists.pharo.org> Enviados: Domingo, 15 de Junio 2014 21:58:04 Asunto: [Pharo-dev] New Cog & Spur VMs available in http://www.mirandabanda.org/files/Cog/VM/VM.r3003/ . Apologies for the non-Spur VMs in r3000 which should have had the "relocating call to invalid address" bug fixed but I made a mistake. It is fixed in 3003. Further, those who got crashes running the test suite due to the Aio tests should now find the VM does not crash. CogVM source as per VMMaker.oscog-eem.774/r3003 Remember to regenerate the cogit.c's from the non-Spur configurations to fix the "relocating call to invalid address" bug. Add a hack to link the XDisplayControlPlugin against vm-display-X11 (a hack because it assumes paths etc). But at least the plugin works. Add an initial revision of platforms/unix/plugins/UUIDPlugin/acinclude.m4 to search for uuid.h in either /usr/include/uuid or /usr/include and use either uuidgenerate or uuidgen. -- best, Eliot

June 16, 2014

Re: [Pharo-dev] Using ZnLogEvents to build a live updating requests per second monitor for an HTTP server

by Esteban A. Maringolo

This is really cool, and could enable live instrumentation for server health monitoring. Esteban A. Maringolo 2014-06-16 12:29 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > Hi, > > Here is a concrete example of how cool object logging can be. In the current development version, Zinc HTTP Components announces a number of ZnLogEvent objects while either ZnClient or ZnServer operates. One of those is ZnServerTransactionEvent, which signals the completion of a single HTTP transaction (request/response pair) by the server. By subscribing to this specific event through Zinc's Announcer, we can simply count the number of transactions. If we report and reset this counter every second, we get a rudimentary live updating requests per second monitor, in about ten lines of code in a workspace ! > > Here is the setup: > > | transactionCount transactionsPerSecond | > transactionCount := 0. > transactionsPerSecond := 0 asValueHolder inspectWithLabel: 'HTTP req/s'. > ZnLogEvent announcer > when: ZnServerTransactionEvent > do: [ :each | transactionCount := transactionCount + 1 ] > for: #transactionCountDemo. > [ [ > 1 second asDelay wait. > transactionsPerSecond value: transactionCount. > transactionCount := 0 ] repeat ] > forkAt: Processor userBackgroundPriority > named: #transactionCountDemo. > > Then we start the server: > > ZnServer startDefaultOn: 8080. > > In a terminal, we use ab (the Apache Benchmark tool) to generate some load on the server (10K requests for 1K random data, using 4 concurrent threads): > > $ ab -k -n 10240 -c 4 http://localhost:8080/random/1024 > > Here is a short 2 minute screencast showing this little demo in action (be sure to select the HD version): > > https://www.youtube.com/watch?v=gaUxPNq6_7c > > It starts by showing how a AnnouncementSpy can be used to monitor the server starting up and handling a single request - the logging from the client is visible as well. The lines in the AnnouncementSpy are not just text, but full, detailed objects. We inspect and explore the same transaction from both the client and server perspective. > > Next is the demo of the live updating requests per second monitor with the load described above. You can see that both our counter and ab report approximately the same number: about 800-900 req/s. > > And finally, here is the cleanup code: > > ZnLogEvent announcer unsubscribe: #transactionCountDemo. > ZnServer stopDefault. > Process allInstances select: [ :each | each name = #transactionCountDemo ] thenDo: #terminate. > > Note that by using other data elements in the ZnServerTransactionEvent we could track bytes transferring in or out, rates of failure, slow requests and so. There are lots of possibilities with object logging left to explore, as well as lots to learn. > > Sven > >

June 16, 2014

Re: [Pharo-dev] Vm on Mac OS 7.5 no cairo

by Stephan Eggermont

Uhm yes 10.7.5 of course. Opening the Roassal examples in a Moose image triggers the problem Stephan

June 16, 2014

Using ZnLogEvents to build a live updating requests per second monitor for an HTTP server

by Sven Van Caekenberghe

Hi, Here is a concrete example of how cool object logging can be. In the current development version, Zinc HTTP Components announces a number of ZnLogEvent objects while either ZnClient or ZnServer operates. One of those is ZnServerTransactionEvent, which signals the completion of a single HTTP transaction (request/response pair) by the server. By subscribing to this specific event through Zinc's Announcer, we can simply count the number of transactions. If we report and reset this counter every second, we get a rudimentary live updating requests per second monitor, in about ten lines of code in a workspace ! Here is the setup: | transactionCount transactionsPerSecond | transactionCount := 0. transactionsPerSecond := 0 asValueHolder inspectWithLabel: 'HTTP req/s'. ZnLogEvent announcer when: ZnServerTransactionEvent do: [ :each | transactionCount := transactionCount + 1 ] for: #transactionCountDemo. [ [ 1 second asDelay wait. transactionsPerSecond value: transactionCount. transactionCount := 0 ] repeat ] forkAt: Processor userBackgroundPriority named: #transactionCountDemo. Then we start the server: ZnServer startDefaultOn: 8080. In a terminal, we use ab (the Apache Benchmark tool) to generate some load on the server (10K requests for 1K random data, using 4 concurrent threads): $ ab -k -n 10240 -c 4 http://localhost:8080/random/1024 Here is a short 2 minute screencast showing this little demo in action (be sure to select the HD version): https://www.youtube.com/watch?v=gaUxPNq6_7c It starts by showing how a AnnouncementSpy can be used to monitor the server starting up and handling a single request - the logging from the client is visible as well. The lines in the AnnouncementSpy are not just text, but full, detailed objects. We inspect and explore the same transaction from both the client and server perspective. Next is the demo of the live updating requests per second monitor with the load described above. You can see that both our counter and ab report approximately the same number: about 800-900 req/s. And finally, here is the cleanup code: ZnLogEvent announcer unsubscribe: #transactionCountDemo. ZnServer stopDefault. Process allInstances select: [ :each | each name = #transactionCountDemo ] thenDo: #terminate. Note that by using other data elements in the ZnServerTransactionEvent we could track bytes transferring in or out, rates of failure, slow requests and so. There are lots of possibilities with object logging left to explore, as well as lots to learn. Sven

June 16, 2014

Re: [Pharo-dev] Brainstorming Pharo4

by ClÃ©ment Bera

2014-06-16 16:13 GMT+02:00 Esteban A. Maringolo <emaringolo(a)gmail.com>: > Add this to the wishlist: > > - Scoped refactorings. Particularly method renames. I'd like to scope > the refactorings to class, hierarchy, package or global level. :) > > This is already in the image. You can click on "browse scoped" in Nautilus and then all the refactorings are scoped into what you browse. Clement > > Esteban A. Maringolo > > > 2014-06-15 11:18 GMT-03:00 Serge Stinckwich <serge.stinckwich(a)gmail.com>: > > and copy-paste that in playground and CTRL-O will open the Browser ;-) > > > > On Sun, Jun 15, 2014 at 2:17 PM, stepharo <stepharo(a)free.fr> wrote: > >> Soon soon :) > >> but in this form > >> > >> MyClass>>myMethod > >> [ > >> ^ 1 + 3 > >> ] > >> > >> ;) > >> > >>> > >>> MyClass>>myMethod "in accessors" > >>> ^ 1 + 3 > >>> > >>> The current System Browser my also be switched to that method at the > same > >>> time, or a new System Browser opened if this is entered from > Workspace. I > >>> see some advantages for this for tutorials, where methods are presented > >>> using the ">>" convention, and readers might copy-paste the whole code. > >>> > >>> cheers -ben > >>> > >>> > >> > >> > > > > > > > > -- > > Serge Stinckwich > > UCBN & UMI UMMISCO 209 (IRD/UPMC) > > Every DSL ends up being Smalltalk > > http://www.doesnotunderstand.org/ > > > >

June 16, 2014

Re: [Pharo-dev] [PROVENANCE INTERNET] Re: Brainstorming Pharo4

by Goubier Thierry

Le 16/06/2014 16:24, Goubier Thierry a Ã©crit : > > > Le 16/06/2014 16:13, Esteban A. Maringolo a Ã©crit : >> Add this to the wishlist: >> >> - Scoped refactorings. Particularly method renames. I'd like to scope >> the refactorings to class, hierarchy, package or global level. :) > > I think it's already there :) > > Just need a way to use them. I may already have that, need to test > (scoped system browser with refactorings coupled to the scope). Try > scoped browsing with Nautilus and apply refactorings... And once you're in there, you can refine by cascading scopes. In package X, along hierarchy of class Y, find all methods with name containing visit, rename #visitRootNode: as #acceptRootNode: Can also be combined with RB pattern matching for searching in code, but I'd like to see the GUI for that last one :) Who was said to be working on that? Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

June 16, 2014