Re: Hessian Serialization Performance...

On May 2, 2005, at 10:09 AM, Gursel KOCA wrote:

>  
> Hi,
>  
>    Currently , we are developping an enterprise application that would
> have nearly 5000 clients.Since our application requires complicated
> screen , we choose swing , rich client approach.
>    Our EJB's are stateless, and we are using Toplink as persistence
> engine. Swing clients communicates with EJB's via RMI. As known by
> everybody, java default serialization mechanism is both
>     space and cpu consuming. For example , one of our most used domain
> object , when it is serialized it takes about 25-40 kb. Our client's
> network bandwidth is limited. Therefore , I have tried to find another
> solution . instead of java default serialization. I have found Hessian
> protocol. It was very promising, I have thought but my problem had
> been solved. But after a simle test, it seems that Hessian protocol is
> worse than default serialization mechanism. Hessian serialization
> creates 50-70 kb file for our most used domain object. For a simle
> domain object like ProcolTest.TestData, it creates smaller file than
> default serialization, the ratio is about 2.5. But when we increase
> number of serialization , the performance of Hessian degrades
> comparing to default .

Hessian should be more verbose and probably a bit slower than Java
serialization. (I'm not sure if the serialization should be slower,
but it would certainly be a bit more verbose.)

When serializing an object, Hessian always sends the field names and
also the object type. So it might look like

m t TestData
   S key S my-key
   S value S my-value
   z

m t TestData
   S key S a-second-key
   S value S some-more-data
   z

(m="map", t="type", S=string, z=end)

A more compact future Hessian 2.0 could avoid the repetition (and
probably save some time) by sending the object format only once.
Something like the following

o t TestData S key S value z
   S my-key
   S my-value

o r #1
   S a-second-key
   S some-more-data

(o=object, t=type, r=reference, S=string, z=end)

In other words, Hessian always sends the field names and type for each
instance. A future Hessian 2.0 could add the capability of caching the
object format. I think the implementation would be relatively
straightforward, actually.

That new capability should be approximately as compact as Java
serialization. I'm not sure what the performance would look like.
Certainly better than the current Hessian for lots of repeated objects.

(It would be possible to improve the compression more by adding new
tags like '0', '1', but it didn't seem to be worth the added
complexity.)

-- Scott

>  
> These are the test results.
>  
> Number Of Iteration    Hessian (ms)      Default (ms)
> 100                             15                    63
> 1000                            160                 160
> 10000                           875                 532
> 50000                           3860               2093
> 100000                          7687               4032       
>  
> The results for our complex domain object are worse ;
> Number Of Iteration    Hessian (ms)          Default (ms)
>  10                                 265                        110
> 100                                1500                       516
> 1000                               13140                    4360
>  
>  
>  
> Could somebody explain why hessian serialization performance is worse?
> . Is there anything wrong with my testcase?
>  
> Thanks in Advance...
>  
> Gursel Koca
>  
>  
>  
> Here is the test code,
>  
> public class ProtocolTest {
>     public static class TestData implements Serializable {
>        Long longField = new Long(10000);
>        Date dateField=new Date(System.currentTimeMillis());
>        String stringField = "Test String";
>        Double doubleField = new Double(2.334);
>      }
>
>  
>     
>   public void performanceTestOfSerializationWithSimpleObject() {
>       try {
>           int len = 1000;
>          ByteArrayOutputStream barr = new ByteArrayOutputStream();
>           ByteArrayOutputStream barr2 = new ByteArrayOutputStream();
>           TestData newIsemriPstn = new TestData();
>           ObjectOutputStream oout = new ObjectOutputStream(barr);
>           HessianOutput hout = new HessianOutput(barr2);
>           long begin = System.currentTimeMillis();
>           for (int i = 0; i < len; i++) {
>               oout.writeObject(newIsemriPstn);
>               barr = new ByteArrayOutputStream();
>               oout = new ObjectOutputStream(barr);
>           }
>           long end = System.currentTimeMillis();
>           System.out.println("Default Serialization takes
> "+(end-begin));
>           begin = end;
>           for (int i = 0; i < len; i++) {
>              hout.writeObject(newIsemriPstn);
>              barr2= new ByteArrayOutputStream();
>               hout = new HessianOutput(barr2);
>          }
>          end = System.currentTimeMillis();
>          System.out.println("Hessian Serialization takes
> "+(end-begin));
>       }
>       catch (Exception ex) {
>           ex.printStackTrace();
>        
>       }
>   }
>  
>    public static void main(String[] args) {
>         new
> ProtocolTest().performanceTestOfSerializationWithSimpleObject();
>     }
> }
>  
>  
>    
>  
>
> GIZLILIK NOTU
> Bu e-posta mesaji gizli, hassas bilgi ve/ya da ekler icerebilir. Bu
> mesaj, mesajin alici kisminda belirtilen kullanici/kullanicilara
> gonderilmistir. Eger mesaji yanlislikla almissaniz lutfen gondereni
> acilen bilgilendiriniz, mesaji ve tum kopyalarini siliniz.
> Bu mesaj bilinen tum viruslere karsi Symantec Antivirus ile
> taranmistir.
>  
> CONFIDENTIALITY NOTICE
> This email may contain confidential information and/or attachments.
> This email is intended for the use of the addressee only. If you
> receive this email by mistake, please advise the sender immediately
> and delete the email and any copies of it.
> This e-mail has been scanned by Symantec Antivirus for all known
> viruses.
Received on Mon 02 May 2005 16:05:21 -0700