# I am the Watcher. I am your guide through this vast new twtiverse.
#
# Usage:
# https://watcher.sour.is/api/plain/users View list of users and latest twt date.
# https://watcher.sour.is/api/plain/twt View all twts.
# https://watcher.sour.is/api/plain/mentions?uri=:uri View all mentions for uri.
# https://watcher.sour.is/api/plain/conv/:hash View all twts for a conversation subject.
#
# Options:
# uri Filter to show a specific users twts.
# offset Start index for quey.
# limit Count of items to return (going back in time).
#
# twt range = 1 7
# self = https://watcher.sour.is/conv/als7bsa
@prologic It is, but that’s just one of many factors at play here. It turned out that the system did not leave the stage of “loading plugins” for a long time. “Loading plugins” means: Read the plugin blobs from the PostgreSQL database (that’s where they’re stored) and put them somewhere in the filesystem (probably so that the Java VM can actually load them), probably also analyze the plugins in some way (I didn’t dig that deep). When finished, the resulting directory in the filesystem is a whopping 1.4 GB in size. Combine that with a CPU that’s way too slow, and voilà, it takes forever to start.
The “solution” was to move the system to another host which has a more powerful CPU. 🫤
(You might think that that’s a very large number of plugins, but rest assured, it’s quite normal. People love to install every plugin that they can find.)
@prologic It is, but that’s just one of many factors at play here. It turned out that the system did not leave the stage of “loading plugins” for a long time. “Loading plugins” means: Read the plugin blobs from the PostgreSQL database (that’s where they’re stored) and put them somewhere in the filesystem (probably so that the Java VM can actually load them), probably also analyze the plugins in some way (I didn’t dig that deep). When finished, the resulting directory in the filesystem is a whopping 1.4 GB in size. Combine that with a CPU that’s way too slow, and voilà, it takes forever to start.
The “solution” was to move the system to another host which has a more powerful CPU. 🫤
(You might think that that’s a very large number of plugins, but rest assured, it’s quite normal. People love to install every plugin that they can find.)
@prologic It is, but that’s just one of many factors at play here. It turned out that the system did not leave the stage of “loading plugins” for a long time. “Loading plugins” means: Read the plugin blobs from the PostgreSQL database (that’s where they’re stored) and put them somewhere in the filesystem (probably so that the Java VM can actually load them), probably also analyze the plugins in some way (I didn’t dig that deep). When finished, the resulting directory in the filesystem is a whopping 1.4 GB in size. Combine that with a CPU that’s way too slow, and voilà, it takes forever to start.
The “solution” was to move the system to another host which has a more powerful CPU. 🫤
(You might think that that’s a very large number of plugins, but rest assured, it’s quite normal. People love to install every plugin that they can find.)
@movq if the solution means just throw more hardware at the problem, then something is outright wrong.
that always happens.... \\_(:/)_/
@akoizumi Yep, something’s wrong. A *lot* is wrong. Don’t get me started. 🤣
@akoizumi Yep, something’s wrong. A *lot* is wrong. Don’t get me started. 🤣
@akoizumi Yep, something’s wrong. A *lot* is wrong. Don’t get me started. 🤣