There are already plans to provide Zyan with a monitoring and statistic feature, as you can see under
But work on this feature hasn´t started yet.
> I am in the monent very interested to see some perf numbers.
Performance numbers always depends on many factors: network protocol, size of messages, number and frequency of messages sent, number of concurrent client, network bandwidth, hardware, and so on.
I currently have no performance charts. Performance was never a problem, with one exception. Zyan need long time to register distributed events and delegates to a server. This issue is caused by dynamic code generation and compiling. Since
Changeset 12851 the issue is resolved. Zyan uses now lambda expressions instead of dynamic code generation to attach remote event handlers.
If don´t want to wait for completion of the Zyan monitoring and statistic feature, you can collect numbers and facts yourself. To be able to do this, you need to know, how Zyan works.
> Though Zyan is based on .Net Remoting, this disallows usually to have full control over the internals, like
> how many threads are just waiting [ready to process new incoming "packages" really in parallel].
.NET Remoting uses the .NET ThreadPool and this applies also to Zyan. Changes you make on the ThreadPool configuration affects Zyan. You can increase the minimum and maximum number of parallel worker threads, for example (via
ThreadPool.SetMaxThreads). The ThreadPool class let you get the number of available threads in the thread pool (ThreadPool.GetAvailableThreads). Please
remember that the ThreadPool is also used by other components of the .NET Framework. This means that not all used threads are Zyan worker threads!
Generally the .NET Framework ThreadPool implementation is robust and has good performance. The .NET ThreadPool is optimized for short running tasks. Receiving messages from a socket is such a short running taks in most cases. You can find some detailed information
about the ThreadPool (and its improvements in .NET Framework 4.0) here:
Other interessting perf numbers depend on the sent bytes over the network and the amount of time thas was required to doing this. It is not difficult to get the raw byte to be transmitted. You just have to wirte a component called
channel sink. Zyan uses this existing extension system from .NET Remoting (Read more about Remoting sinks:
http://msdn.microsoft.com/en-us/library/tdzwhfy3%28VS.80%29.aspx). Every sink needs to have a sink provider. The provider is a factory class which receives configuration settings
and manages creating instances of the sink and plugging them into the sink chain, when needed.
You can see a very simple implementation of such a channel sink inside the Zyan source code. The ClientAddressServerChannelSink is used inside Zyan to get the client´s IP address on server side.
ClientAddressServerChannelSinkProvider This is the provider. As you can see in the CreateSink method, it creates a instance of the sink and puts it into the sink chain.
ClientAddressServerChannelSink This is the channel sink implementation. The music plays inside the ProcessMessage method and the AsyncProcessResponse method.
You can take this code as a template to create your own sink for acquiring your perf numbers on server side (for a client side sink, you must implement the IClientChannelSink interface instead of IServerChannelSink and the IClientChannelSinkProvider interface
for the provider instead of IServerChannelSinkprovider; Create always seperate sinks for server and client!). Interessting for you are the
requestStream and responseStream parameters. They can be used to get the count of raw bytes to be transferred over the network.
Please have a look at a patch from the user blackdog at
http://zyan.codeplex.com/SourceControl/list/patches (last entry). He wrote already a counter sink to get perf numbers. The patch was not applied to Zyan because the feature of easy sink integration wasn´t completed at this time. His code should give
you a glue about writing your own performance monitoring channel sink.
The position of your sink inside the sink chain is very imporant. If you plug your sink in to early, the stream may not be created already, for example.
Your sink provider must be added to a protocol setup. This is very simple. On server side, you can use the following extension methods on your protocol setup instance:
AddServerSink (Adds your sink provider at the end of the sink chain)
AddServerSinkBeforeFormatter (Adds your sink provider before the formatter sink; The formatter sink handles (de)serialization of the data to be sent)
AddServerSinkAfterFormatter (Adds your sink provider after the formatter sink; Here the data should be serialized to the requestStream)
On client side you use the methods called AddClientSink, and so on.
I hope this helps you.
As soon as I have any news about the final Zyan monitoring and statistic feature, I´ll post it here on Zyan discussions.