| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
rest seem honestly reasonable. no huge red flags anymore.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds:
mcp.active_req_limit(count)
mcp.buffer_memory_limit(kilobytes)
Divides by the number of worker threads and creates a per-worker-thread
limit for the number of concurrent proxy requests, and how many bytes
used specifically for value bytes. This does not represent total memory
usage but will be close.
Buffer memory for inbound set requests is not accounted for until after
the object has been read from the socket; to be improved in a future
update. This should be fine unless clients send just the SET request and
then hang without sending further data.
Limits should be live-adjustable via configuration reloads.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
have a bug where updating a token and then requesting it again returns
the previous token. Also have other branches which require use of the
flattened request.
Removes the extra allocation space for lua request objects as we're not
flattening into the end of the memory.
I was originally doing this using a lot of lua but just copying the
string a few times has some better properties:
1) should actually be faster with less lua + fewer allocations
2) can be optimized to do minimal copying (avoid keys, append new flags,
etc)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Originally I envisioned taking an inbound request object, tagging it
with the time, and at the very end of a function logging is called. This
would give you the total time of the "backend" part of a request.
On rethinking, the timing information that's most useful in the proxy's
perspective is the time it takes for a response to happen + the status
of a response. One request may generate several sub-responses and it is
impossible to check the timing of each of those and log outliers.
You now cannot get the total time elapsed in a function anymore, but I
believe that is less useful information to the user of a proxy. The best
picture of latency will still be from the client, and response latency
can educate the proxy on issues with backends.
resp:elapsed() has been added as a compromise; it returns the elapsed
microseconds that a response took, so you can add the time together and
get an approximation of total time (if running req/resp's sequentially).
This change also means that calling mcp.await() and waiting for multiple
responses will give the timing of each sub-response accurately.
|
| |
|
|
|
|
| |
returns (exists, previous_token)
optional second argument will replace the flag/token with supplied
flag/token, or nothing if "" is passed.
|
| |
|
|
|
|
|
| |
in the request parser the new endcap token was always the end of the
line, but it should be the start of the next token. For some use cases
the scanning stops early, or if we have too many tokens it would make
the final token look like the rest of the line.
|
| |
|
|
|
|
| |
function accepts a flag, returns (bool, token|nil).
bool indicates if the flag exists, and if the flag has a token it is
returned instead of nil as the second value.
|
| |
|
|
|
|
|
|
|
| |
Add mcp.request function for quick checking if a flag exists in a
request string.
Also updates internal code for checking the length of a token to use the
endcap properly, and uses that for the r:token(n) requets as well, which
fixes a subtle bug of the token length being too long.
|
| |
|
|
|
|
|
|
|
|
| |
- errors if a string value is missing the "\r\n" terminator
- properly uses a value from a response object
- allows passing in a request object for the value as well
- also adds r:vlen() for recovering the value length of a response
think this still needs r:flags() or similar?
|
| |
|
|
|
|
|
|
|
| |
mcplib_request_token() allows us to parse each token in a request string. The
existing implementation delimits tokens using <whitespace>. This approach
works for every token but the last one which will be followed by \r\n.
This patch uses the token offsets present within the request parser to calculate
the token boundaries instead of looping until the next delimiter.
|
| |
|
|
|
|
|
|
|
| |
mcp.request can now take a response object and internally copy the
value. bit faster than doing it through C.
iterating from here should allow taking a reference to the resp object
and directly pointing to its value, but we need to make resp objects
immutable first.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
avoids sending the response to the client, in most cases. works by
stripping the noreply status from the request before sending it along,
so the proxy itself knows when to move the request forward.
has sharp edges:
- only looking at the request object that's actually sent to the
backend, instead of the request object that created the coroutine.
- overriding tokens in lua to re-set the noreply mode would break the
protocol.
So this change helps us validate the feature but solidifying it requires
moving it to the "edges" of processing; before the coroutine and after
any command assembly (or within the command assembly).
|
|
|
now's a good time to at least shove functional subsections of code into
their own files. Some further work to clearly separate the API's will
help but looks not too terrible.
Big bonus is getting the backend handling code away from the frontend
handling code, which should make it easier to follow.
|
