zoukankan      html  css  js  c++  java
  • 太过于依赖.NET默认的序列化机制

    当我们在应用中使用跨进程的缓存机制,例如分布式缓存memcached或者微软的AppFabric,此时数据被缓存在应用程序之外的进程中。每 次,当我们要把一些数据缓存起来的时候,缓存的API就会把数据首先序列化为字节的形式,然后把这些字节发送给缓存服务器去保存。同理,当我们在应用中要 再次使用缓存的数据的时候,缓存服务器就会将缓存的字节发送给应用程序,而缓存的客户端类库接受到这些字节之后就要进行反序列化的操作了,将之转换为我们 需要的数据对象。

    另外还有三点需要注意的就是:

    • 这个序列化与反序列化的机制都是发生在应用程序服务器上的,而缓存服务器只是负责保存而已。
    • .NET中的默认使用的序列化机制不是最优的,因为它要使用反射机制,而反射机制是是非常耗CPU的,特别是当我们缓存了比较复杂的数据对象的时候。

    基于这个问题,我们要自己选择一个比较好的序列化方法来尽可能的减少对CPU的使用。常用的方法就是让对象自己来实现ISerializable接口。

    首先我们来看看默认的序列化机制是怎么样的。如图3:

    然后,我们自己来实现ISerializable接口,如下图4所示:

    我们自己实现的方式与.NET默认的序列化机制的最大区别在于:没有使用反射。自己实现的这种方式速度可以是默认机制的上百倍。

    可能有人认为没有什么,不就是一个小小的序列化而已,有必要小题大做么?

    在开发一个高性能应用(例如,网站)而言,从架构,到代码的编写,以及后面的部署,每一个地方都需要优化。一个小问题,例如这个序列化的问题,初看 起来不是问题,如果我们站点应用的访问量是百万,千万,甚至更高级别的,而这些访问需要去获取一些公共的缓存的数据,这个之前所谓的小问题就不小了!

  • 相关阅读:
    第二冲刺阶段第一天
    spring第二冲刺阶段第八天
    spring第二冲刺阶段第七天
    spring第二冲刺阶段第六天
    spring第二冲刺阶段第五天
    spring冲刺第二阶段第四天
    spring第二阶段冲刺第三天
    spring冲刺第二阶段第二天
    SPRING冲刺第二阶段第一天
    spring第一冲刺阶段总结200zi
  • 原文地址:https://www.cnblogs.com/shihao/p/2450021.html
Copyright © 2011-2022 走看看