Ce qui est le plus WCF liant performant?

Question

Je dois obtenir la performance de débit maximum dans mon service WCF. Dans l'un de mes tests ci-dessous le service a seulement 50k éléments de données par minute en utilisant NetTcpBinding. Est-ce qu'une déconnexion de liaison comme NetMsmqBinding améliorer cette performance?

Service et le client utilise WCF et exécuter dans la même machine.

[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single,
    ConcurrencyMode = ConcurrencyMode.Multiple)]
public class Storage : IStorage
{
    protected List<int> _data = new List<int>();

    public void Insert(int[] data)
    {
        lock (_data)
        {
            _data.AddRange(data);
        }
    }

    public int[] Get()
    {
        lock (_data)
        {
            return _data.ToArray();
        }
    }
}

Le code ci-dessus est une version simplifiée du code réel.

Answer 1

Msmq est susceptible d'être plus lent que TcpBinding.

Si vous utilisez sur la même machine, vous devez certainement utiliser NetNamedPipeBinding (IPC) qui est le plus rapide de liaison disponible.

Vous devriez également vérifier la façon dont vous sérialisation vos données. sérialisation Protocol Buffer est beaucoup plus rapide (et plus maigres) que sérialisation binaire par défaut WCF (mais nécessite un peu de peaufinage).

Answer 2

Le plus rapide pour un seul appel en vase clos, ou pour un flot de milliers d'appels?

NetMsmq utilise un message de mise en attente MSMQ - vous mettez votre message dans une file d'attente géré par MSMQ, et le service obtenir de cette file d'attente et éventuellement travailler. Vous ne recevez pas une rétroaction instantanée, les messages ne sont à sens unique.

NetTcp d'autre part est comme http - seulement plus rapide. Vous envoyez une demande au service et obtenir une réponse en retour (si tout va bien) tout de suite. Aucun message faire la queue en soi impliqué, vos messages sont demande / réponse.

Je ne pense pas que vous pouvez comparer les deux liaisons, vraiment. Ils servent à des fins totalement différentes:

• si vous voulez par exemple rechercher un code postal et retourner la longitude / latitude de cet endroit, vous voulez certainement un mécanisme de demande / réponse -> utiliser NetTcp

• si vous souhaitez déposer des demandes à, par exemple imprimer un document, ou réorganiser une base de données, ou quelque chose de cette nature - quelque chose qui doit être eu tendance à terme, mais vous ne vous attendez pas en arrière une réponse tout de suite (mais vous pouvez ensuite vérifier si le message a été manipulé correctement), puis utiliser un message système de file d'attente

L'espoir qui rend les choses un peu plus clair - je ne pense pas que ces deux sont vraiment orientés vers le même ensemble d'opérations, de sorte que vous aurez probablement pas toujours de choisir entre ces deux directement:)

Answer 3

Si le service client et exécuté sur la même machine que j'éviteraient le réseau tout à fait en faveur d'un mécanisme IPC tels que des tuyaux nommés. Le trafic réseau entraîne beaucoup de frais généraux qui peut être évité en utilisant un mécanisme IPC.

Answer 4

Avez-vous des raisons de croire que le transport est ce qui ralentit le taux de transaction? Qu'est-ce que vous a dit le profilage? En ce moment, ce service est d'être un seul thread, et a également plusieurs appels à « obtenir » verrouiller les uns les autres.

Comment est-ce service appelé / utilisé? Serait-il utile de le rendre multi-thread? Qu'en est-il à l'aide d'un verrou plus sophistiqué comme un ReaderWriterLock qui permet à plusieurs appels pour obtenir de se produire en même temps, mais toujours bloquer sur « Ajouter »?

Modifier: Je sais que la situation est simplifiée, mais serait le benifit service réel à partir des mêmes considérations