diff --git a/apps/docs/content/guides/queues/pgmq.mdx b/apps/docs/content/guides/queues/pgmq.mdx index 41dfd52550d..9e057e84368 100644 --- a/apps/docs/content/guides/queues/pgmq.mdx +++ b/apps/docs/content/guides/queues/pgmq.mdx @@ -20,9 +20,9 @@ create extension pgmq; ## Usage [#get-usage] -### Queue Management +### Queue management -#### create +#### `create` Create a new queue. @@ -47,7 +47,7 @@ select from pgmq.create('my_queue'); -------- ``` -#### create_unlogged +#### `create_unlogged` Creates an unlogged table. This is useful when write throughput is more important that durability. See Postgres documentation for [unlogged tables](https://www.postgresql.org/docs/current/sql-createtable.html#SQL-CREATETABLE-UNLOGGED) for more information. @@ -75,7 +75,7 @@ select pgmq.create_unlogged('my_unlogged'); --- -#### detach_archive +#### `detach_archive` Drop the queue's archive table as a member of the PGMQ extension. Useful for preventing the queue's archive table from being drop when `drop extension pgmq` is executed. This does not prevent the further archives() from appending to the archive table. @@ -102,7 +102,7 @@ select * from pgmq.detach_archive('my_queue'); --- -#### drop_queue +#### `drop_queue` Deletes a queue and its archive table. @@ -128,9 +128,9 @@ select * from pgmq.drop_queue('my_unlogged'); t ``` -### Sending Messages +### Sending messages -#### send +#### `send` Send a single message to a queue. @@ -164,7 +164,7 @@ select * from pgmq.send('my_queue', '{"hello": "world"}'); --- -#### send_batch +#### `send_batch` Send 1 or more messages to a queue. @@ -203,9 +203,9 @@ select * from pgmq.send_batch( --- -### Reading Messages +### Reading messages -#### read +#### `read` Read 1 or more messages from a queue. The VT specifies the delay in seconds between reading and the message becoming invisible to other consumers. @@ -242,7 +242,7 @@ select * from pgmq.read('my_queue', 10, 2); --- -#### read_with_poll +#### `read_with_poll` Same as read(). Also provides convenient long-poll functionality. When there are no messages in the queue, the function call will wait for `max_poll_seconds` in duration before returning. @@ -282,7 +282,7 @@ select * from pgmq.read_with_poll('my_queue', 1, 1, 5, 100); --- -#### pop +#### `pop` Reads a single message from a queue and deletes it upon read. @@ -312,9 +312,9 @@ pgmq=# select * from pgmq.pop('my_queue'); --- -### Deleting/Archiving Messages +### Deleting/Archiving messages -#### delete (single) +#### `delete` (single) Deletes a single message from a queue. @@ -343,7 +343,7 @@ select pgmq.delete('my_queue', 5); --- -#### delete (batch) +#### `delete` (batch) Delete one or many messages from a queue. @@ -384,7 +384,7 @@ select * from pgmq.delete('my_queue', array[6, 999]); --- -#### purge_queue +#### `purge_queue` Permanently deletes all messages in a queue. Returns the number of messages that were deleted. @@ -413,7 +413,7 @@ select * from pgmq.purge_queue('my_queue'); --- -#### archive (single) +#### `archive` (single) Removes a single requested message from the specified queue and inserts it into the queue's archive. @@ -445,7 +445,7 @@ select * from pgmq.archive('my_queue', 1); --- -#### archive (batch) +#### `archive` (batch) Deletes a batch of requested messages from the specified queue and inserts them into the queue's archive. Returns an array of message ids that were successfully archived. @@ -489,7 +489,7 @@ select * from pgmq.archive('my_queue', array[4, 999]); ### Utilities -#### set_vt +#### `set_vt` Sets the visibility timeout of a message to a specified time duration in the future. Returns the record of the message that was updated. @@ -524,7 +524,7 @@ select * from pgmq.set_vt('my_queue', 11, 30); --- -#### list_queues +#### `list_queues` List all the queues that currently exist. @@ -553,7 +553,7 @@ select * from pgmq.list_queues(); --- -#### metrics +#### `metrics` Get metrics for a specific queue. @@ -599,7 +599,7 @@ select * from pgmq.metrics('my_queue'); --- -#### metrics_all +#### `metrics_all` Get metrics for all existing queues. @@ -638,7 +638,7 @@ select * from pgmq.metrics_all(); ### Types -#### message_record +#### `message_record` The complete representation of a message in a queue. diff --git a/apps/docs/content/guides/realtime/benchmarks.mdx b/apps/docs/content/guides/realtime/benchmarks.mdx index 9a12182df42..8c97310b349 100644 --- a/apps/docs/content/guides/realtime/benchmarks.mdx +++ b/apps/docs/content/guides/realtime/benchmarks.mdx @@ -26,7 +26,7 @@ The benchmarking results include the following workloads: ## Results -### Realtime Broadcast Performance +### Realtime broadcast performance This workload evaluates the system's capacity to handle multiple concurrent WebSocket connections and message broadcasting. Each virtual user (VU) in the test: @@ -51,7 +51,7 @@ This workload evaluates the system's capacity to handle multiple concurrent WebS | New Connection Rate | 320 conn/sec | | Channel Join Rate | 640 joins/sec | -### Payload Size Impact +### Payload size impact This workload tests the system's performance with different message payload sizes to understand how data volume affects throughput and latency. Each virtual user (VU) follows the same connection pattern as the broadcast test, but with varying message sizes: @@ -62,15 +62,15 @@ This workload tests the system's performance with different message payload size - Sends messages with payloads of 1KB, 10KB, and 50KB - Generates traffic by sending 2 messages per second to each joined channel for 5 minutes -#### 1KB Payload +#### 1KB payload ![1KB Payload Broadcast Performance](/docs/img/guides/realtime/payload-size-1kb.png) -#### 10KB Payload +#### 10KB payload ![10KB Payload Broadcast Performance](/docs/img/guides/realtime/payload-size-10kb.png) -#### 50KB Payload +#### 50KB payload ![50KB Payload Broadcast Performance](/docs/img/guides/realtime/payload-size-50kb-small.png) @@ -86,7 +86,7 @@ This workload tests the system's performance with different message payload size > Note: The final column shows results with reduced load (2,000 users) for the 50KB payload test, demonstrating how the system performs with larger payloads under different concurrency levels. -### Large-Scale Broadcasting +### Large-Scale broadcasting This workload demonstrates Realtime's capability to handle high-scale scenarios with a large number of concurrent users and broadcast channels. The test simulates a scenario where each user participates in group communications with periodic message broadcasts: diff --git a/apps/docs/content/troubleshooting/monitor-supavisor-postgres-connections.mdx b/apps/docs/content/troubleshooting/monitor-supavisor-postgres-connections.mdx index 1d1e733344e..c202f6509bb 100644 --- a/apps/docs/content/troubleshooting/monitor-supavisor-postgres-connections.mdx +++ b/apps/docs/content/troubleshooting/monitor-supavisor-postgres-connections.mdx @@ -20,7 +20,7 @@ It can be run locally within Docker. Alternatively, you can deploy it to fly.io Installation instructions can be found in it the [metrics docs ](/docs/guides/platform/metrics#deploying-supabase-grafana) -## Observing Connections +## Observing connections In Supabase Grafana, the "Client Connections" graph shows connections to both Supavisor and Postgres ![image](https://github.com/supabase/supabase/assets/91111415/141b8e01-9aae-4544-818c-acb47371ef3b) @@ -28,7 +28,7 @@ In Supabase Grafana, the "Client Connections" graph shows connections to both Su - **Yellow**: The yellow line represents the number of actively querying and idle connections to the Supavisor Pooler. - **Green**: The green line represents the total number of actively querying and idle direct connections to the database. -## Investigating Connection Sources +## Investigating connection sources `pg_stat_activity` is a `VIEW` that keeps track of processes being run by your database, including connections. It's particularly useful for determining if idle clients are hogging connection slots. @@ -76,7 +76,7 @@ If you believe a connection should be killed, you can do so by running the follo where pid = ; ``` -## Managing the Supavisor Pooler: +## Managing the Supavisor pooler: The Supavisor Pooler is an intermediary between your clients (application servers) and the database. In transaction mode (port 6543), it can enable Postgres to share single connections with many clients, only allowing access when a query is pending. This prevents idle clients from hogging a direct connection and allows for more throughput. @@ -87,7 +87,7 @@ The general rule is that if you are using the PostgREST database API, you should These numbers are generalizations and assume a certain level of activity from all connected servers. The actual values depend on your peak connection usage. For instance, if you were only using 80 connections in a week period and your database could support 500 connections, then realistically you could allocate the remaining 420 (minus a reasonable buffer) to service more demand. -## Secondary Issues: +## Secondary issues: When managing Postgres, outside of connections, there are generally 3 likely bottlenecks (links to address each):