Magma October 2010

magma@lists.squeakfoundation.org

4 participants
7 discussions

[ANN] ConfigurationOfMagma for Pharo 1.0, Pharo 1.1 and Pharo 1.2
by Miguel Enrique Cobá Martínez 08 Dec '10

08 Dec '10

Hi all, a new version of ConfigurationOfMagma is available for Pharo. Notes: Pharo 1.0 ---------------------- - 1.1r1 is the last versions that works in Pharo 1.0. This is because upstream Magma code depends on code that only exists on Pharo 1.1 and superior. - Pharo 1.0 uses Preferences to enable/disable the underscore as assigment in code. This release captures current value of this preference. Enables it for loading Magma and restores it to the original value after installing Magma. Pharo 1.1, Pharo 1.2 ---------------------- - The configuration for these Pharo releases is based on the one from Pharo 1.0. - 1.1r2 uses a new baseline because Magma has a new package dependency (Ma files additions). - Pharo 1.1 and superior uses Scanner allowUnderscoreAsAssignment instead of Preferences. The current value is captured and restored after installation of Magma. - Pharo 1.1 and superior doesn't include FlapTab class anymore. Magma adds some methods to it so the Configuration adds an empty class named FlapTab before installing and removes from the system after installing. This avoid a warning prompt when installing Magma. - This Configuration includes support for installing Magma releases previous to 1.1r2. Those versions should install correctly on Pharo 1.1 and greater but if a lot of problems are detected, the support for those old versions will be removed, and only 1.1r2 and newer versions will be supported. Now that Pharo has Universes, Magma has different ConfigurationOfMagma in each universe for Pharo. Each of those Configuration install the appropriate packages in Pharo. Installing Magma Pharo 1.0 --------------- Evaluate: Gofer new squeaksource: 'UniverseForPharo10'; package: 'ConfigurationOfMagma'; load. And then, one of: ConfigurationOfMagma project latestVersion load: 'Client'. ConfigurationOfMagma project latestVersion load: 'Server'. ConfigurationOfMagma project latestVersion load: 'Tester'. latestVersion is 1.1r1 Pharo 1.1 --------------- Evaluate: Gofer new squeaksource: 'UniverseForPharo11'; package: 'ConfigurationOfMagma'; load. And then, one of: ConfigurationOfMagma project latestVersion load: 'Client'. ConfigurationOfMagma project latestVersion load: 'Server'. ConfigurationOfMagma project latestVersion load: 'Tester'. latestVersion is 1.1r2 Pharo 1.2 --------------- Evaluate: Gofer new squeaksource: 'UniverseForPharo12'; package: 'ConfigurationOfMagma'; load. And then, one of: ConfigurationOfMagma project latestVersion load: 'Client'. ConfigurationOfMagma project latestVersion load: 'Server'. ConfigurationOfMagma project latestVersion load: 'Tester'. latestVersion is 1.1r2 Comments and bugs accepted. Enjoy. -- Miguel Cobá http://miguel.leugim.com.mx

4 4

Magma & Multiple Cores
by Udo Schneider 25 Oct '10

25 Oct '10

All, I'm currently thinking about how to scale a Magma based Seaside Application efficiently. As the majority of requests are read-only the idea of using Magma HA came to my mind ... thus a few points I'm not quite sure about. Multiple Magma Servers on one physical server: As Squeak/Pharo is not SMP-capable I was thinking of running one server image per physical CPU core on the DB Server. One of those images would host the primary while all other images would host read-only secondaries. As the requests are primarily read-only this should give (in theory) a more or less linear increase (with cores) in read performance ... or did I miss something? Local secondary server on Web frontend server: Given that the intended webserver machines are quad core I was thinking of running three seaside images + one secondary magma image on them. The idea is that a local read-only replica should be much faster to query than over the network. However I'm not even sure if it is possible for a MagmaClient to configure preferred servers. My current thinking is start a remote MagmaSession against the locally running (secondary) Magma server image. My understanding is that all read requests are handled by this server then - only write requests will be sent to the primary. Am I making things much too complicated? Best Regards, Udo

2 1

Looking for real-world Magma application
by Igor Stasenko 21 Oct '10

21 Oct '10

Hello all, sorry for cross-posting. :) I'd like to ask you, if anyone could share either an image or installation with application, which using Magma OODB. I'd like to use it & test how changing different aspects of Magma internals could affect the performance. There's many tricks, which is known by Chris how to speed it up by cleverly fine-tuning various Magma options, like read strategy etc. But what i'd like is to see, is some setup, used by people, and by taking it, see how it could make run faster, without changing an application code. I remember, someone gave a talk @ ESUG, that they were using Magma for their application, but then forced to switch to another DB layer, because they had bad performance issues. It would be good, if you could give me the code, so i can run it and see if things could be improved. Its not a problem, if code is not open-source, we could sign an NDA, if this is necessary. I need something real, simply because benchmarks sometimes not representative. :) -- Best regards, Igor Stasenko AKA sig.

1 0

Range Queries fail for MaSearchStringIndex when using Umlauts
by Udo Schneider 15 Oct '10

15 Oct '10

All, I'm currently using Magma to perform a prefix search on City names. I found out that this fails if the string contains umlauts or, to be more precise, if the last given char is not Ascii. E.g. myCollection where: [ :reader | reader read: #city from: 'Me' to: 'Me' maAlphabeticalNext] works fine. Changing the prefix to 'Mü' fails (no result). I assume that this is somehow connected to a) maAlphabeticalNext and b) the "allowed" characters for MaSearchStringIndex (BTW: #beAscii doesn't help here). I'm currently using MaByteSequenceIndex to circumvent the problem but I am not sure whether this is the intention. I attached a Testcase which shows the problem. Thanks, Udo

2 2

Memory problem
by Denis Kudriashov 13 Oct '10

13 Oct '10

Hello. I run some test in pharo1.1 and magma installed from configuration. I insert 100000 objects to local Magma db. I use MargaCollection for this. And after test I have grow memory size. Before I have 90 mb. After I have 140 mb. My code for test is: session commit: [entitiesGroup entities add: payment]. session stubOut: entitiesGroup. session finalizeOids. Smalltalk garbageCollect entitiesGroup entities is MagmaCollection. During test I see that "payment class allInstances size" don't changed. Its ok. I do stub/finalize stuff for this. But memory usage grow. Its bad. At the end of test I watch in MaWeakValueDictionary allInstances. And I found that some instance has 141000 items. And 140000 items is nil. (self select: [:each | each isNil] a MaWeakValueDictionary(size 140064)). This is my problem What I do wrong?

2 1

Fwd: Memory problem
by Igor Stasenko 11 Oct '10

11 Oct '10

On 11 October 2010 13:46, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hello. > > I run some test in pharo1.1 and magma installed from configuration. I insert > 100000 objects to local Magma db. > I use MargaCollection for this. > > And after test I have grow memory size. Before I have 90 mb. After I have > 140 mb. > > My code for test is: > > session commit: [entitiesGroup entities add: payment]. > session stubOut: entitiesGroup. > session finalizeOids. > Smalltalk garbageCollect > > entitiesGroup entities is MagmaCollection. > > During test I see that "payment class allInstances size" don't changed. Its > ok. I do stub/finalize stuff for this. > But memory usage grow. Its bad. > > At the end of test I watch in MaWeakValueDictionary allInstances. And I > found that some instance has 141000 items. And 140000 items is nil. > (self select: [:each | each isNil] a MaWeakValueDictionary(size 140064)). > > This is my problem > What I do wrong? > > If i remember correctly, there are a mechanism, which should clean it up periodically. But not too often , to prevent too much processing. > > > > > _______________________________________________ > Magma mailing list > Magma(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/magma > > -- Best regards, Igor Stasenko AKA sig.

2 1

CommitSafelly
by Denis Kudriashov 05 Oct '10

05 Oct '10

Hello, I attach method commitSafelly: aBlock for session. It's garanties that when commit block will failed transaction will aborted. Maybe some analogue already exists?

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Magma October 2010