|
Sponsored Links
Resources
.NET Research Library
Get .NET related white papers, case studies and webcasts
|
.NET performance and scalability
.NET performance and scalability
.NET performance and scalability
|
Messages: 5
Messages: 5
Messages: 5
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
large image files transfer
We are working on a project that requires to transfer large image files from a server to clients. We think (but not sure if it's correct) that sending images file in binary format using SOAP would degrade the performance greatly as
SOAP has to encode the image files on the server side and decode it on the other side. And our solution is to put the image files in the body of an HTTP message and send it to the clients. In other words, we use HTTP as our protocol to avoid encoding/decoding overheads.
I'm just wondering if anyone can tell me what the disadvantage of this approach. Do you know any better way to solve the problem???
Thanks you.
|
|
|
Message #141793
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
large image files transfer
Henry,
Remember that SOAP is simply an abstraction protocol over HTTP, so in essence you are not going to gain any performance benefit by using it. There is a certain cost in wrapping up the data, and you have to balance that cost against the benefits of SOAP (ie tying the image data to credentials or other information, and better opportunities for compression/encryption of the data than HTTP).
When transferring large image files (or any other large binary data), unless you are doing it over a very fast connection (for example lets say 10MB/s for images around 1 meg), your main performance concern is going to be in bandwidth. My recommendation would be to perform a few tests using the SOAP solution, including compression of the data before transmittal. It may be faster to compress the image, transmit it, and decompress it on the other side, despite the extra processing time this entails.
There are not a whole lot of other options, however if performance is critical and you are not operating over firewalls or the public internet a pure TCP/IP socket solution would generally perform faster than any other option. Incidentally, it also involves the most code on your part to make sure everything works smoothly.
HTH,
Chris
|
|
|
Message #159933
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SOAP is not good for byte arrays
Its true that SOAP is just a protocol over HTTP, but the built in SOAP Serializers will bloat a byte array, especially with a large file. Remember SOAP is nothing more than an xml format, so for each byte you'll get an opening and a closing tag, with just the one byte inside like so:
<soap:byte>1</soap:byte>
i'm not sure of the exact xml tag text, its easy to searialize out a byte array to file using the SOAP formatter and see for yourself.
basically, for each byte in the image you'll end up writing 24 bytes of text to represent the soap xml value (double that if soap is unicode...not sure there). so if your image is 250K, which is a fairly small image, you'll send over 6 meg of SOAP. even if you add compression, i though you'd be hard pressed to get below 250K.
of course this is a moot point if you are using WSE 1.0 or 2.0.
|
|
|
Message #170099
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
large image files transfer
I'm a bit rusty on this but: If you don't have firewall issues, why not use a TCP Socket rather than SOAP? It's not so hard to code and you don't have to pay some of the SOAP/UDP overheads.
I have used this in the past on telepathology applications for both large image transfer and video-conferencing. In those cases I used unmanaged C++, but the point is that if performance is an overriding issue, you should not be looking at SOAP, but at a TCP based solution that allows you to send your data without needless text encoding transformations. Also remember that there are overheads at the far end in using a UDP based protocol for large amounts of data.
Remember that HTTP is a UDP datagram protocol, not a guaranteed delivery protocol like TCP - if I recall correctly it doesn't even guarantee the order of the packets, so there will be overheads in streaming the data in, esp. if the images are _really_ big and being sent via many different routes on the net. You might be better advised to stream the data from a socket straight to disk?
In addition you won't have the problem of object deserialisation at the far end since you already know what the data is each time. Why force your system to go through that sort of effort just to comply with a protocol that was intended for other applications?
|
|
|
| Top posters of the weekTop posters of the weekTop posters of the week |
|
|
This list contains the members who have made the most posts in all forums over the
last 7 days:
- Karissa Sin
- sherazam khan
- Mike Liu
- Core Lab
|
|
Hot threads
Hot threads
Hot threads
|
More hot threads
More hot threads
More hot threads
|
|
Speaking at EclipseCon 2006, Java developer and independent consultant Madhu Siddalingaiah compared Microsoft's Visual Studio IDE to the open source development environment of Eclipse.
(33 comments,
last posted
March 09, 2010)
In this tech talk, Microsoft's Peter Provost talks about the design of the Composite UI Application Block and how the p&p team has led Microsoft in the adoption of Agile methodologies.
(0 comments,
last posted
April 17, 2006)
Chapter 4 of Framework Design Guidelines, titled "Type Design Guidelines," presents patterns that describe when and how to design classes, constructs and interfaces. In this chapter, Abrams and Cwalina divide types into four groups and discuss the do's and don'ts of type design.
(2 comments,
last posted
July 07, 2006)
Paul Ferrill caught up with prime open-source .NET applications driver Miguel De Icaza at Novell's BrainShare conference last week. They discussed the status of Windows Forms for Mono (it's coming along) and VB.NET for Mono (it looks like it's out).
(5 comments,
last posted
March 30, 2006)
In this tech talk, Microsoft Visual Studio architect Jack Greenfield discusses the company's approach to Domain-Specific Languages, or DSLs, and the part they play in software factories.
(0 comments,
last posted
March 15, 2006)
More hot threads »
|
|
