Download the PHP package automattic/sliding-window-counter without Composer
On this page you can find all versions of the php package automattic/sliding-window-counter. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download automattic/sliding-window-counter
More information about automattic/sliding-window-counter
Files in automattic/sliding-window-counter
Package sliding-window-counter
Short Description Sliding window counter
License GPL-2.0-or-later
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package sliding-window-counter
Sliding Window Counter
What's this all about?
We needed a way to have arbitrary short-lived time series. For example, to tackle a messaging spam problem, we would like to know if the number of statistically suspicious messages sent by users connecting from a specific range of IP addresses exceeds previously observed numbers.
We can use a time series built from logs or database entries to work around this. It requires having a log or a database in the first place, not to mention that calculating the necessary statistics on every request could be expensive. We could back the calculation with a cache, but why don't we use the in-memory cache in the first place? That's what we are going for here.
First, we need to solve the input side of the problem. To do that, we divide the time into equal chunks and record events falling into matching periods. And we have to include the observation period and the window size in the cache key to ensure we don't accidentally reuse numbers from another time series. Straightforward as it is.
The slightly more complicated part is to assemble everything back. Let's agree on the following terminology:
- A frame is a window-long period of time.
- The material frame is a frame that matches the data stored in the cache to the last second.
- The logical frame is a window-long frame aligned to the current time but not necessarily aligned to the cache data.
It is all straightforward if the current time is aligned with the material frame boundary. Take what you have in the cache, and presto!
But if logical and material frames are not aligned (the end of the last material frame could be twenty seconds ago, and the logical frame is always now), we are up for some extrapolation.
- To extrapolate the value for the most recent logical frame, we can take a portion of the previous material frame and the full value of the most recent material frame. This post on Cloudflare's blog explains it beautifully.
- And we use portions of underlying material frames for every other logical frame.
And there are many edge cases: for example, if we don't specify the anomaly detection start time, we discard all heading null values. But for relatively rare events, it might make sense to keep every empty frame, so there's an option to specify the start time.
The API
Here's how it should be used:
And at some later point in time
There's also a handy adapter for the Memcached-backed WP_Object_Cache:
