> Frans Bouma wrote:
> > Consider an object which is serializable to XML using the SOAP
> > formatter. the XmlSerializer is first serializing the object to XML.
> > This is done using an utterly slow, FILE based approach.
>
> Where does this persistent myth spring from?
because it is true? Does it or doesn't it use the file system to
create sourcecode it has to compile? You said it yourself:
> It's true that the first time you fire up an XmlSerializer in
> a process, there's some disk activity. But only the first
> time. If you observe what's going on with FILEMON, you'll
> see that the first time you ask for an XmlSerializer for a
> particular type, the C# compiler gets fired up.
>
> But once you've asked for the XmlSerializer for that type,
> you can ask for it as many times again as you like, and it
> you'll not see any disk activity at all - it just reuses what
> it built earlier. (And if you care about performance,
> presumably you were planning to serialize and/or deserialize
> more than just once, right?) Nor will you see any disk
> activity when you ask it to serialize and deserialize objects
> for you. (Unless you serialize via FileStreams of course...)
... I just said the XmlSerializer uses the filesystem which IS
slow. That's all I said. You shouldn't read more into things I didn't
say in the first place, Ian.
> So there's nothing intrinsically file-bound about
> XmlSerializer once its up and running as far as I can tell.
I'm pretty sure it will then run the types it has created to
produce the xml for a given type, code which is not unloadable from the
appdomain btw.
> And aside from that one detail, what about your more general
> claim that XmlSerializer is slower than SoapFormatter?
SoapFormatter is pretty slow also, but it's my experience that
if I serialize a type to disk using soapformatter or using xmlserializer
the soapformatter is faster big time. IF the xmlserializer is even
capable of producing XML because it bites the dust as soon as it runs
into an interface typed member variable, something the soapformatter can
handle nicely and which has always got me wondered why on earth the
xmlserializer wasn't capable of producing xml with interface types or
cyclic references.
> There's a fairly well-known article on MSDN that talks about
> the relative performance of various styles of .NET remoting
> vs .asmx web services:
>
> http://msdn.microsoft.com/library/en-us/dnbda/html/bdadotnetarch14.asp
>
> Notice that the throughput and response time of SOAP over
> remoting is substantially *worse* than .asmx for all user
> loads when hosting in IIS.
Who hosts remoting services in IIS? Of course it's slower in
IIS. :) This is about communication between 2 applications on a binary
level. Why would you need a webserver/http consumer/xml serialization
etc. etc. ? You just want to get the binary stream accross.
> This is further reason to be suspicious of your claim that
XmlSerializer is slower than
> the SOAP binary formatter. Apparently XmlSerializer is
> faster here. The only situation in which the SOAP binary
> formatter can do better (and even then, only some of the
> time) is if you use the TCP channel and don't host in IIS.
> And yes, those two things are have performance benefits, but
> again it has precisely nothing to do with the XmlSerializer.
> (In other words, SoapFormatter only looks better if you stack
> the odds in its favour first.)
Again, Ian, I just said it was slower, I didn't mention a
situation nor a context. If I have to serialize a big object graph to
disk using teh soap formatter it's 'faster' (it's pretty slow) than the
xmlserializer. I'm not serializing the graph to disk every 20 seconds,
just now and then. Why should I then conclude "the xmlserializer is
faster", because it isn't? In other situations it is perhaps, due to the
code it generates which hardcoded produces xml for a given type...
Nevertheless, the XmlSerializer is unnecessary in a webservice
setup if the client of the service isn't consuming XML. However you
can't exclude the XmlSerializer in a webservice, which can be very big
problem if you have complex typed member variables or interface typed
member variables in the objects in the graph: the xmlserializer can't
handle these. What to do then? Implement IXmlSerializable? No can do
either, as the XmlSerializer then thinks the complex type is a dataset.
Not only is XmlSerializer unnecessary, it's also a big pain for
that reason, and all that for producing XML which is not consumed as XML
anyway.
> Only two of the possible remoting configurations consistently
> outperform the .asmx web service implementation according to
> those tests. They are the TCP Channel + Binary Formatter,
> and the HTTP Channel + Binary Formatter, both running outside
> of IIS. (And that latter is extremely close. It's only the
> TCP+Binary+not-IIS option that gives you a really substantial
> benefit.)
... which is also the only sane option for doing remoting in a
100% .NET environment, because who needs the XML if it's not being
consumed at the client? That was the whole point!
> Have you run other tests that contradict these (fairly widely
> reported) tests? Or are you just describing what you think
> should be fastest, based on some internal mental model of
> yours? If there is other evidence around that tells a
> different story, then again, I'd love to see it.
I was describing the result of a setup where I ran into this
issue with the code being generated in the background which severily
stalled the process. You now wrote a long rant telling me I was wrong
and I apparently stepped on your towes and for that I'm sorry. You
totally missed the point though. The point was that because webservices
use xml which is totally unnessecary, the XmlSerializer is used no
matter what, while you don't need xml to get services to talk to clients
and vice versa! :)
> > However if you just have an application sitting on 2 1U
> boxes in the
> > same 19" rack, why on earth would you set up the
> communication between
> > the processes on both boxes via xml?
>
> There's a very good reason not to use .NET remoting in such a
> setup. (That's not an argument in favour of XML per se, of
> course. However, web services don't suffer from the problem
> in question.) .NET remoting requires both ends to share type
> information. This entails a degree of coupling between your
> systems that is likely to be highly undesirable.
Everybody who has written a remoting setup knows that this is
easily circumvented by defining an assembly with just interface
definitions which are implemented by teh server and consumed by the
client. You don't need to store type implementations on server and
client, just the interfaces.
Why is it highly undesireable that systems are coupled?
Webservices are also coupled. these types are also known at the client!!
In fact, VS.NET regenerates classes for those types at the server when
you add a web reference, but these regenerated classes can often be a
big pain as they don't contain deeper logic and will cause casting
errors along the way (so you have to alter these generated classes by
hand).
A service which provides an interface should have a well known
interface, which implies that the interface is known on the client.
Otherwise the client can't consume the service...
> There's also a good reason to host in IIS today, which is
> that it's the only supported mechanism for getting integrated
> authentication. You can use that on both .NET remoting and
> .asmx of course, but remember that once you host in IIS,
> you've already lost the lion's share of the performance
> advantage .NET remoting could otherwise have given you.
Integrated authentication can be 'good' at first, but once you
use a remoted service, you should protect the datastream anyway, which
doesn't make non-IIS remoting a bad solution per se. If 2 applications
just have to communicate on a binary level, why on earth do we need this
big stack of overhead services to get that going? :) I'm not saying
everybody should now start writing his own socket consuming
communication library, however there are far more efficient ways of
getting data accross and calls accross than a full stack inside a
webserver with an HTTP consumer/xml producer etc.
> It's true that if you use the binary formatter and TCP
> channel, .NET remoting can offer better performance,
> especially if you are able to host outside of IIS. But it's
> not as big a difference as some make out. Moreover, you are
> increasing the coupling in your system, so you really have to
> ask yourself whether that last ounce of performance is more
> important to you.
Could you please provide some argumentation why the close
binding of a server interface with the client is so bad? If you
implement an interface on the server, the client should be able to
consume that interface and know that interface, be it a remoting server
or a webservice. The server then can later on implement another
interface for other clients, or upgraded clients. Bad design? I don't
think so.
Talking about myths, I think the fear for having coupled systems
is based on a big myth. If coupling of systems is so bad, every tier in
an n-tier system should be completely abstract and only be communicating
with others through xml (both commands and data). The vast majority of
systems have coupled tiers or better: tied bindings between service and
consumer, be it in an n-tier system, remoting or webservices. This is by
design, and not bad at all.
> Sometimes it is. But you seem to be saying that web services
> are always the wrong choice, and I really can't agree with that.
As long as XmlSerializer is REQUIRED, webservices are the wrong
choice, especially in situations where you are communicating between
100% .NET applications. That was the start of the argument btw:
webservices vs. COM+ with its dcom. They are ONLY the right choice if
the clients are not .NET, and/or when pure XML in a given format has to
be consumed/produced. I'm not very sure if that's the majority of
systems currently being developed with webservices.
The XmlSerializer is severily broken as it can't produce Xml for
simple classes with interface typed members, it can't handle cyclic
references, it can't handle correctly classes which implement
IXmlSerializable (to work around these issues). I'd love to implement
IXmlSerializable to connect its methods to my ReadXml and WriteXml
methods which do serialize cyclic references and interface based types
to xml in my classes but I can't, due to the hardcoded paths in
XmlSerializer for that particular interface.
Aren't you agreeing with me that if you have two boxes, A and B,
and on both an application is running and communicating with the other
one on a binary level, that it is completely insane to run this
communication through a webserver/http client, xml
serializer/deserializer, soap envelopes etc. ? :) Do you really see the
need for that full stack? I don't. In the early days we used sockets on
Unix and RPC. That's very low level and I fully agree a bit more
sophisticated layer on top of that might be very handy. However a full
stack of services on top of eachother producing XML in the end is nuts
as all the work done in that stack is not used, the XML is not consumed
as XML, it's just a different format the data is in, but it was already
in a format. That was the original point of the argument started: xml is
not needed in that situation, so leave it out of it, no matter how much
code is generated behind the scenes to produce xml on teh fly.
FB
===================================
This list is hosted by DevelopMentorŪ http://www.develop.com
Some .NET courses you may be interested in:
NEW! Guerrilla ASP.NET, 26 Jan 2004, in Los Angeles
http://www.develop.com/courses/gaspdotnetls
View archives and manage your subscription(s) at http://discuss.develop.com
