xml文档从格式到大小都是不是确定的。有的可能只有几行，而有的却有好几兆字节。你也许会怀疑是不是需要了解xml文档的大小。而当性能成为首要问题时，知道xml文档大小就是件必须要作的事情了。
从性能角度讲，有两类处理xml文档的方法。批量处理方式需要较短的时间，解析成组的文档。实时方式就是实时的处理文档。批处理方式的性能可以通过在一定时间内处理多少文档来测量，而实时模式的性能也采用类似的测量方式，不过是以处理一个文档需要多长时间来计算的。
scenarios场景
想象一下，你有一个实时工作的系统，比如一个web服务器。这个系统需要实时的接收客户发来的订单，并需要立即对这个订单进行响应。
这个系统显然不能用批量处理的方式进行。简单的估计一下，假设这是个很简单的订单，只有十个项目，这样所生成的xml文档就比较小，大概每个文档是4kb。这种情况下，使用dom来解析收到文档。
如果你的订单每小时只有几个，那么系统性能对你来说还不是问题。但是长远考虑，总有一天订单的数量会多到令你意识到系统性能必须提高。
现在你开始考虑提高性能来适应增长的负荷。你的订单文档已经很小了，把它们合并成较大的文档也没有什么实际的意义。从纵向考虑，这时候你可以提高现有系统处理能力；从横向考虑，你可以增加更多的系统将负荷分散开。
再看看另一个完全不同的领域，你现在要处理的是一个大型的数据仓库。和web服务器完全不同，你现在用ftp来传输平均大小为300mb的xml文档。如果还是使用dom来解析xml文档，你很快就会遇到大麻烦。相反，如果你使用sax就会好的多，它可以直接解析流入的xml文档，而不必把它们事先都装入内存。
改变文档尺寸
有时候你会遇到特殊情况需要改变xml文档大小。想象一下，和刚才一样你有一个实时处理xml文档的web服务器，而此时所有的文档大小都是400mb而不是4kb，你不能使用dom方式，因为那太占内存了。可是因为这是个实时系统，性能很重要。你可以使用sax，不过需要时间允许并要有强大的处理器。
在这种情况下，你可以通过改变文档大小来改进系统执行性能。比如你可以将一个400mb的文档分成10个40mb的，或者40个10mb的小文档，这比起处理一个400mb的文档更有效率。这样你就可以使用dom方式把文件读入内存进行处理，及时响应每个文档的请求了。同时还可以清除掉不相关的文档。
在批量处理方式上也有类似情况。想象一下你在通过dom的批处理方式处理数千个4kb大小的文档。最好的方式是将一千个文件合并成一个4mb的文件。因为每个文档的载入都需要占用系统时间（不论是dom还是sax）。通过将一千个文档合并成一个，你只需要载入一个文档，占用的时间只是原来的千分之一。
Java Asp PHP .Net XML C/C++ CGI VB Jsp J2ee J2se J2me EJB Servlet Tomcat Resin Struts Weblogic Eclipse ANT GUI JMS Web servise IDEA Webphere Hibernate Spring Jboss Applet Swing Socket Javamail Perl Ajax P2P 安全 模式 框架 测试 开源 游戏
Windows XP Windows 2000 Windows 2003 Windows Me Windows 9.x Linux UNIX 注册表 操作系统 服务器 应用服务器
