YetaWF.Caching Package

The YetaWF.Caching assembly/package implements the following low-level data providers:

• File and folder I/O
• Caching
• Locking
• PubSub Messaging

Applications do not access the low-level data providers in this package directly. Caching, locking and publish/subscribe services provided by YetaWF.Core.IO.Caching and file system services provided by YetaWF.Core.IO.FileSystem, YetaWF.Core.IO.DataFilesProvider and YetaWF.Core.IO.FileIO<TObj> should be used instead.

Depending on AppSettings.json settings, low-level data providers for single- or multi-instance sites are used.

Single-Instance Sites

A single-instance site is one single instance of the site, usually running in IIS or Docker. This is the typical use case for small to mid-size sites.

Multi-Instance Sites (Web Farm, Web Garden)

A multi-instance site runs multiple instances of the site in one instance of IIS/Docker on one server (web garden) or on multiple IIS/Docker instances on multiple servers (web farm). For multi-instance sites, Redis, SQL or PostgreSQL is used to implement caching services. Locking services use files or Redis to implement resource locking.

Multiple instances of a YetaWF site are rarely needed unless your site needs the utmost in availability and scalability. This is only accomplished by running multiple instances of the site on multiple servers in a web farm. Running multiple site in a web garden configuration (i.e., on one server with multiple instances in IIS/Docker) does not provide the availability, nor does it scale well as still only one server does all the work.

Running a web farm is not trivial, and you'll need to set up load balancers (not covered here). For caching/locking you'll need either SQL, PostgreSQL or Redis. For SQL and PostgreSQL it is sufficient to create a database and set the connection strings in AppSettings.json. YetaWF will create the necessary tables during initialization. For better performance, Redis is recommended. For information about setting up a Redis server see https://redis.io/.

When starting up the very first node of a multi-instance site, an empty file "FirstNode.txt" must be added to the ./Website folder. This is absolutely crucial to insure proper initialization of the site as a multi-instance site. Additional instances can then simply be started up (or shut down) at any time. Even the first node that was started can be recycled at any time. The first node that was started has no special attributes that require it to remain running.

When making certain Site Settings changes that would affect all sites, these may not take effect until the entire site is restarted (all nodes) and a first node is started with an empty file "FirstNode.txt". Very few actions require a restart. For example, changing the domain name or the CDN Url would require a full restart. Adding/changing pages or module content never requires a restart.

Admin > Dashboard > Audit Information (standard YetaWF site) can be used to determine whether a restart is pending.

AppSettings.json

AppSettings.json uses the following section to configure the YetaWF.Caching package:

{
  "Application": {
    "P": {
      "YetaWF_Caching": {
        "Distributed": {true|false},
        "CacheProvider": {"SQL"|"PostgreSQL"|"Redis"|"Local"},
        "LockProvider": {"File"|"Redis"},
        "PubSubProvider": {"File"|"Redis"},

        "RedisCacheConfig": "...your config...localhost:6379",
        "RedisLockConfig": "...your config...localhost:6379",
        "RedisKeyPrefix": "...some key prefix... _",
        "RedisPubSubConfig": "...your config...localhost:6379",
        "RedisPubSubPrefix":  "...some key prefix... _",

        "SQLDbo": "dbo",
        "SQLConnect": "Data Source=...datasource...;Initial Catalog=...catalog...;User ID=..userid...;Password=...password...",

        "PostgreSQLSchema": "public",
        "PostgreSQLConnect": "Host=...;Port=...;Username=...;Password=...;Database=...",

        "FileLockFolder": "..path to folder where locks are recorded (within ./Website folder)..",

        "TempRootFolder": "..path to a folder for temporary files..",

        "SmallObjectCacheDuration": { 0 | -1 | n }
      },
    }
  }
}

AppSettings.json Examples

Multi-Instance Site (SQL)

{
  "Application": {
    "P": {
      "YetaWF_Caching": {
        "Distributed": true,
        "CacheProvider": "SQL",
        "LockProvider": "File",
        "SQLDbo": "dbo",
        "SQLConnect": "Data Source=...datasource...;Initial Catalog=...catalog...;User ID=..userid...;Password=...password..."
      },
    }
  }
}

Multi-Instance Site (Redis)

{
  "Application": {
    "P": {
      "YetaWF_Caching": {
        "Distributed": true,
        "CacheProvider": "Redis",
        "LockProvider": "Redis",
        "RedisCacheConfig": "localhost:6379",
        "RedisLockConfig": "localhost:6379",
      },
    }
  }
}

Single Instance Site

A single-instance site does not use distributed caching or a shared file systems and offers the best performance.

{
  "Application": {
    "P": {
      "YetaWF_Caching": {
        "Distributed": false,
      }
    }
  }
}

See Also YetaWF.Core

Documentation Feedback
© 2023 - Softel vdm, Inc. - YetaWF.com