6
votes

Y a-t-il une limite pour System.IO.Fileshare?

Je veux construire ma propre base de données de fichiers plats. Voici comment j'accède à la base de données de fichiers plats xxx

existe une limite imposée par .NET pour l'utilisation de system.io.fileeshare.read , , System.io.fileeshare.write et system.io.fileeshare.readwewrite Lorsque vous traitez avec un fichier?

Je veux dire, c'est que .Net capable de supporter des milliers de Utilisateurs utilisant flux de fichiers et lecteur de flux avec system.io.fileeshare.read Pour accéder simultanément à un fichier unique?


6 commentaires

Bonjour, je m'attendrais à ce que la limite soit plus importante sur les API Windows sous-jacentes qui sont probablement enveloppées.


Aucun limite au-delà de la mémoire de la piscine du noyau épuisé par toutes ces demandes d'E / S. Avoir des milliers d'applications lues à partir d'un fichier que vous écrivez est, bien, courageux. Il n'ya aucun moyen de synchroniser, ces applications vont lire des lignes de texte partiellement écrites. C'est pourquoi les serveurs existent, SQL Server est hautement préférable, un fichier texte n'est pas un dBase.


HANS: Synchroniser l'accès aux fichiers est pourquoi le verrouillage de fichier a été inventé.


Je suggérerais d'ajouter un niveau d'accès aux données pour effectuer la lecture et l'écriture de fichier et tout parler à ce niveau. De cette façon, vous n'avez qu'un processus de lecture ou d'écriture dans le fichier et vous pouvez gérer plusieurs connexions à votre niveau de données.


Dites-moi votre version .NET & Windows, je vais effectuer un vrai test pour vous


Il n'y a pas de limite imposée par .NET. Seulement par le système d'exploitation secondaire. Imaginez que vous n'utilisiez pas du tout .NET, mais de nombreux utilisateurs tentent d'essayer d'accéder à un fichier sur une part de fichier, les limitations seraient les mêmes. Si le fichier est mis à jour simultanément, les limitations seront formidables.


6 Réponses :


3
votes

L'élément FileShare signifie que d'autres fichiers peuvent également ouvrir le fichier. Cela ne garantit pas ne garantit pas que les données seront synchronisées de quelque manière que ce soit signifie simplement que plusieurs programmes peuvent désormais lire (car c'est ce que vous définissez - fileshare.read ) à partir de ce fichier pendant que vous l'avez ouvert.

Si vous utilisez READWRITE , plusieurs programmes peuvent lire et écrire dans le fichier. Encore une fois, vous allez pas être informé de tout changement. Si plusieurs programmes écrivent dans le même fichier en même temps qu'un flux, les données seront mélangées et vous obtiendrez un fichier corrompu. (Corrompu signifie que ni vous ni l'autre programme ne pourront la décompiler car vos données sont étroitement liées à l'application de vos amis).

Il n'y a pas de limitations déraisonnables au nombre de programmes simultanés en lisant un fichier.


0 commentaires

4
votes

Si vous essayez d'ouvrir un fichier avec un accès conflictuel et de partager des autorisations, cela ne fonctionnera pas. Mais s'il s'agit d'une base de données personnalisée, pourquoi auriez-vous besoin de plus d'une poignée de fichier ouverte? Votre logiciel de base de données personnalisée doit gérer les poignées ouvertes (avoir 1 par fichier). En ce qui concerne votre question spécifique, aucune limite définie, mais une ouverture ultérieure du fichier doit suivre les règles d'accès et de partage des autorisations.

http://msdn.microsoft. com / fr-nous / bibliothèque / aa363874% 28v = vs.85% 29.aspx


0 commentaires

0
votes

Vous ne devez avoir qu'un seul filestream pour écrire dans le fichier et limiter son utilisation à un fil à la fois en utilisant les mécanismes de verrouillage habituels. Le modèle habituel pour le logiciel DBMS est d'avoir une file d'attente simultanée d'opérations d'écriture et d'avoir un fil d'écriture qui les chasse. Dans les cas où vous avez besoin de la source de l'opération d'écriture pour attendre son achèvement, vous pouvez utiliser un modèle async (Begwewrite / Endwrite).

A SEMAPHORE peut être précisément ce dont vous avez besoin pour la lecture, car il permet un nombre maximal de threads d'y avoir accès à tout moment. Vous pouvez l'utiliser pour limiter le débattage de disque qui se produirait pour un nombre illimité de lecture aléatoire simultanée.

Cependant, vous devez toujours garder une cache des données "les plus chaudes" en mémoire pour réduire la charge. Sans cela, votre disque ne sera tout simplement pas assez rapide pour continuer.


0 commentaires

1
votes

Plusieurs objets peuvent accéder à un fichier unique, mais le disque sur lequel les fichiers sont sauvegardés maintiennent la mémoire tampon de cache de lecture pour chaque objet / processus et le cache se multiplierait avec le nombre d'objets accédant au fichier. La performance dépend de la quantité d'octets requis pour maintenir le cache par objets et une capacité totale de la mémoire cache.

Si le fichier est modifié lorsque le fonctionnement de la lecture est effectué, les lectures asynchrones doivent être utilisées. Toutefois, si un processus se termine par une partie d'un fichier verrouillé ou ferme un fichier comportant des verrous exceptionnels, le comportement est indéfini.

Je recommanderais de détruire explicitement les objets de flux lorsqu'ils ne sont pas nécessaires.


0 commentaires

0
votes

Ouverture d'un fichier signifie normalement qu'il est ouvert exclusivement par vous et qu'aucun autre processus ne peut y accéder, à moins que vous soyez Windows que vous souhaitez le partager.

Réglage des fichiers FileShare.Read/Write signifie que vous accordez d'autres processus le droit de lire ou d'écrire le fichier pendant que vous l'avez ouvert.

Je regarde: vous accordez d'autres processus le droit de lire et / ou d'écrire dans votre fichier. Rien de plus, rien de moins.

Imaginons les bits de partage de fichiers comme une porte:

  • aucun signifie, la porte est fermée et verrouillée.
  • Lire signifie que vous ne pouvez aller qu'un seul moyen.
  • écriture signifie, vous ne pouvez aller que dans l'autre sens.

    Alors, quelle est la limite d'une porte?


0 commentaires

2
votes

Je ne connais pas la limite exacte imposée par .NET / Windows, j'ai donc créé un vrai test pour vous. J'ai exécuté le code de test suivant pendant quelques minutes et j'ai trouvé cela jusqu'à 635908 strong> Nombre de comptes System.IO.Fileshare code> Utilisation, il est toujours fonctionnel, c'est-à-dire que vous pouvez toujours lire l'appartement Contenu du fichier de base de données.

Voici le code (c'est une application Winform, .NET 4): P>

Public Class Form1

    Private Sub Button1_Click(sender As System.Object, e As System.EventArgs) Handles Button1.Click
        Dim filepath As String = "c:\database.txt"

        Dim filestream As System.IO.FileStream

        Dim count As Int32

        For count = 0 To System.Int32.MaxValue
            filestream = New System.IO.FileStream(filepath, System.IO.FileMode.Open, System.IO.FileAccess.Read, System.IO.FileShare.Read)
            AppendLog(count, filestream.ReadByte)
        Next
    End Sub

    Private LogFilepath As String = "C:\LogInfo.txt"
    Private Enter As String = Chr(13) & Chr(10)
    Private Space As String = " "

    Private Sub AppendLog(ByVal Sequence As Int32, ByVal info As Byte)
        System.IO.File.AppendAllText(LogFilepath, Enter & Sequence & Space & CStr(info))
    End Sub

End Class


0 commentaires