Thanks for the link. It was exactly about what I needed.
On 06/20/2015 04:06 AM, Luis Medina
wrote:
Oops, forgot to post the
link: https://www.parleys.com/tutorial/easy-scalability-akka
(you'll need to register a free account to view the ful
Jumping in a bit late, but one comment:
On Fri, Jun 19, 2015 at 1:38 PM, Guido Medina wrote:
> I do agree with Luis, but I wasn't pushing much that approach because
> AFAIK you are new to Akka and you have only one server, the concept of
> sharding and Akka persistence can be overwhelming at fir
Thank you Luis.
On Jun 20, 2015 4:06 AM, "Luis Medina" wrote:
> Oops, forgot to post the link:
> https://www.parleys.com/tutorial/easy-scalability-akka (you'll need to
> register a free account to view the full video).
>
> On Friday, June 19, 2015 at 4:36:05 PM UTC-7, Luis Medina wrote:
>>
>> I j
Oops, forgot to post the
link: https://www.parleys.com/tutorial/easy-scalability-akka (you'll need
to register a free account to view the full video).
On Friday, June 19, 2015 at 4:36:05 PM UTC-7, Luis Medina wrote:
>
> I just saw this really interesting presentation from Scala Days that
> Mart
I just saw this really interesting presentation from Scala Days that
Martynas posted in another thread that talks about scaling with Akka. I
think it will give you some ideas for how to design your app in a way that
scales even if you are starting out small right now.
On Thursday, June 18, 2015
You are right Guido, I never used Akka in production though I have
implemented several successful applications with Scala, Play and
ReactiveMongo. And there is a single server with 50K user at
maximum. Certainly, supporting more users and advanced scenarios
would be great
I do agree with Luis, but I wasn't pushing much that approach because AFAIK
you are new to Akka and you have only one server, the concept of sharding
and Akka persistence can be overwhelming at first, but if you read between
the lines, the hash code approach I proposed initially is the skeleton
Personally, I wouldn't organize your actors into "zones" since zones aren't
really a concept that would exist in your game and like you pointed out, it
can make scaling a bit tricky. The approach that I would take is to use
clustering along with sharding to distribute your actors across however
I completely agree with you. Thanks again :)
On 06/19/2015 06:47 PM, Guido Medina
wrote:
Trust me you don't want to do concurrency by
yourself even if you are an expert at it, asynchronous design is
the way to go, with Akka that concern is e
Trust me you don't want to do concurrency by yourself even if you are an
expert at it, asynchronous design is the way to go, with Akka that concern
is easy enough and you will be able to focus only on the business logic and
produce results, the last thing I'm going to Advice you is to not
under
These technologies and architectures are so appealing to me but I'm
still in doubt
whether I should follow these interesting approaches or just make a
traditional software (with a monolithic database-driven model).
Although this is a side project, it's very importan
And don't worry about performance, assuming each shard has a pattern of
Single Consumer - Multiple Producer, make sure the inbox type for shards
and players is SingleConsumerOnlyMailbox which is a the fastest Akka
mailbox atm.
On Friday, June 19, 2015 at 1:43:46 PM UTC+1, Guido Medina wrote:
>
If your number of shards is high enough and your hashcode is smart enough
coalitions should be very minimal, I think you should have stats of how
many players you have per shard and how busy shards get, and between
restarts *-maintenance time-*, redo your numbers and hashcode formulas,
otherwis
Yes that would be easy and scalable!
Just out of curiosity, what if a zone get too active? In another
world how can we have asymmetric zones so that we can balance zones
pressure by moving active players between them.
The first thing that comes to mind is that
Another option, if you don't have player ID but a sort of ID as string,
say, attach player "oxygen8", get the hash of that string and apply the
same formula, so you have 64 shards, so the supervisor of that player is
"oxygen8".hashCode() % 64
On Friday, June 19, 2015 at 1:01:00 PM UTC+1, Guido
Do you have player IDs? design your application to have zones divided by a
number -preferably a power of 2-, say, 64, now you have 64 evenly
distributed "shards" so to send a message to player ID = 1001 then you just
need to 1001 mod shards, no look up needed, it is just a convention you are
us
Yes it would be very nice. But I have no idea how to find a player
zone. Suppose player A want to attack player B. First we need to
find out the player B zone (to find it's supervisor). Right? Then we
need an actor which knows about the players zone. That would be the
bot
Nvm, that would run into the same problem, instead, eagerly load the
player's zone -a supervisor for a bunch of players- and then lazily load
the player per zone, that will keep your actors distributed and also will
prepare your code to use these zones as shards when the game grows.
On Friday,
You could even have the concept of lazily load the zone and each zone
lazily load the players.
On Friday, June 19, 2015 at 12:25:47 PM UTC+1, Guido Medina wrote:
>
> 50K is like zero for current and modern hardware, so, I would say, load
> them lazily from your players' supervisor and don't expi
50K is like zero for current and modern hardware, so, I would say, load
them lazily from your players' supervisor and don't expire them until you
start seeing a problem, expiring them would require you only to set context
time out at preStart() and then handle the timeout message which would be
You're absolutely right. I need at least one supervisor (or maybe
two; one for players and one for villages as they are top level
actors). This way I can deactivate and lazy load them as you said.
And yes I don't have millions of players :D but I hope some day I'll
;
Say you don't have zones or any sort of grouping, you need at least one
supervisor, I wouldn't recommend you to make all your players top level
actors where their parent is /user, you need a fast way to locate "a
player" and context().child(...) is such way IMHO, sharding with persistent
actor
Thanks Guido, this is good idea but as I'm not going to make this
game distributed (at least in the near future) I feel this approach
increases the complexity and I don't know what would I get instead
of this complexity? (except for RAM usage optimization)
The reason
I'd recommend you to look at Akka Persistence. You can store entitiy as
PersistentActor, and collect statistics by corresponding PersistentView.
Also, you can employ Cluster Sharding and use passivation to remove
inactive entities from RAM.
On Thursday, June 18, 2015 at 12:57:30 PM UTC+5, Amir
You can activate an actor if not present, as long as you send the message
to its supervisor, so you have to keep say, supervisors per zone? and each
supervisor will try to send/forward the message to such child and if not
present create it.
This is an example in Java where I do the same thing f
I think It's not enough. There are events which will happen when the user
is not logged in. For example an attack on a village (which its owner is
inactive) or occupation of that village also generates a message to the
owner player actor (which is not resident) as well. So I can't activate
them
You can set context time out for actors, if they don't receive a message
within some time passivate them, activate them at login, that way you don't
have to lazy load when the player is active but at login which will
basically happen asynchronously.
Now, Akka experts should tell us if setting c
27 matches
Mail list logo
