web service设计中的性能问题

SOA架构已经成为很多系统的架构选择，在基于SOA架构的系统的编程开发中，可以从以下三个点来关注性能问题。

1 web service的调用。
众所周知，web service的调用中，网络上的时间消耗是一个比较大的部分。这里有两个可以注意的地方。soap消息的大小，标准的soap消息以是xml文档的形式传送的，而一个重型的web service的结果可以达到几十甚至更大，可以考虑用压缩后的形式传送比较大的soap消息。web service的调用频率，在一次业务中，有可能调用同一个系统多次web service，可以考虑设计一些重型的service来减少调用次数。

2 业务逻辑编程时的考量
一般来说，代码中的性能bug会比较少，但是，质量很差的代码一样有可能是性能杀手。对关键系统的代码一定要做性能测试，以便尽早发现低质量的代码。

3 数据库优化
数据库访问一直是性能杀手，对数据库的优化应该持续的测量与改进。加索引，分表，加缓存等等任何常见的优化措施都有可能对性能有一个大的提升。

4 对ws约定的理解
很多时候大家都忘了性能同样是ws的一个约定。只不过是隐含的。
一个ws在发布之前，应该有充分的性能测试。

性能的问题，永远都不会有一个最终的完美方案。其要点在于，设计，编程，配置，测试时要有性能的概念。要思考自己的每一个动作会对性能造成什么样的影响。性能的改进依赖于测试，任何改进都必须有性能测试报告来证明其是行之有效的，而不是yy出来的。性能的改进依赖于团队对于性能持久的关注，而不是有了问题才解决。

这个有点问题， 如果是SOA架构，那必须面对的就是原有系统和异构系统。
如果你的SOAP被压缩为某一个格式，你怎么确定接收方会识别你的压缩格式，正确解压缩？改造所有的旧有系统？
不过对于新系统内部可以考虑用自己的实现去传输。

其实现在看webservice调用也可以考虑不用xml传输，用json或者其他更轻量级的格式貌似都可以。

其实做异构系统集成，还可以不用webservice，有更好用的技术。

如果要用WS的话，建议可以使用二进制协议的Hession或者PHPRPC，如果不用的话，用REST。

旧系统也可以考虑加一个薄层，这个薄层可以加在应用服务器上，也可以加在一个中心转发机器上。

恩，以前用xml是为了标准简单，真正关键时刻要性能的话，还是得用2进制。

json貌似减轻了一些性能负担，但是不如2进制来的爽快。

跨平台的话，二进制不见得会多爽。至少javascript里面没办法处理二进制。

javascript传递XML?速度更慢，要提供好的性能，最好不要使用解释型语言。