Magma & Multiple Cores

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Magma & Multiple Cores

Udo Schneider
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

_______________________________________________
Magma mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/magma
Reply | Threaded
Open this post in threaded view
|

Re: Magma & Multiple Cores

Chris Muller-3
Hi Udo,

> 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?

No, your understanding is correct.

You may also consider, that if the application truly is strictly
read-only (in terms of clients), then you can open multiple images on
one single copy of the database, each with a _local_ connection.  To
do that, the best practice is to make a #fullBackup of the repository
and host that copy read-only.

However, if you need updates then the HA approach is the right way to do it.

> 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.

Yep, that's how it works.  Please see the comment in
MagmaNode>>#anySecondaryLocation for more information about how
secondary locations can be chosen.   :)

> Am I making things much too complicated?

No, but I would ask whether you've looked at the #statistics of your
MagmaSession clients and determined that they are, in fact, waiting on
the server?  A server usually can handle several active MagmaSession
clients, and maybe that's what each of your web-servers is doing;
employing enough MagmaSession clients to saturate the server.  If that
is the case, then HA configuration will help.

 - Chris
_______________________________________________
Magma mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/magma