Skip to content

Performance & Threading for AuditLog create_event #335

@danielduan

Description

@danielduan

The use case for this API call seems to revolve around recording that a resource has been accessed by a user. The current implementation of WorkOS::AuditLogs.create_event blocks the execution thread and delays the response until the audit trail has been logged.

It would be nice to have a create_event_async where the SDK could perform the call on a separate thread, or to default that API to async. This would shave off 200-500ms off our backend APIs.

We will try to mitigate this on our end and see if we can manage the threading. Maybe this would be good to mention in the documentation as well in lieu of any SDK changes.

I'm also very curious why this API call performs so poorly. We are seeing an average of 240ms on this with p95 of 450ms.
Screenshot 2024-11-19 at 5 18 44 PM

event = {
      action: action,
      occurred_at: Time.now.utc.iso8601,
      actor: {
        id: workos_user,
        type: "user"
      },
      context: {
        location: request.remote_ip,
        user_agent: request.user_agent
      },
      targets: targets
    }


WorkOS::AuditLogs.create_event(
      organization: workos_org_id,
      event: event

wrapping the actual API call in a Thread.new seems to at least take it of the main execution thread so it's not blocking the render:

Thread.new do
      WorkOS::AuditLogs.create_event(
        organization: workos_org_id,
        event: event
      )
end

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions