-
Notifications
You must be signed in to change notification settings - Fork 279
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PoC for external calls via HTTP/POST+JSON #1694
Closed
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
so that others can be horrified.
@garypen your pull request is missing a changelog! |
Inefficient: - lots of data being copied in and out of rhai - spawns a thread and a runtime for each call I'll work on versions that eliminate both of these problems.
As an alternative to the http_plugin, you can also write a simple rhai script that does the same thing. Arguably more useful because it gives you the ability to tinker with data before and after the call if you like.
to make it more complete.
It's probably not going to be contended, but might as well...
also lower the tracing level to debug
@garypen, please add a |
Conclude that doing this via config is a bad idea, but doing it through rhai is still viable. This commit: - deletes the http-plugin. - adds support for all pipeline stages - adds support for externalizing headermaps - improves error handling
error message had changed with new testing functionality
This is a major step forward from the last version, since the external processing is now async (checkpoint_async) and the call_external() function has been removed (because it was blocking). I've also started to break down the massive rhai.rs file into smaller components. I've broken out tests and macros so far. I intend to do more clean up and break out: - ServiceStep - Plugin - Error modules and perhaps more... If you look at the new rhai example, you can see what things would look like for a rhai programmer using this new capability.
Closing since this was delivered via |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
DO NOT MERGE UNDER ANY CIRCUMSTANCES
PoC for external calls via HTTP/POST+JSON payloads via
rhai
extension methodI've done some fairly unscientific comparative benchmarking on my laptop to give a rough indication of the overhead of the current implementation.
Experiment: Send
to an "echo" server which does nothing to the payload but echo it back to the router.
hey
was used for driving load. Configured as:Without External:
Memory: 85MB
CPU: 484
./HEY.local
Summary:
Total: 60.0044 secs
Slowest: 0.1302 secs
Fastest: 0.0005 secs
Average: 0.0060 secs
Requests/sec: 24631.3440
Response time histogram:
0.001 [1] |
0.014 [996137] |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
0.026 [3095] |
0.039 [509] |
0.052 [157] |
0.065 [41] |
0.078 [28] |
0.091 [18] |
0.104 [9] |
0.117 [4] |
0.130 [1] |
Latency distribution:
10% in 0.0026 secs
25% in 0.0031 secs
50% in 0.0037 secs
75% in 0.0046 secs
90% in 0.0057 secs
95% in 0.0066 secs
99% in 0.0095 secs
Details (average, fastest, slowest):
DNS+dialup: 0.0000 secs, 0.0005 secs, 0.1302 secs
DNS-lookup: 0.0000 secs, 0.0000 secs, 0.0000 secs
req write: 0.0000 secs, 0.0000 secs, 0.0083 secs
resp wait: 0.0059 secs, 0.0003 secs, 0.1301 secs
resp read: 0.0001 secs, 0.0000 secs, 0.0447 secs
Status code distribution:
[200] 1000000 responses
With External (echo to local server):
Memory: 95MB
CPU: 300
garypen@Garys-MBP TV2_load % ./HEY.local
Summary:
Total: 60.0057 secs
Slowest: 0.2101 secs
Fastest: 0.0017 secs
Average: 0.0113 secs
Requests/sec: 8838.8037
Response time histogram:
0.002 [1] |
0.023 [523684] |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
0.043 [6530] |
0.064 [63] |
0.085 [1] |
0.106 [0] |
0.127 [0] |
0.148 [0] |
0.168 [0] |
0.189 [0] |
0.210 [100] |
Latency distribution:
10% in 0.0071 secs
25% in 0.0086 secs
50% in 0.0106 secs
75% in 0.0132 secs
90% in 0.0163 secs
95% in 0.0184 secs
99% in 0.0233 secs
Details (average, fastest, slowest):
DNS+dialup: 0.0000 secs, 0.0017 secs, 0.2101 secs
DNS-lookup: 0.0000 secs, 0.0000 secs, 0.0000 secs
req write: 0.0000 secs, 0.0000 secs, 0.0049 secs
resp wait: 0.0113 secs, 0.0016 secs, 0.2065 secs
resp read: 0.0000 secs, 0.0000 secs, 0.0100 secs
Status code distribution:
[200] 530379 responses
Summary: 1000000 Txns without external calls, 530379 with them.
Without: median response time: 0.014ms
With: median response time: 0.023ms
Which implies, that on average, the externalisation process adds about 1ms to the transaction time. That's a reasonable expectation of a lower bound on externalisation. Most external processes will do more than just echo back the payload...