Async

Everyone knows F# agents are cool right?  Well here’s yet another example of how versatile they can be…

There was a series of posts last April by Stephen Toub from the pfxteam at Microsoft.  I was reading through some of the posts again the other day and thought some of the ideas presented there would make interesting projects in F# to demonstrate the flexibility and succinctness of the language.  I thought the ObjectPool example would make an interesting project in F# using agents aka MailboxProcessors. An ObjectPool is basically a pool of objects that have been pre-created so that you can grab one and use it, and then place it back in the pool when you’re finished.  They are useful in situations where the cost of creating object from scratch is very high or you want to cut down on allocations in the garbage collector.

Ok so I have been offline for a while now, what with starting a new financial contract in London and not having any broadband access for a while.  I have been working on something, honest!

Since the last post I have been reflecting on the pipeline design and it had a distinct object orientated feel to it that I wasnt happy with, so I have amended the structure of the code and come up with the following which simplifies in some areas and expands in others…

Welcome to pipeline processing part 2.

I feel I need to backtrack slightly from the previous post, having worked with pipelines for quite some time I have the advantage of knowing all of the details that may be alluded to in these articles without being effected by any omissions I may make, obviously you guys aren’t in that position, so I’m going to try and rectify that a bit now.  If you have any queries then please leave a comment and I will try to address them in further articles. Pipelines are a simple concept but in practice there can be some caveats and things to bear in mind, sometime the whole mindset of development team can be against them unless they can see the bigger picture…

Welcome to new series of articles on pipeline processing.

First up, what’s a pipeline?  Well according to Wikipedia:

A pipeline is a set of data processing elements connected in series, so that the output of one element is the input of the next one. The elements of a pipeline are often executed in parallel or in time-sliced fashion; in that case, some amount of buffer storage is often inserted between elements.

[Read More]

Welcome to part 4

If you were looking forward to some exciting new F# code this time your going to be disappointed, however if you are like me and like looking at graphs and stats and digging in deeper into the code then your going to enjoy this, lets get started…

I set up a 5 minute test with 50 clients connecting to the server with a 15ms interval between each one.  Once connected each client receives a 128 byte message from the server every 100ms so this will be a 500 messages per second test.  I am going to be using an excellent product called YourKit Profilerfor .NET it can do both memory and CPU profiling as well as displaying telemetry for things like thread count, stack contents, memory allocations etc.  It can be configured to be a lot less intrusive than a lot of other profilers and I have had a lot of success using it.  You can download a demo from their site using the link above.  I will be doing some other articles on using profiling and analysis tools later on so stay tuned for those too.  All of the graphs and information gathered in this post come from YourKits output during CPU and memory profiling.

Welcome to part three!

As promised heres a description of the inner workings.  I’m sick to death of typing SocketAsyncEventArgs so from now on I will refer to it as SAEA.

BocketPool
The BocketPool has an interesting name and with it an interesting constructor! It takes the following parameters:

number: The number of items to create in the BocketPool. size: The size of each buffer in bytes. callback: A callback function which is invoked whenever the SAEA object completes its operation.

Welcome to part two

Lets jump in at the deep end and take a look at some code…

When you look at the method syntax for the xxxAsync methods you will notice they return a boolean value that indicates if the method completed synchronously, this means that you have to check the return value every time you use one of the methods and invoke the callback yourself if it completes synchronously.  In practice this hardly ever happens, and normally only on a send operation.  But as it is a possibility we will add module with a some extension methods in to help us out, this will make the code more readable and avoid unnecessary duplication.

Welcome to part 1

A while back I read an interesting article by Brian McNamara f-async-on-the-server-side which describes C# and F# versions of a simple asynchronous socket server, one of the driving forces behind the article was how F# can wrap the traditional asynchronous model with Asynchronous Workflows, this produces nice clean simple code compared to the C# version which uses lambda expressions, the code looks quite ugly in this style!  However thats not the end of the story, a lot of memory fragmentation can occur using the APM model when there is a high throughput, so I thought I would see if I could take this a step further…