咪啦网上线了！

公司的b2c门户咪啦网（www.5366.com）经过大伙一个多月的开发终于按当初的承诺时间于08年7月25号上线，可喜可贺啊！但一经发布公司内测，发现问题还是不少！首先在深圳总部访外网时，出现点击一些按钮没有反映，包括前后台都是相同情况，但在其他地方就没有这种情况发生，大家都觉得比较奇怪，问题现在还不能定位，初步判断那边网络设置可能有问题；其次最重要的就是性能问题，现在我们的首页有800k，正常的情况在400－500k之间算比较理想，我们的首页图片比较多，大概有一百张左右，每张图片大概3－4k，加上3个广告图片大约120k，这些加起来就快4－5百k了，然后还引用了一些第三方的js控件，算起来又有1－2百k了，这么大的一个首页访问起来肯定要慢了。图片在效果和大小权衡后基本定在3－4k之间，不能在压缩了，第三方的js还能有些压缩的空间，但压缩的情况也不是很理想，这个首页减肥是我们下阶段工作的一个重点。而在与服务器端交互的一些功能上，头要求我们每个请求处理时间至少要保持在100ms以内。通过对代码的详细跟踪后，发现主要耗费的时间还是在与数据库打交道的过程中，一个最简单select语句大约需要30ms，由于我们在dao层使用的是ibatis，sql语句执行都是预处理的方式，所以相同的数据库操作第二次执行时耗费的时间能减少50％。此处一些简单的业务逻辑执行耗费的时间仅占很少的一部分，所以我们的重点在sql语句优化以及ibatis的优化（在测试一个select的语句耗时时发现一个问题，在dao(ibatis)和manager(spring)层他们耗费的时间都是一样，为什么到action(webwokr)层时间就增加了1倍呢，不能理解，还要好好探讨一下！）。
以上都是说的数据库操作执行时间的问题，系统响应较慢还有一个主要问题，就是内存的消耗。我们控制层用的是webwork，它对每次请求都需要产生一个新的实例，从而避免了线程安全问题。但每次产生一个新实例，就需要分配一段内存，而它使用完事后，GC不能够及时回收掉，那么这样会耗费更多内存容量。我在用jprofile分析我们后台的时候看到一个现象，我们的共用分页代码在后台运行后，居然分配了100多个相同对象，而GC并没有实时对那些闲置的对象进行回收，这样造成严重的资源浪费（关于struts1的单态线程不安全和struts2以及webwork的多实例线程安全问题现在还没有很好理解，一定要看一下他们得源码把问题搞明白）。
希望在下一步的工作中，都能把以上的问题圆满的解决掉。只有在不断的困难挑战下，人才能不断的进步。