Hi everyone,
I'm facing a performance-challenge. I have a project which was build using LLBLGen Pro 1.0.2005, Visual Studio 2005 (.NET 2.0) and it uses the C# adapter templates with webservices (downloaded from the 3rd party download section), which is slightly modified, but nothing relevant. We use an SQL Server 2005 database and LLBLGen runtimes version 1.0.20051.60621. That all works fine. But we are implemting this for a client and now our solution seems to choke on the amount of data. We did some performance-testing and it seems that almost all performance is lost to the serialization and deserialization. The ReadXML and WriteXML of the entities take up more than 90% of all the time spent on the transactions. We've also had implementations of the same software where this didn't happen. But it seems to be that we're passed some performance-thresholds of the software.
So we're considering all possible angles here to improve the performance, because what we have now is unacceptable. We are trying to reduce the data before it enters the Business Layer. This is something which has obviously nothing to do with LLBLGen. But we also need to try to make improvements in the Business Layer. I did some initial research and we started testing some of the possibilities. But as we also have time-pressure, I would like to show what I've got so far and maybe someone can help me with the architectural decissions or the implementation of it. Any help is appreciated. If possible we would like to stay on LLBLGen Pro 1.0.2005 and VS 2005, because an upgrade of those would not only mean more investments, but also an extra learning curve and implementation time, which we don't have to be honoust.
So far, I found 3 possible angles for improving serialization and deserialization in the Business Layer:
1. Moving to WCF with DataContractSerializer
2. Moving to Remoting with BinaryFormatter
3. Start using the FastSerializer for LLBLGen
I will elaborate a little bit on all 3 possibilities:
-
WCF
WCF is a preferred way to go, because it is the direction Microsoft is going with SOA. Furthermore, test have proved that WCF with DataContractSerializer performs very well (see http://serialseb.blogspot.com/2008/01/comparing-serializations-or-why-flash.html and http://blogs.microsoft.co.il/blogs/sasha/archive/2008/01/20/wonders-with-wcf-s-datacontractserializer.aspx). All Entities are now generated with the [Serializable]-attribute, which should not be a problem for the DataContractSerializer. The DataContractSerializer will first serialize to an XML-Infoset object-structure in memory and the a BinaryEncoder would be used before it is sent over the wire.
-
Remoting
The above two links show different performance for the Remoting architecture. But still, it would probably improve things drasticly. Remoting also uses the ISerializable interface, which should be okay with our Entities. The BinaryFormatter will use reflection to serialize the inner object structure.
-
FastSerializer
I have not investigated this possibility at the moment.
For WCF and FastSerializer I'm not even sure it will work with LLBLGen 1.0.2005. I have no experience with LLBLGen 2.x and I don't know if I can use existing templates to build a working solution.
So far we have tried to implement the first possibility; WCF. But we have no luck so far. We created a WCF-service, added ServiceKnowTypes for all entities and OperationContracts for all methods that used to be WebMethods. These methods generally return EntityCollections. The WCF-Service compiles, but I'm stuck on creating the webreference. Since I'm on VS 2005 I do this manually by invoking svcUtil.exe:
"C:\Program Files\Microsoft SDKs\Windows\v6.1\Bin\svcUtil.exe" net.tcp://localhost:8083/WCFService/mex /language:cs /serializer:XmlSerializer /reference:"C:\Sources\bin\DataLayer.dll" /out:"C:\Sources\WCFClient\WCFServiceProxy.cs"
When using the XmlSerializer, I get warnings in my generated code:
// CODEGEN: Parameter 'GetOrdersResult' requires additional schema information that cannot be captured using the parameter mode. The specific attribute is 'System.Xml.Serialization.XmlElementAttribute'.
And the generated proxy method does not look okay either:
GetOrdersResponse GetOrders(GetOrdersRequest request);
It is generating proxy-classes for my Entities, although it should reference my original entities (as I did in the svcUtil commandline). I also reference to the project. Still, it misses the "additional schema information".
When I try the same with the DataContractSerializer (which is actually the preferred way), I get warning during the generation of the proxies:
Warning: The optional WSDL extension element 'body' from namespace 'http://schemas.xmlsoap.org/wsdl/soap12/' was not handled. XPath: //wsdl:definitions[@targetNamespace='http://tempuri.org/']/wsdl:binding[@name='NetTcpBinding_WCFService']/wsdl:operation[@name='GetOrdersPerStatus']/wsdl:output
And then the code looks like this:
void GetOrders();
Parameters and return-types seem to be lost in both cases. The warnings I get from the XmlSerializer are similar to what is discussed here: http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=8927&StartAtMessage=25 .
I did try to build using the runtime, which was provided in that topic. But that obviously would not compile, because it was actually a 2.x runtime and our code was generated with LLBLGen Pro 1.0.2005. I also tried to change the result-types of our methods to IEntityCollection2, but that didn't help either.
I could use some help in getting WCF working for our project. Or maybe some insights or directions on how to implement Remoting or FastSerializer (which I believe is also based on Remoting). Or maybe a new approach, which is usefull for us. Again, any help is appreciated.
Thanks a lot,
Rene Lergner
I will try it immediately. I'll report back in a few minutes.