Thanks for sharing! I have create an issue for future investigations: https://github.com/akka/akka/issues/15784
/Patrik On Fri, Aug 22, 2014 at 12:31 PM, Sean Zhong <clock...@gmail.com> wrote: > In case, someone is also looking for the workaround, here is the hacked > implementation > > https://github.com/clockfly/akka_ShortActorRefProvider > > > On Saturday, August 9, 2014 5:03:19 PM UTC+8, Sean Zhong wrote: > >> Thanks, I hacked the RemoteActorRefProvider, and now be able to reduce to >> per message overhead to 34 byes(26 bytes are fixed overhead of wire format, >> not sure what it is). >> >> >> >> On Saturday, August 9, 2014 5:26:16 AM UTC+8, Kam Kasravi wrote: >> >> What was Endre's idea - is it related to URL shortening as discussed >> here? http://stackoverflow.com/questions/742013/how-to- >> code-a-url-shortener - ie using a bijective function? >> >> On Friday, August 8, 2014 6:18:24 AM UTC-7, Konrad Malawski wrote: >> >> Hi Sean, >> to summarise our thoughts about the on-the-wire overhead: >> >> * Viktor hinted at this technique: http://en.wikipedia.org/wiki/TCP_ >> acceleration which requires special hardware AFAIK, but is able to >> transparently compress data sent over TCP connections. It's probably costly >> but can be applied without app modifications. >> * We are aware of the large overhead and want to fix it soon – this will >> require changes in the remoting protocol, so it won't happen sooner than >> 2.4.x. The biggest part of the overhead is the ActorPath and Endre has >> suggested a neat "actor path shortening" trick which will save a lot of >> space on the wire for popular senders / receivers. >> * You could implement your own Transport (like our NettyTransport) and >> hook additional Gzip stages to the netty pipeline in there... This is quite >> some work but depending on your use-case perhaps it's worth it? In order to >> gzip to give anything here it would have to span multiple messages. >> >> Hope this helps! >> If your case is not strong enough for implementing this yourself you'll >> have to wait for our remoting updates which will address this problem (we >> totally agree the overhead is too big and will bring it down). >> >> >> On Fri, Aug 8, 2014 at 1:29 AM, Sean Zhong <cloc...@gmail.com> wrote: >> >> 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. >> >> >> Hi, Endre and Viktor, >> >> suppose I want to hack the wire format transport, which source file I >> should change? >> >> On Thursday, August 7, 2014 5:11:17 PM UTC+8, √ wrote: >> >> That would be completely outside of Akka. >> >> >> On Thu, Aug 7, 2014 at 11:01 AM, Sean Zhong <cloc...@gmail.com> wrote: >> >> compressed link/interface >> >> >> Is this configuration inside Akka conf? I cannot find the document, do >> you have pointer to this? >> >> >> On Thursday, August 7, 2014 4:58:05 PM UTC+8, √ wrote: >> >> Hi Sean, >> >> >> On Thu, Aug 7, 2014 at 10:49 AM, Sean Zhong <cloc...@gmail.com> wrote: >> >> Hi Viktor, >> >> About wire-compression, do you mean this? >> >> akka { >> remote { >> compression-scheme = "zlib" # Options: "zlib" (lzf to come), leave out >> for no compression >> zlib-compression-level = 6 # Options: 0-9 (1 being fastest and 9 being >> the most compressed), default is 6 >> } >> } >> >> >> >> No, that's from a legacy version of Akka. I mean using a compressed >> link/interface. >> >> >> Will it do compression at message level? or at a batch level(share same >> source machine and target machine)? >> >> >> >> Hi Endre, >> >> This is the Akka wire level envelope, cannot be directly controlled by >> users (unless someone writes a new transport of course). >> >> >> Which part of source code I can look at to write a new transport? >> >> >> >> >> >> >> On Thursday, August 7, 2014 4:22:16 PM UTC+8, √ wrote: >> >> You can do wire-level compression. >> >> >> On Thu, Aug 7, 2014 at 10:09 AM, Endre Varga <endre...@typesafe.com> >> wrote: >> >> >> >> >> On Thu, Aug 7, 2014 at 10:05 AM, √iktor Ҡlang <viktor...@gmail.com> >> wrote: >> >> Or add compression. >> >> >> This is the Akka wire level envelope, cannot be directly controlled by >> users (unless someone writes a new transport of course). >> >> -Endre >> >> >> On Aug 7, 2014 9:52 AM, "Endre Varga" <endre...@typesafe.com> wrote: >> >> 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 <cloc...@gmail.com> 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://app0executor0@192.168.1.53:51582/remote/akka.tcp/ >> 2120193a-e10b-474e-bccb-8ebc4b3a0247@192.168.1.53:48948/remo >> te/akka.tcp/cluster@192.168.1.54:43676/user/master/Worker1/a >> pp_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-5e26e >> 2ab080c-akka.actor.default-dispatcher-4] [akka.serialization.Serializat >> ion(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/t >> ree/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 <cloc...@gmail.com> 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/serializatio >> n.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 <cloc...@gmail.com> 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/c >> urrent/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 akka-user+...@googlegroups.com. >> To post to this group, send email to akka...@googlegroups.com. >> >> 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/c >> urrent/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 akka-user+...@googlegroups.com. >> To post to this group, send email to akka...@googlegroups.com. >> 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 >> >> <font style="margin:0px;padding:0px;border:0px;vertical-align: >> >> ... > > -- > >>>>>>>>>> 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 akka-user+unsubscr...@googlegroups.com. > To post to this group, send email to akka-user@googlegroups.com. > Visit this group at http://groups.google.com/group/akka-user. > For more options, visit https://groups.google.com/d/optout. > -- Patrik Nordwall Typesafe <http://typesafe.com/> - Reactive apps on the JVM Twitter: @patriknw -- >>>>>>>>>> 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 akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
