Scott Hanselman’s recent post about exporting data from a database to a csv file where he talks about how some code could be improved. He does a very nice job of showing how and were the code could remove the smells that were present in the original design. However there are a few things that I see that if changed could improve both the performance and scalability of the system.
While this is something that depending on the complexity and scalability needs of your site one may consider over kill, it is something that takes minimal effort in design to create a system that is innately more scalable. What happens when the data you are querying starts to push out is 5-10Mb of Data to a CSV file?
Option 1
So rather than generate the list of Foo into a CSV at each request why not pre generate the list at pre configured intervals depending on the volatility of the data and save the resultant CSV to a san that can be served up via IIS. In this scenario there is no need for the ASP.NET worker process to get involved and the IIS process can do what it was meant to do serve content.
Advantages
No need to hit the DB to get the data
You don’t have to involve the asp.net worker process and let IIS do what its designed to do
Disadvantages
Your data may be stale up to a preconfigured amount of time (but since its going to a report of sorts it is more than likely stale)
Option 2
So your business requirement absolutely dictates that it is required to be generated and sent as the user requests it. There is no choice, you have but to send it through the response stream. BUT there is another way. Say when this request for the data to be exported VIA an AJAX call to your server the response from the server is a URL to where the file will be output. Now the server it self can then send a message to the export to csv service and request the file be output to the san. The client can then poll the server waiting for a 200 response code, when it does get one it can then redirect the browser to the given URL.
Advantages
Gives you more or less up to the minute accurate data
Reduces the amount of work the asp.net worker process has to perform
Disadvantages
Introduces polling into the design of the client
When designing systems that do not take Scalability into account from the ground up, you generally are missing something. Considering Scalability does not mean that you choose either of these two options all the time. At times it might make sense to think about using the approach suggested in Scott’s article, the key being to always think about know your data and make informed decisions.
It is the second time I have sat through Udi’s Advanced Distributed Systems Design. Unlike repeating a course at University, I was like a 6 year old waiting for Santa Claus to arrive with his presents at Christmas. Not only has the course content been refined in some sections, CQRS (In case you missed it you can watch Udi’s presentation on CQRS here) for instance. Udi’s delivery of the material is such that he always has you yearning for more. The first time i did this course it was as though someone had opened my minds eye. Since then I have made so many changes to my thinking and the way I approach development.
My reasons for attending the course again were simple
Gauge my progression
Hear other peoples thoughts and opinions
Spend more time at the feet of the master
And of course Learn some more
The beauty of this course is that despite the complexity of the architecture and the concepts the delivery makes the comprehension a breeze. Paul Batum and Rhys Campbell who attended the course have written up their impressions, as has Simon and we all agree that it is worth its weight in gold. So if you have thought about ever doing this course and can make it to one do so, but if your not able to go to one of upcoming courses I would strongly suggest getting in touch with Udi and working other possible solutions with him. Which is why I guess Simon is owed big thanks for setting up this opportunity.
That’s the game I find myself playing with Microsoft software names these days, It’s one thing to go from Indigo and Avalon to WCF and WPF but oh those days of simplicity are a far cry from what we have today. Let’s start with Oslo, what original started as the "updated messaging and workflow technologies in the next version of BizTalk Server and other products" aka Biztalk VNext which was on their SOA site if my memory serves me correct. But what have we today “SQL Server Modeling”.
That’s ok you say we are used to the Microsoft code name to product name shenanigans. Sure but its way more than just changing names and focus or both. This quite often has me having this conversation with myself
Me: What is Microsoft Distributed Caching product? Velocity?
Myself: No that’s the old name now its “Windows Server AppFabric”
Me: Ok thanks ill download that but what does AppFabric have to do with Caching? And where is the CTP of that application server that came from the “Olso” group? Dublin.
Myself: Oh you have that already?
Me: No all I have is that “Windows Server AppFabric”
Myself: Yes that’s Dublin.
Me: But I thought that “Windows Server AppFabric” is Velocity
Myself: Yes it is
Me: BUT BUT BUT….
Myself: No Buts It just is.
I hope that this constant cycle of changeinnovationduplication from Microsoft slows down to a pace that people can keep up with. Maybe even have a sniff of the roses and ensure that it is actually making a difference, and not just causing more noise from Redmond.
Udi presented his talk on CQRS at the Victoria.Net User Group on the 19th of January in Melbourne, we recorded his presentation. Hopefully this is of some benefit despite the audio and video not being the greatest. It was a great night that opened many eyes and ears to the best.
Simon has released the first version of the Linq To Sql Saga Persister code and the EF 1 Saga Persister in the past couple of days. In fact we started working on the saga persister mid September, so what took doing something like a Saga Persister, a fairly trivial exercise almost 3 months. To be fair Simon initially put some of the work on the persister quite quickly. However once we started to use the code in our test with the Manufacturing sample under load it would begin to creak. Seeing as that was a problem we had to switch to using the NHibernate Saga persister for our client to go into production.
The first thing that went through our minds was that we had written the persister wrong, however a persistent Simon continued to work through the issues. Along the way we discovered a few things.
NHibernate is faster and therefore able to handle the load better.
Proper Saga Design is important.
NHibernate is faster
Most of you already know this but the key thing here is that because its faster it fails less therefore the issues that we saw in the development of the persister was difficult to isolate.
In the Manufacturing Sample that comes with NServiceBus start up all the required services and when the partner is ready run it in simulate mode, it does not fail. doing the same thing when using the L2S persister had the same effect.
Once the number of worker threads on the Order Service Host was increased to 4 could use we started to see a whole bunch of errors. From messages not being completed to violation of primary keys and deadlocks. Using the NHibernate persister required us to increase the workers to 6 or 7 you would start to notice similar errors.This leads me to the next item.
Proper Saga Design is Important
If your not sure about what a Saga is please read the NServiceBus wiki. When considering how you build a system though that goes into how you would like to handle long running transactions is important. Knowing how many transactions per second. What are the SLA’s? My rule of thumb the more i think about it is that a Saga message that starts the saga should be unique any subsequent messages that are part of that saga should be dealt with a more explicit message handler. So you have a CreateOrderMessage that starts a saga and subsequent messages are handled by UpdateOrderMessages for changes to the order, with CancelOrderMessages and AuthorizeOrderMessages being explicit to the saga.
In my opinion doing so produces both a simpler and more explicit design of your long lived transaction. This however is now going down the path of a different post one that warrants a post of it own.
The Benefits of Reading code became clear the deeper we went through the NServiceBus code base, the more you understand how each piece interacts with the other to provide a great framework. Despite all the hurdles L2S provided it was worth the effort. What must be said for NServiceBus is that it is highly extensible already evidenced by its existing OOB support for 4 IOC frameworks, now 3 ORM’s and in the future with version 2.1 it will support a whole raft of Queued Transports.
This post has been sitting in my drafts for a while. After my day today i felt that it was best that i put my thoughts about service broker down. In a project that i worked on about 2 years ago Service Broker was used as part of the system to perform data validation. If success was measured by the amount of time that a system has been in production without major issues then i can say that it was successful.
But if a system was to be judged by how much of a pain it is to maintain then l must say that its was not a glowing success. Below is a list of things that i found as good or bad about it.
Bad things
Limited information on the internet
Testing is extremely hard (compromises everywhere)
Troubleshooting is a pain
It could stop working and you may never know, (if using a fire and forget mechanism)
Poison messages disable queues (would have been nicer if it moved the message to a error queue)
Good things
Its Asynchronous
Its Asynchronous
Its Asynchronous
Yes this list is one sided but true. The question that is important though is
Would i use Service Broker again?
The answer to that question is strangely YES. Only in very specific circumstances where system is ok with not having some data loss because of queue being disabled
What would I use instead?
NServiceBusof course. It provides an answer to all the negatives of service broker and is still asynchronous.
First off i know there should be no reason for me to do this as there are hosting options galore, but sometimes its just easier having the code running in your LAN, so with that in mind i remembered reading that Scott Hanselman wrote about his experience setting up VisualSvn on WHS.
So i decided to follow his work and rather than reinvent the wheel, however as i went through the process i found that a couple of things needed changing to make this whole processes much easier.
Setup a new share on your home server using the Windows Home Server Console. The recommended approach is to Uncheck the Enable Folder Duplication Check Box, though i have yet to experience any of the locking issues described here
Log on to your Windows Home Server using Remote Desktop
Give the Network Service access to the share as well as permissions on the folder to Read/Write/Modify files as required. For a detailed walkthrough on what and how to modify the permissions are available in the VisualSvn Knowledge base article for Storing Repositories on a Network Share.
NOTE: it is recommended that you create a special user that has Run As Service Account as well as the permissions to the folder and not use the Network Service.
When prompted by the installation for a location for the share provide it with the share location that you have just setup.
Set choose port 8443 for your port and complete the installation. If the installer gives you any warnings its likely that you have not given the Network Service its required permissions.
Setup up port forwarding on your router. and you should then be able to access the Visualsvn from your Home Server url either http://server:8443/ if your inside your network or http://my-dynamic-dns.homeserver.com:8443/
The interesting thing about this is that while this is one of about 6 different ways i could count to do this installation while i found this the most straight forward for me YMMV.
