May I add that also, in my experience, materializing a graph is a very
costly operation performance-wise (if we're talking about 100/1000s of
materializations/s)?
Pre-fusing could help. There's a ticket open for fusing optimization.
I try to materialize as little as possible because it's the biggest
overhead compared to other reactive solutions (at least to the only one
I've ever used before in production, rx).
My choice between multiple graphs and a single parallel graph (with async
boundaries) would depend on the number of materializations per second as
well.
I personally had to completely avoid streams in my most load-intensive api
(one materialization per call kills performance) but I use them everywhere
else.
I pre-fuse everywhere I can but I still have a lot of "source factories",
i.e.: `def m(someParam: SomeType): Source[X, NotUsed] = ...`
I also have this pattern in database apis (e.g. slick): `def
getPeopleOlderThan(minAge: Int): Source[Person, NotUsed]`
Maybe after fusing optimization this would not be a problem anymore?
Sorry if I went OT but knowing how everyone handles their use cases could
lead to a nice discussion? We could open another thread if you think it's
worth it :)
Cheers
G
On Monday, 2 May 2016 08:56:18 UTC+2, Johan Andrén wrote:
>
> Hi Arun,
>
> There isn't really a right or wrong per se, it depends on what models your
> problem domain best. In some cases that will be one stream doing 10 things
> in parallell and in some cases it will be 10 separate streams doing things
> in parallell.
>
> If you expect to aggregate some information, if any of the operations on
> the streams should interact across the streams, or if one failure should
> fail all the streams that would be good reasons to choose one stream over
> many.
>
> Side note: I guess you included the sample graph just as an example, but
> if your graph is that simple there is no need at all to use the GraphDSL,
> just use the Flow API instead: 'Source(start to
> end).map(_.toString).to(Sink.foreach(x => println(s"$name: $x"))'
>
> --
> Johan Andrén
> Akka Team, Lightbend Inc.
>
> On Monday, April 25, 2016 at 7:08:40 PM UTC+2, Arun wrote:
>>
>> Hi,
>>
>> Need suggestion, I need to run parallel multiple source graphs, for
>> example I have created this sample code where I am creating 10 graphs and
>> running them parallel.
>>
>> Is this right approach or should I create multiple source inside a graph
>> and run them parallel in one graph?
>>
>>
>> def createGraph(start: Int, end: Int, name: String) = {
>> RunnableGraph.fromGraph(GraphDSL.create() {
>> implicit builder =>
>> import GraphDSL.Implicits._
>> val s = Source(start to end)
>> val f = Flow[Int].map[String](x => x.toString)
>> val sink = Sink.foreach[String](x => println(name + ":" + x))
>>
>> val t = builder.add(s)
>>
>> val flow1 = builder.add(f)
>>
>> t ~> flow1 ~> sink
>>
>> ClosedShape
>> })
>> }
>>
>>
>> (1 to 10).map(x => createGraph(x, x + 10, "g" + x)).map(_.run())
>>
>>
>> Thanks & Regards,
>>
>> Arun
>>
>>
--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ:
>>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups "Akka
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
