Re: Fiber based HTTP client for load testing
On Thursday, 1 October 2020 at 00:35:49 UTC, Arun wrote:
I have a REST client that can do load test of my REST services.
It uses ikod's dlang-requests under the hood.
https://github.com/ikod/dlang-requests
At the moment I use a thread pool to dispatch the runtime
operation and send the requests to the server.
As seen, the downside is that the more threads we use the more
memory the app consumes. Is there a way to replace the threads
with fibers in this particular case so that instead of spawning
1000 threads, we spawn 1000 fibers with just 1 thread?
Hello, you can use requests with vibe.d sockets. You'll get the
idea from example:
---
dub.json:
{
"authors": [
"me"
],
"copyright": "Copyright © 2020, me",
"dependencies": {
"requests": "~>1.1.7",
"vibe-d": "~>0.9.2"
},
"description": "A minimal D application.",
"license": "proprietary",
"name": "t",
"subConfigurations": {
"requests": "vibed"
}
}
---
import vibe.core.core;
import vibe.core.log;
import requests;
static void workerFunc(string url)
{
logInfo("Param: %s", url);
Request rq;
rq.verbosity = 1;
auto rs=rq.get(url);
logInfo("response code: %s", rs.code);
}
void main()
{
auto urls = ["http://httpbin.org/;,
"http://httpbin.org/image;];
foreach(url; urls)
{
runWorkerTask(, url);
}
runApplication();
}
---
GET / HTTP/1.1
User-Agent: dlang-requests
Host: httpbin.org
Connection: Keep-Alive
Accept-Encoding: gzip,deflate
GET /image HTTP/1.1
User-Agent: dlang-requests
Host: httpbin.org
Connection: Keep-Alive
Accept-Encoding: gzip,deflate
< HTTP/1.1 200 OK
< date: Thu, 01 Oct 2020 03:07:33 GMT
< content-type: image/png
< content-length: 8090
< connection: keep-alive
< server: gunicorn/19.9.0
< access-control-allow-origin: *
< access-control-allow-credentials: true
< HTTP/1.1 200 OK
< date: Thu, 01 Oct 2020 03:07:33 GMT
< content-type: text/html; charset=utf-8
< content-length: 9593
< connection: keep-alive
< server: gunicorn/19.9.0
Connect time: 210 ms, 805 μs, and 9 hnsecs
Request send time: 293 μs and 2 hnsecs
Response recv time: 205 ms, 378 μs, and 9 hnsecs
< access-control-allow-origin: *
[vibe-6(ZLjs) INF] < access-control-allow-credentials: true
response code: 200
Connect time: 210 ms, 749 μs, and 6 hnsecs
Request send time: 307 μs and 6 hnsecs
Response recv time: 205 ms and 922 μs
[vibe-3(cfzw) INF] response code: 200
Re: Fiber based HTTP client for load testing
On 9/30/20 8:35 PM, Arun wrote: As seen, the downside is that the more threads we use the more memory the app consumes. Is there a way to replace the threads with fibers in this particular case so that instead of spawning 1000 threads, we spawn 1000 fibers with just 1 thread? Right on the main page, it says it can work with vibe.d. So that would be with fibers. How you create a fiber task for use in vibe.d I don't know. I've only ever used it with the web framework in mind. "just using fibers" isn't going to make it any faster. You still need an event framework to yield the fibers when they are waiting on i/o. -Steve
Fiber based HTTP client for load testing
I have a REST client that can do load test of my REST services.
It uses ikod's dlang-requests under the hood.
https://github.com/ikod/dlang-requests
At the moment I use a thread pool to dispatch the runtime
operation and send the requests to the server.
/// Iterates over the enum members and builds a switch case
statement at compile time.
/// If the input operation matches the case, the runtime
dispatches the corresponding
/// task pool with it's options.
auto pool = new TaskPool(options.threadCount);
foreach (_; 0 .. options.threadCount) {
foreach (__; 0 .. options.iterationCount) {
final switch (options.operation) {
foreach (e; EnumMembers!Operation) {
case e:
pool.put(mixin("task!" ~ e.to!string ~
"(options)"));
break;
}
}
}
}
pool.finish();
As seen, the downside is that the more threads we use the more
memory the app consumes. Is there a way to replace the threads
with fibers in this particular case so that instead of spawning
1000 threads, we spawn 1000 fibers with just 1 thread?
Re: What classification should shared objects in qeued thread pools have?
On Thursday, 1 October 2020 at 00:13:41 UTC, IGotD- wrote: I think that the shared in shared structs should not be transitive to members of the struct. The compiler should not Once the aggregate struct data is decl-ed `shared` as a whole, it needs to be transitive to play safe. The compiler (technology) is not that advanced enough to either prove that for a particular sub-component of a shared struct data is fine without protection, or the programmer's intention. enforce this as we don't really know what the programmer will do inside the struct to ensure the thread safety. If the programmer is really sure about his/her design, just cast() the `shared` away.
Re: What classification should shared objects in qeued thread pools have?
On Thursday, 1 October 2020 at 00:00:06 UTC, mw wrote: I think using `shared` is the D's encouraged way. If there is a better way do this in D, I'd want to know it too. I think that the shared in shared structs should not be transitive to members of the struct. The compiler should not enforce this as we don't really know what the programmer will do inside the struct to ensure the thread safety. For example completely lockless algorithms can often be a combination of atomic operations and also non-atomic operations on data members. I originally thought that DIP 1024 only applied for integer types alone (not inside structs). I don't really understand the rationale why a shared struct should all have atomic integers, it doesn't make any sense.
Re: What classification should shared objects in qeued thread pools have?
On Thursday, 1 October 2020 at 00:00:06 UTC, mw wrote: On Wednesday, 30 September 2020 at 20:13:47 UTC, IGotD- wrote: [...] I think declaring the container and item as `shared` is the D's encouraged way of sharing data among different threads. [...] then just cast the `shared` away: cast()data. [...] I think using `shared` is the D's encouraged way. If there is a better way do this in D, I'd want to know it too. BTW, this is what I learnt from my previous thread: https://forum.dlang.org/post/nlhjzafnmywrgkyjl...@forum.dlang.org
Re: What classification should shared objects in qeued thread pools have?
On Wednesday, 30 September 2020 at 20:13:47 UTC, IGotD- wrote: This where the memory model of D starts to become confusing for me. By default memory allocations/deallocation are not allowed between threads, however setting the object to shared circumvents this. This seems to work as there is no more aborts from the D memory management. However, this has a weird side I think declaring the container and item as `shared` is the D's encouraged way of sharing data among different threads. effect. Now the compiler wants that all my integer member variables operates by using atomic primitives. I don't need this, I know that this object will be sequentially used. then just cast the `shared` away: cast()data. Is shared the wrong way to go here and is there another way to solve this? I think using `shared` is the D's encouraged way. If there is a better way do this in D, I'd want to know it too.
What classification should shared objects in qeued thread pools have?
I have a system that heavily relies on thread pools. Typically this is used with items that are put on a queue and then a thread pool system process this queue. The thread pool can be configured to process the items in whatever parallel fashion it wants but usually it is set to one, that means no special protection for concurrency is needed as serialization is guaranteed. One item is processed at a time. So think that one item is being processed and then put on some kind of dynamic data structure. During this operation allocations and deallocations can happen. Because we have a thread pool, these memory operations can happen in different threads. This where the memory model of D starts to become confusing for me. By default memory allocations/deallocation are not allowed between threads, however setting the object to shared circumvents this. This seems to work as there is no more aborts from the D memory management. However, this has a weird side effect. Now the compiler wants that all my integer member variables operates by using atomic primitives. I don't need this, I know that this object will be sequentially used. Is shared the wrong way to go here and is there another way to solve this?
Re: vibe.de multiple ports.
On Wednesday, 30 September 2020 at 12:38:10 UTC, seany wrote:
On Wednesday, 30 September 2020 at 12:29:06 UTC, Daniel Kozak
wrote:
Dne st 30. 9. 2020 13:25 uživatel seany via
Digitalmars-d-learn < digitalmars-d-learn@puremagic.com>
napsal:
Hello
I am trying to use this example for a iot application:
https://aberba.com/2018/using-vibe-d-web-interface/
The code i use is:
ushort port = 5504;
void main(char[][] args)
{
auto router = new URLRouter;
router.post("/archive", );
router.get("/archive", );
auto settings = new HTTPServerSettings;
settings.port = port;
settings.bindAddresses = ["::1", "0.0.0.0"];
listenHTTP(settings, router);
runApplication();
}
This is fine. But now that we have ~ 100 IoT devices in the
field, I would like to assign each a new port.
Why? I do not see any reason for that.
to separate the messages from the IoT responses quickly and
forward them to different programs, and to have the capability
in hand, so that when later i have an idea to exploit the
capability, I can also do it.
What you are doing, if I understand you well, is a way of scaling
the server to handle high amount of traffic.
If that's right, then I'm not sure how the number of PORT is the
issue. Irrespective of the port, the server resources remains the
same.
And if that's the case, then you might need a load balancer (or
use nginx or any of the options I've used in my projects). In
that case, you run multiple versions of the server in stateless
environments... scaled up or down on demand.
Been a long while since I wrote some vibe.d tutorials though :)
Re: Deprecation in traits
On Wednesday, 30 September 2020 at 18:18:48 UTC, Basile B. wrote: On Tuesday, 29 September 2020 at 17:08:40 UTC, Frak wrote: Hi folks, I've this: /Users/frak/dlang/ldc-1.23.0/bin/../import/std/traits.d(3711): Deprecation: function `std.typecons.Nullable!long.Nullable.get_` is deprecated - Implicit conversion with `alias Nullable.get this` will be removed after 2.096. Please use `.get` explicitly. I'm trying to find out WHERE this is generated to fix it, dependency included, without success. Suggestions? The problem has been observed already and it is an official enhancement request [1]. I think it is legit because deprecation are sometimes used to help into refactoring, so to have the use site is a essential. [1] https://issues.dlang.org/show_bug.cgi?id=21176 Does compiling with -v help? I think it might at least show you which module the issue is coming from?
Re: Deprecation in traits
On Tuesday, 29 September 2020 at 17:08:40 UTC, Frak wrote: Hi folks, I've this: /Users/frak/dlang/ldc-1.23.0/bin/../import/std/traits.d(3711): Deprecation: function `std.typecons.Nullable!long.Nullable.get_` is deprecated - Implicit conversion with `alias Nullable.get this` will be removed after 2.096. Please use `.get` explicitly. I'm trying to find out WHERE this is generated to fix it, dependency included, without success. Suggestions? The problem has been observed already and it is an official enhancement request [1]. I think it is legit because deprecation are sometimes used to help into refactoring, so to have the use site is a essential. [1] https://issues.dlang.org/show_bug.cgi?id=21176
Re: vibe.de multiple ports.
On Wed, Sep 30, 2020 at 2:40 PM seany via Digitalmars-d-learn <
digitalmars-d-learn@puremagic.com> wrote:
> On Wednesday, 30 September 2020 at 12:29:06 UTC, Daniel Kozak
> wrote:
>
> to separate the messages from the IoT responses quickly and
> forward them to different programs, and to have the capability in
> hand, so that when later i have an idea to exploit the
> capability, I can also do it.
>
Ok as Adam said you can do something like this:
void main()
{
immutable ushort startPort = 5500;
import std.range : iota;
foreach (ushort port; iota!(ushort,ushort)(startPort, startPort + 100))
{
auto settings = new HTTPServerSettings;
settings.port = port;
settings.bindAddresses = ["::1", "127.0.0.1"];
listenHTTP(settings, );
}
runApplication();
}
void hello(HTTPServerRequest req, HTTPServerResponse res)
{
import std.conv : to;
res.writeBody(req.fullURL.port.to!string);
}
Re: Deprecation in traits
On Wednesday, 30 September 2020 at 09:42:40 UTC, Stefan Koch wrote: On Wednesday, 30 September 2020 at 08:33:58 UTC, Frak wrote: On Tuesday, 29 September 2020 at 18:25:03 UTC, Steven Schveighoffer wrote: On 9/29/20 1:08 PM, Frak wrote: [...] Because it's probably coming from a constraint, you probably can't figure out the exact usage. What's more annoying is that likely it is a spurious warning. A lot of traits "try something", and then alias to false or true depending on what works. But it's not going to make a difference in your code. It's one of the most annoying things in the library. If you see this warning coming from *your* code, then you should fix it. But it will tell you the location if that was the case, not std.traits. -Steve That's REALLY REALLY annoying! I'm spending LOT of time trying to figure out the exact point to fix in the code. Any idea? dustmite? You can give me access to the code and I can find it out for you. That's the best I have. Thank you, but unfortunately that's not possible
Re: vibe.de multiple ports.
On Wednesday, 30 September 2020 at 11:23:59 UTC, seany wrote:
auto router = new URLRouter;
router.post("/archive", );
router.get("/archive", );
auto settings = new HTTPServerSettings;
settings.port = port;
settings.bindAddresses = ["::1", "0.0.0.0"];
listenHTTP(settings, router);
If you loop this section it should listen to each port. This is
just a setup loop, it wouldn't actually be wasteful once it is
running.
(I think, I don't really know vibe super well)
Re: vibe.de multiple ports.
On Wednesday, 30 September 2020 at 12:29:06 UTC, Daniel Kozak
wrote:
Dne st 30. 9. 2020 13:25 uživatel seany via Digitalmars-d-learn
< digitalmars-d-learn@puremagic.com> napsal:
Hello
I am trying to use this example for a iot application:
https://aberba.com/2018/using-vibe-d-web-interface/
The code i use is:
ushort port = 5504;
void main(char[][] args)
{
auto router = new URLRouter;
router.post("/archive", );
router.get("/archive", );
auto settings = new HTTPServerSettings;
settings.port = port;
settings.bindAddresses = ["::1", "0.0.0.0"];
listenHTTP(settings, router);
runApplication();
}
This is fine. But now that we have ~ 100 IoT devices in the
field, I would like to assign each a new port.
Why? I do not see any reason for that.
to separate the messages from the IoT responses quickly and
forward them to different programs, and to have the capability in
hand, so that when later i have an idea to exploit the
capability, I can also do it.
Re: vibe.de multiple ports.
Dne st 30. 9. 2020 13:25 uživatel seany via Digitalmars-d-learn <
digitalmars-d-learn@puremagic.com> napsal:
> Hello
>
> I am trying to use this example for a iot application:
> https://aberba.com/2018/using-vibe-d-web-interface/
>
> The code i use is:
>
> ushort port = 5504;
>
> void main(char[][] args)
> {
>
> auto router = new URLRouter;
> router.post("/archive", );
> router.get("/archive", );
>
> auto settings = new HTTPServerSettings;
> settings.port = port;
> settings.bindAddresses = ["::1", "0.0.0.0"];
> listenHTTP(settings, router);
>
> runApplication();
> }
>
>
> This is fine. But now that we have ~ 100 IoT devices in the
> field, I would like to assign each a new port.
>
Why? I do not see any reason for that.
>
Re: Trying to create a trivial 64 bit D Lang DLL on a Windows 10 machine and cant get past linking.
On Tuesday, 29 September 2020 at 21:22:21 UTC, WhatMeWorry wrote:
module user;
export { int myAddSeven(int a, int b); }
[...]
it is better to use this template
https://github.com/dlang/dmd/tree/master/samples/mydll
You don't have a DllMain.
vibe.de multiple ports.
Hello
I am trying to use this example for a iot application:
https://aberba.com/2018/using-vibe-d-web-interface/
The code i use is:
ushort port = 5504;
void main(char[][] args)
{
auto router = new URLRouter;
router.post("/archive", );
router.get("/archive", );
auto settings = new HTTPServerSettings;
settings.port = port;
settings.bindAddresses = ["::1", "0.0.0.0"];
listenHTTP(settings, router);
runApplication();
}
This is fine. But now that we have ~ 100 IoT devices in the
field, I would like to assign each a new port. The devices should
be communicating over HTTP as the vendor software running
thereupon uses http.
What is the best practice to make a vibe.d server listen to
multiple ports? Make a loop scanning each loop seems wasteful. Is
there a function in vibe.d that can take multiple ports, and
launch a set of threads assigned to each port?
Thank you
Re: Deprecation in traits
On Wednesday, 30 September 2020 at 08:33:58 UTC, Frak wrote: On Tuesday, 29 September 2020 at 18:25:03 UTC, Steven Schveighoffer wrote: On 9/29/20 1:08 PM, Frak wrote: [...] Because it's probably coming from a constraint, you probably can't figure out the exact usage. What's more annoying is that likely it is a spurious warning. A lot of traits "try something", and then alias to false or true depending on what works. But it's not going to make a difference in your code. It's one of the most annoying things in the library. If you see this warning coming from *your* code, then you should fix it. But it will tell you the location if that was the case, not std.traits. -Steve That's REALLY REALLY annoying! I'm spending LOT of time trying to figure out the exact point to fix in the code. Any idea? dustmite? You can give me access to the code and I can find it out for you. That's the best I have.
Re: Deprecation in traits
On Tuesday, 29 September 2020 at 18:25:03 UTC, Steven Schveighoffer wrote: On 9/29/20 1:08 PM, Frak wrote: Hi folks, I've this: /Users/frak/dlang/ldc-1.23.0/bin/../import/std/traits.d(3711): Deprecation: function `std.typecons.Nullable!long.Nullable.get_` is deprecated - Implicit conversion with `alias Nullable.get this` will be removed after 2.096. Please use `.get` explicitly. I'm trying to find out WHERE this is generated to fix it, dependency included, without success. Suggestions? Because it's probably coming from a constraint, you probably can't figure out the exact usage. What's more annoying is that likely it is a spurious warning. A lot of traits "try something", and then alias to false or true depending on what works. But it's not going to make a difference in your code. It's one of the most annoying things in the library. If you see this warning coming from *your* code, then you should fix it. But it will tell you the location if that was the case, not std.traits. -Steve That's REALLY REALLY annoying! I'm spending LOT of time trying to figure out the exact point to fix in the code. Any idea? dustmite?
