＋设为首页 ＋添加到收藏夹
as the capabilities of our distributed applications increased, so did our consumption of bandwidth. in 1998, our server sent objects no larger than 50k to a group of users on a local network. by 2002, we were passing an average of 500k per object, with some as large as 1.5mb.
more important, the distribution of our user base grew from 50 to over 1,500, with some users based across the country from the server. add in a group of users roaming on their modem connections and the full scale of our bandwidth issues become clear. we were presented with a problem faced by many developers of distributed systems: reduce bandwidth usage and client wait time without removing any functionality. this article shares our solution to this problem, providing you with the simple code that helped us eliminate over 80% of our network traffic.
evaluating bandwidth is quite simple. the developer has two options: get more of it or use less of it. given the magnitude and expense of expanding bandwidth on a nationally distributed application, it was clear we had to find ways to reduce the amount of bandwidth required by our systems. its important to note the wording: reduce the bandwidth usage, not the amount of data passed over the network. to preserve the functionality of the systems, we needed all the data being passed over the line. in the end, there was one conclusion: the data needed to be compressed.
as i researched compression in java, i was looking for a way to pass in an object and receive a compressed object back. i found that there are a number of ways to compress sockets or build zip files on the disk, but not the object-level solution i was seeking. we needed an api that could be selectively implemented and used for the largest data objects and most critical applications without impacting other parts of the system. we also wanted the ability to compress an object one time, and use that same object for multiple downloads to client machines, essentially caching a compressed object.
during this research, i found an article on compression on
the java developers web site that laid out all the pieces to our
solution (see resources section ). using just a few of the classes in
the java.io and java.util.zip packages, we were able to build an api
to compress any serializable java object. being the kind of developer
who prefers simplicity, i was excited at the ease of use and
performance of the underlying java classes as well as the api we
built. we were able to develop and integrate our solution in just
under two days, resulting in more than an 80% reduction in network
traffic and astounding improvements in ... 下一页