Casbin

Casbin

  • Docs
  • API
  • Editor
  • IDE Plugins
  • Single Sign-On (SSO)
  • Forum
  • Help
  • Blog
  • Pricing
  • Contact Sales
  • Languages iconEnglish
    • 中文
    • 한국어
    • Русский
    • Français
    • Deutsch
    • 日本語
    • Help Translate
  • GitHub

›Advanced Usage

The Basics

  • Overview
  • Get Started
  • How it Works
  • Tutorials

Model

  • Supported Models
  • Syntax for Models
  • Effector
  • Function
  • RBAC
  • RBAC with Pattern
  • RBAC with Domains
  • Casbin RBAC v.s. RBAC96
  • ABAC
  • Priority Model
  • Super Admin

Storage

  • Model Storage
  • Policy Storage
  • Policy Subset Loading

Extensions

  • Enforcers
  • Adapters
  • Watchers
  • Dispatchers
  • Role Managers
  • Middlewares
  • GraphQL Middlewares
  • Cloud Native Middlewares

API

  • API Overview
  • Management API
  • RBAC API
  • RBAC with Domains API
  • RoleManager API
  • Data Permissions

Advanced Usage

  • Multi-threading
  • Benchmarks
  • Performance Optimization
  • Authorization of Kubernetes
  • Authorization of Service Mesh through Envoy

Management

  • Admin Portal
  • Casbin Service
  • Log & Error Handling
  • Frontend Usage

Editor

  • Online Editor
  • IDE Plugins

More

  • Our Adopters
  • Contributing
  • Privacy Policy
  • Terms of Service
Edit

Performance Optimization

When applied in a production environment with millions of users or permissions, you may encounter performance downgrade in Casbin enforcement, there are usually two causes:

High Volume Traffic

The number of coming requests per second is too large, e.g., 10,000 request/s for a single Casbin instance. In such case, a single Casbin instance is usually not enough to handle all the requests. There are 2 possible solutions:

  1. Use multi-threading to enable multiple Casbin instances, so you can fully utilize all the cores in the machine. See details at: Multi-threading.

  2. Deploy Casbin instances to a cluster (multiple machines). Use Watcher to guarantee all Casbin instances are consistent. See details at: Watchers.

note

You can use the above methods both at the same time, e.g., deploy Casbin to a 10-machine cluster. Each machine has 5 threads simultaneously to serve Casbin enforcement requests.

High Number of Policy Rules

Millions of policy rules may be required in a cloud or multi-tenant environment. Each enforcement call or even loading the policy rules at the initial time is very slow. Such cases can usually be mitigated in several ways:

  1. Your Casbin model or policy is not well-designed. A well-written model and policy will abstract out the duplicated logic for each user/tenant and reduce the number of rules to a very small level (< 100): e.g., you can share some default rules across all tenants and let users customize their rules later. Customized rules can override the default rules. If you still have question, please send GitHub issue to the Casbin repos.

  2. Do sharding to let a Casbin enforcer only load a small set of policy rules, e.g., enforcer_0 only serves for tenant_0 to tenant_99, enforcer_1 only serves for tenant_100 to tenant_199. To load only a subset of all policy rules, see details at: Policy Subset Loading.

  3. Grant permissions to RBAC roles instead of users directly. Casbin's RBAC is implemented by a role inheritance tree (as a cache). So given a user like Alice, Casbin only uses O(1) time to query the RBAC tree for role-user relationship and do enforcement. If your g rules don't change often, then the RBAC tree won't need to update. See details at this dicussion: https://github.com/casbin/casbin/issues/681#issuecomment-763801583

note

You can try the above methods all at the same time.

Last updated on 11/28/2022
← BenchmarksAuthorization of Kubernetes →
Casbin
Docs
Getting StartedManagement APIRBAC APIMiddlewares
Community
Who's using Casbin?Stack Overflow
Casbin          jCasbin
Node-Casbin   PHP-CasbinPyCasbin          Casbin.NETCasbin-CPP        Casbin-RS
Follow @casbinHQ
Copyright © 2022 Casbin Organization