Hi Sean, Unfortunately there is no way to reduce this overhead without changing the wire layer format, which we cannot do now. As you correctly see, practically all the overhead comes from the path of the destination and sender actor. In the future we have plans to implement a scheme which allows the sender to abbreviate the most common paths used to a single number, but this needs a new protocol.
So the answer currently is that you cannot reduce this overhead without introducing some batching scheme yourself: instead of sending MyMessage you can send Array[MyMessage], so the cost of the recipient path is only suffered once for the batch, but not for the individual messages -- i.e. you can amortize the overhead. -Endre On Thu, Aug 7, 2014 at 8:11 AM, Sean Zhong <[email protected]> wrote: > Is it possible to reduce the average message overhead? > > 200 bytes extra cost per remote message doesn't looks good... > > > On Thursday, August 7, 2014 1:45:12 PM UTC+8, Sean Zhong wrote: > >> Hi Michael, >> >> I used wireshark to capture the traffic. I found for each message >> sent(the message is sent with option noSender), there is an extra cost of >> ActorPath. >> >> For example, for the following msg example, message payload length length >> is 100 bytes(bold), but there is also a target actor path for 221 >> bytes(red), which is much bigger than message itself. >> Can the actorPath overhead cost be reduced? >> . >> >> akka.tcp://[email protected]:51582/remote/akka. >>> tcp/[email protected]: >>> 48948/remote/akka.tcp/[email protected]:43676/user/ >>> master/Worker1/app_0_executor_0/group_1_task_0#-768886794o >>> h >>> *1880512348131407402383073127833013356174562750285568666448502416582566533241241053122856142164774120* >>> : >> >> >> >> On Thursday, August 7, 2014 1:34:42 AM UTC+8, Michael Frank wrote: >>> >>> sean- how are you measuring your network thoroughput? does 140MB/s >>> include TCP, IP, ethernet header data? are you communicating across local >>> network or across the internet? the greater the distance your packets have >>> to travel (specifically the number of hops), the higher chance that they >>> will get dropped and retransmitted, or fragmented. a tool like Wireshark, >>> tcpdump, or ScaPy could help you differentiate utilization at different >>> protocol layers and also identify network instability. >>> >>> -Michael >>> >>> On 08/06/14 08:46, Sean Zhong wrote: >>> >>> Konrad, thanks. >>> >>> After enabling the debug flag, >>> >>> I saw the system message like Terminate are using javaSerialiaer, is >>> this expected? >>> >>> [DEBUG] [08/06/2014 22:19:11.836] [0e6fb647-7893-4328-a335- >>>> 5e26e2ab080c-akka.actor.default-dispatcher-4] [akka.serialization. >>>> Serialization(akka://0e6fb647-7893-4328-a335-5e26e2ab080c)] Using >>>> serializer[*akka.serialization.JavaSerializer*] for message >>>> [akka.dispatch.sysmsg.Terminate] >>>> >>> >>> Besides, as my message is String, I cannot find related serialization >>> log for type java.lang.String. How to know for sure protobuf is used for >>> String? >>> >>> Are you sure you’re not CPU or something else -bound? And you should >>>> be able to stuff the network? >>>> >>> >>> What I means is that 140MB/s network are occupied, but source message >>> throughput is only 60MB/s, so there are 80MB/s bandwidth I cannot explain. >>> >>> >>> On Wednesday, August 6, 2014 11:30:49 PM UTC+8, Konrad Malawski wrote: >>>> >>>> Hi Sean, >>>> >>>> On the wire: >>>> You can look into https://github.com/akka/akka/ >>>> tree/master/akka-remote/src/main/protobuf for what exactly we pass >>>> around on the wire. >>>> >>>> Which serializer is used: >>>> enable debug logging, we log this info in Serialization.scala >>>> log.debug("Using >>>> serializer[{}] for message [{}]", ser.getClass.getName, clazz.getName) >>>> >>>> Other hints: >>>> Are you sure you’re not CPU or something else -bound? And you should be >>>> able to stuff the network? >>>> Have you played around with the number of threads etc? >>>> What hardware are you benchmarking on? >>>> >>>> >>>> >>>> On Wed, Aug 6, 2014 at 5:19 PM, Sean Zhong <[email protected]> wrote: >>>> >>>>> Thanks, Konrad, >>>>> >>>>> >>>>> Are there other akka data/attributes attached to a remote sending >>>>> message? Or just? >>>>> serialized(msg) + actorRef >>>>> >>>>> Which part of akka source code I can check for answer? >>>>> >>>>> Besides, is there LOG flags I can enable so that I can check which >>>>> serilization framework is in effect? >>>>> >>>>> In my experiment, I cannot explain half network bandwitdh usage with >>>>> akka remote messaging. My message throughput is 60MB/s, but the network >>>>> bandwidth is 140MB/s. How can I trouble shooting this. >>>>> >>>>> >>>>> On Wednesday, August 6, 2014 7:53:39 PM UTC+8, Konrad Malawski wrote: >>>>> >>>>>> Hello Sean, >>>>>> actual overhead in terms of how many bytes – depends on your >>>>>> serialiser. >>>>>> >>>>>> 1) Yes, a message includes the sender. Not much optimisations in >>>>>> there currently, although we have nice ideas on what we can do within a >>>>>> cluster (short "handles" instead of full addresses), >>>>>> 2) Refer to: http://doc.akka.io/docs/akka/snapshot/scala/ >>>>>> serialization.html Strings are a byte array, the envelope is >>>>>> protobuf (you can find it in `akka-remote`), other kinds of payload is >>>>>> whatever you configured – defaults to java serialisation. >>>>>> 3) Of the entire message? It depends on your serialiser. >>>>>> >>>>>> Hope this helps, happy hakking :-) >>>>>> >>>>>> >>>>>> On Wed, Aug 6, 2014 at 1:43 PM, Sean Zhong <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Suppose I want to transfer a msg to another machine >>>>>>> >>>>>>> otherActor ! “hello" >>>>>>> >>>>>>> what is the wire message overhead? >>>>>>> >>>>>>> 1. the wire messge need to have information about ActorRef, will >>>>>>> the ActorRef be attached for every message, or will it be cached on >>>>>>> target >>>>>>> machine, so the sender only need to attach an Id? >>>>>>> 2. How string "hello" is serialized on the wire, with java >>>>>>> serialization? or protobuf? Can this be configured? >>>>>>> 3. What is other overhead for this message? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>>>>> 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 http://groups.google.com/group/akka-user. >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Cheers, >>>>>> Konrad 'ktoso' Malawski >>>>>> hAkker @ Typesafe >>>>>> >>>>>> <http://typesafe.com> >>>>>> >>>>> -- >>>>> >>>>>>>>>> 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 http://groups.google.com/group/akka-user. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> >>>> >>>> -- >>>> Cheers, >>>> Konrad 'ktoso' Malawski >>>> hAkker @ Typesafe >>>> >>>> <http://typesafe.com> >>>> >>> -- >>> >>>>>>>>>> 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 http://groups.google.com/group/akka-user. >>> For more options, visit https://groups.google.com/d/optout. >>> >>> >>> -- > >>>>>>>>>> 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 http://groups.google.com/group/akka-user. > For more options, visit https://groups.google.com/d/optout. > -- >>>>>>>>>> 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 http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
