Re: Release: serverino - please destroy it.
On Tuesday, 10 May 2022 at 21:24:46 UTC, Paolo Invernizzi wrote: Here I am ... Milanese: https://www.deepglance.com/about /Paolo Ok it's me getting old! Andrea
Re: Release: serverino - please destroy it.
On Tuesday, 10 May 2022 at 20:41:17 UTC, Andrea Fontana wrote: On Tuesday, 10 May 2022 at 20:13:45 UTC, Paolo Invernizzi wrote: Sinceramente non ricordo di averlo scritto, ma alla mia eta ... probabilmente dimentico qualcosa ... comunque piacere! E' bello vedere altri italiani apprezzare questo magnifico linguaggio! (Frankly speaking, I don't remember to have written that, but hey, I'm getting old ... probably I'm forgetting something ... anyway nice to meet you! It's great to see Italians here enjoying this great programming language!) I wonder if you're making a fool of me. Or maybe it's me who is getting old. I'm pretty sure that there's a user here with a really Italian name who was born somewhere in South America. Andrea Here I am ... Milanese: https://www.deepglance.com/about /Paolo
Re: Release: serverino - please destroy it.
On Tuesday, 10 May 2022 at 20:13:45 UTC, Paolo Invernizzi wrote: Sinceramente non ricordo di averlo scritto, ma alla mia eta ... probabilmente dimentico qualcosa ... comunque piacere! E' bello vedere altri italiani apprezzare questo magnifico linguaggio! (Frankly speaking, I don't remember to have written that, but hey, I'm getting old ... probably I'm forgetting something ... anyway nice to meet you! It's great to see Italians here enjoying this great programming language!) I wonder if you're making a fool of me. Or maybe it's me who is getting old. I'm pretty sure that there's a user here with a really Italian name who was born somewhere in South America. Andrea
Re: Release: serverino - please destroy it.
On Tuesday, 10 May 2022 at 19:55:32 UTC, Andrea Fontana wrote: On Tuesday, 10 May 2022 at 19:50:08 UTC, Paolo Invernizzi wrote: Concordo ... (I agree!) :-P Wait, you have always said you're not Italian. Have you changed your mind? Andrea Sinceramente non ricordo di averlo scritto, ma alla mia eta ... probabilmente dimentico qualcosa ... comunque piacere! E' bello vedere altri italiani apprezzare questo magnifico linguaggio! (Frankly speaking, I don't remember to have written that, but hey, I'm getting old ... probably I'm forgetting something ... anyway nice to meet you! It's great to see Italians here enjoying this great programming language!)
Re: Release: serverino - please destroy it.
On Tuesday, 10 May 2022 at 19:50:08 UTC, Paolo Invernizzi wrote: Concordo ... (I agree!) :-P Wait, you have always said you're not Italian. Have you changed your mind? Andrea
Re: Release: serverino - please destroy it.
On Tuesday, 10 May 2022 at 16:05:11 UTC, Andrea Fontana wrote: On Tuesday, 10 May 2022 at 15:35:35 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 10 May 2022 at 15:27:48 UTC, Andrea Fontana wrote: Indeed the "-ino" suffix in "serverino" stands for "small" in italian. :) Bambino > bambinello? So, the embedded-version could be «serverinello»? :O) Oh, italian is full of suffixes. -ello means a slightly different thing. It's small but sounds like a bit pejorative. -ino in bambino is not (anymore) a suffix, anyway. Andrea Concordo ... (I agree!) :-P
Re: Release: serverino - please destroy it.
On Tuesday, 10 May 2022 at 18:33:18 UTC, Sebastiaan Koppe wrote:
On Tuesday, 10 May 2022 at 10:49:06 UTC, Andrea Fontana wrote:
On Tuesday, 10 May 2022 at 08:32:15 UTC, Sebastiaan Koppe
wrote:
The difference is that with the route uda you can *only* map
routes 1:1 exhaustively. With your approach it is up to the
programmer to avoid errors. It is also hard to reason about
the flow of requests through all those functions, and you
have to look at the body of them to determine what will
happen.
Sorry I don't follow you
It is simple, since all your handler are effectively chained,
any error in any one of them can cause later ones to fail or
misbehave. This decreases locality and increases the things you
have to reason about.
Not sure. What if your uda (regex) match is too permissive? Is
that different?
My code evaluates workers in order, just like yours, no?
Maybe I can enable some log if set on config, to track what's
happening. That could help you to debug if something goes wrong.
There are other benefits to uda tagged endpoints too, for
example they are easier to nest, or to programmatically
generate them. In vibe-d I added the default option of
generating OPTION handlers for every regular endpoint. This is
required for CORS.
@endpoint void func(...){
if(req.method == Method.OPTION){
// THIS RUN FOR EVERY ENDPOINT
}
}
In any case if you want to use a different routing strategy
it's quite easy. I really don't like libraries that force you
to use their own style/way.
That is good.
Andrea
Re: Release: serverino - please destroy it.
On Tuesday, 10 May 2022 at 16:47:13 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 10 May 2022 at 16:05:11 UTC, Andrea Fontana wrote: Oh, italian is full of suffixes. -ello means a slightly different thing. It's small but sounds like a bit pejorative. Oh, and I loved the sound of it… suggests immaturity, perhaps? (I love the -ello and -ella endings. «Bambinella» is one of my favourite words, turns out it is a fruit too!) Maybe bambinetto is more about immaturity. Bambinuccio is cute. Bambinaccio is bad. Bambinone is big (an adult that behave like a child). -ello doesn't sound good with bambino, but it's very similar to -etto. Good luck :)
Re: Release: serverino - please destroy it.
On Tuesday, 10 May 2022 at 10:49:06 UTC, Andrea Fontana wrote: On Tuesday, 10 May 2022 at 08:32:15 UTC, Sebastiaan Koppe wrote: The difference is that with the route uda you can *only* map routes 1:1 exhaustively. With your approach it is up to the programmer to avoid errors. It is also hard to reason about the flow of requests through all those functions, and you have to look at the body of them to determine what will happen. Sorry I don't follow you It is simple, since all your handler are effectively chained, any error in any one of them can cause later ones to fail or misbehave. This decreases locality and increases the things you have to reason about. There are other benefits to uda tagged endpoints too, for example they are easier to nest, or to programmatically generate them. In vibe-d I added the default option of generating OPTION handlers for every regular endpoint. This is required for CORS. In any case if you want to use a different routing strategy it's quite easy. I really don't like libraries that force you to use their own style/way. That is good.
Re: Release: serverino - please destroy it.
On Tuesday, 10 May 2022 at 16:05:11 UTC, Andrea Fontana wrote: Oh, italian is full of suffixes. -ello means a slightly different thing. It's small but sounds like a bit pejorative. Oh, and I loved the sound of it… suggests immaturity, perhaps? (I love the -ello and -ella endings. «Bambinella» is one of my favourite words, turns out it is a fruit too!)
Re: Release: serverino - please destroy it.
On Tuesday, 10 May 2022 at 15:35:35 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 10 May 2022 at 15:27:48 UTC, Andrea Fontana wrote: Indeed the "-ino" suffix in "serverino" stands for "small" in italian. :) Bambino > bambinello? So, the embedded-version could be «serverinello»? :O) Oh, italian is full of suffixes. -ello means a slightly different thing. It's small but sounds like a bit pejorative. -ino in bambino is not (anymore) a suffix, anyway. Andrea
Re: Release: serverino - please destroy it.
On Tuesday, 10 May 2022 at 15:27:48 UTC, Andrea Fontana wrote: Indeed the "-ino" suffix in "serverino" stands for "small" in italian. :) Bambino > bambinello? So, the embedded-version could be «serverinello»? :O)
Re: Release: serverino - please destroy it.
On Tuesday, 10 May 2022 at 15:16:22 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 10 May 2022 at 15:00:06 UTC, Andrea Fontana wrote: I work in the R and every single time I even have to write a small api or a simple html interface to control some strange machine I think "omg, I have to set nginx agaain". Good point, there are more application areas than regular websites. Embedded remote applications could be another application area where you want something simple with HTTPS (monitoring webcams, sensors, solar panels, supervising farming houses or whatever). Indeed the "-ino" suffix in "serverino" stands for "small" in italian. :) Andrea
Re: Release: serverino - please destroy it.
On Tuesday, 10 May 2022 at 15:00:06 UTC, Andrea Fontana wrote: I work in the R and every single time I even have to write a small api or a simple html interface to control some strange machine I think "omg, I have to set nginx agaain". Good point, there are more application areas than regular websites. Embedded remote applications could be another application area where you want something simple with HTTPS (monitoring webcams, sensors, solar panels, supervising farming houses or whatever).
Re: Release: serverino - please destroy it.
On Tuesday, 10 May 2022 at 15:01:43 UTC, Adam Ruppe wrote: On Monday, 9 May 2022 at 19:20:27 UTC, Andrea Fontana wrote: Thank you. Looking forward to getting feedback, bug reports and help :) BTW I'm curious, what made you not want to use my cgi.d which has similar capabilities? I was really tempted to start from that! But it's difficult to fork and edit a 11kloc project like that :) I had yet developed fastcgi and scgi code in the past so I've reused some code and it didn't take so much time to get to serverino. Andrea
Re: Release: serverino - please destroy it.
On Monday, 9 May 2022 at 19:20:27 UTC, Andrea Fontana wrote: Thank you. Looking forward to getting feedback, bug reports and help :) BTW I'm curious, what made you not want to use my cgi.d which has similar capabilities?
Re: Release: serverino - please destroy it.
On Tuesday, 10 May 2022 at 13:15:38 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 10 May 2022 at 12:52:01 UTC, Andrea Fontana wrote: I'm running a whole website in D using fastcgi and we have no problem at all, it's blazing fast. But it's not so easy to setup as serverino :) Easy setup is probably the number one reason people land on a specific web-tech, so it is the best initial angle, I agree. (By version 3.x you know what the practical weak spots are and can rethink the bottom layer.) Right. But it's not just marketing. I work in the R and every single time I even have to write a small api or a simple html interface to control some strange machine I think "omg, I have to set nginx agaain". It's pretty annoying especially if you're working on shared aws machine. (I know, docker & c. Exist, but they take a lot to setup and they are heavy for some simple api). I'm going to love serverino in the next months :)
Re: Release: serverino - please destroy it.
On Tuesday, 10 May 2022 at 13:34:27 UTC, Adam D Ruppe wrote:
On Monday, 9 May 2022 at 20:37:50 UTC, Andrea Fontana wrote:
The same goes for cgi/fastcgi/scgi and so on.
Well, cgi does one process per request, so there is no worker
pool (it is the original "serverless" lol).
fastcgi is interesting because the Apache module for it will
actually start and stop worker processes as-needed. I don't
think the the nginx impl does that though.
Some daemons can manage this by themselves (once again: check
php-fpm "dynamic" setting).
Serverino can do it as well. You can set in configuration the max
and min number of workers. It's easy:
```
@onServerInit auto setup()
{
ServerinoConfig sc = ServerinoConfig.create();
sc.setMinWorkers(5);
sc.setMaxWorkers(100);
return sc;
}
```
If all workers are busy the daemon will launch a new one. You
might be interested in
setMaxWorkerLifetime() and sc.setMaxWorkerIdling() too!
But the nicest thing about all these application models is if
you write it in the right way, you can swap out the approach,
either transparently adding the i/o event waits or just adding
additional servers without touching the application code.
That's a lot harder to do when you expect shared state etc.
like other things encourage.
I would mention that if something goes wrong and a process crash
or get caught in an infinite loop, it's not a problem. Process is
killed and wake up again without pull all the server down.
Andrea
Re: Release: serverino - please destroy it.
On Monday, 9 May 2022 at 20:37:50 UTC, Andrea Fontana wrote: The same goes for cgi/fastcgi/scgi and so on. Well, cgi does one process per request, so there is no worker pool (it is the original "serverless" lol). fastcgi is interesting because the Apache module for it will actually start and stop worker processes as-needed. I don't think the the nginx impl does that though. But the nicest thing about all these application models is if you write it in the right way, you can swap out the approach, either transparently adding the i/o event waits or just adding additional servers without touching the application code. That's a lot harder to do when you expect shared state etc. like other things encourage.
Re: Release: serverino - please destroy it.
On Tuesday, 10 May 2022 at 12:52:01 UTC, Andrea Fontana wrote: I'm running a whole website in D using fastcgi and we have no problem at all, it's blazing fast. But it's not so easy to setup as serverino :) Easy setup is probably the number one reason people land on a specific web-tech, so it is the best initial angle, I agree. (By version 3.x you know what the practical weak spots are and can rethink the bottom layer.)
Re: Release: serverino - please destroy it.
On Tuesday, 10 May 2022 at 12:31:23 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 10 May 2022 at 10:49:06 UTC, Andrea Fontana wrote: And you can still handle 700k/views per hour with 20 workers! Requests tend to come in bursts from the same client, thanks to clunky javascript APIs and clutters of resources (and careless web developers). For a typical D user ease-of-use is probably more important at this point, though, so good luck with your project! In my opnioni IRL that's not a big problem as it can seem. Again: that's just how nginx and apache handle php/cgi/fcgi/scgi requests. Wikipedia runs wikimedia software. Written in php. Running on apache with php-fpm (and cache!). And I'm not suggesting to run wikipedia on serverino, *for now*. If you try to open a lot of wikipedia pages at the same time in a burst, they will be served (probably using keep-alive connection) not in parallel: you're queued. And the 99.9% of users will never notice this. Is it a problem? If you need much control, you can use an http accelerator and/or you can use a reverse proxy (like nginx) to control bursts et similia. I'm running a whole website in D using fastcgi and we have no problem at all, it's blazing fast. But it's not so easy to setup as serverino :) Andrea
Re: Release: serverino - please destroy it.
On Tuesday, 10 May 2022 at 10:49:06 UTC, Andrea Fontana wrote: And you can still handle 700k/views per hour with 20 workers! Requests tend to come in bursts from the same client, thanks to clunky javascript APIs and clutters of resources (and careless web developers). For a typical D user ease-of-use is probably more important at this point, though, so good luck with your project!
Re: Release: serverino - please destroy it.
On Tuesday, 10 May 2022 at 08:32:15 UTC, Sebastiaan Koppe wrote:
On Monday, 9 May 2022 at 20:37:50 UTC, Andrea Fontana wrote:
On Monday, 9 May 2022 at 20:08:38 UTC, Sebastiaan Koppe wrote:
As an example, how many requests per second can you manage if
all requests have to wait 100 msecs?
For non critical workload you will probably still hit good
enough performance though.
Firstly, it depends on how many workers you have.
Then you should consider that a lot of (most?) websites use
php-fpm, that works using the same approach (but php is much
slower than D). The same goes for cgi/fastcgi/scgi and so on.
Let's say you have just 20 workers. 100msecs for each request
(a lot of time for my standards, I would say). That means
20*10 = 200 webpages/s = 720k pages/h. I don't think your
website has so much traffic...
And I hope not every request will take 100msecs!
100msecs is on the upper end for sure, but if you add a
database, external service call, etc. it is not uncommon to
reach that.
And you can still handle 700k/views per hour with 20 workers!
The point however, is that the architecture breaks down because
it is unable to do work concurrently. Every requests blocks a
worker from start to finish.
Unless it is CPU heavy the system will be under utilized. That
is not necessarily bad though. The simplicity has something
going for it, but it is definitely a tradeoff that you should
consider highlighting.
Every server has its own target. BTW, I'm not developing
serverino to use it as a building block of a CDN.
In real-life projects, I think you can use it without any problem
for not-huge projects.
You can also put it under a reverse proxy (f.e. nginx), to handle
just the requests you need to write in D.
The difference is that with the route uda you can *only* map
routes 1:1 exhaustively. With your approach it is up to the
programmer to avoid errors. It is also hard to reason about the
flow of requests through all those functions, and you have to
look at the body of them to determine what will happen.
Sorry I don't follow you: I don't know which framework you're
using, but if you're using UDA with matches (something like:
@matchUri("/main") void renderMain(...) { ... }) you still have
to check all the functions if a request is not handled correctly.
Or am I missing something?
Using my approach if you want to check which functions escape
from routing you can just add a catch-all endpoint with low
priority.
```
@priority(-1000) @endpoint
void wtf(Request r, Output o)
{
fatal("Request NOT HANDLED: ", r.dump());
}
```
And if a request doesn't match your UDA constraint, how do you
debug what's wrong with it? I think it's easier to add a
checkpoint/log on the first lines of your functions body to guess
why the function is skipped.
In any case if you want to use a different routing strategy it's
quite easy. I really don't like libraries that force you to use
their own style/way.
So you can even drop my UDAs and write the app like this. It
still works:
```
mixin ServerinoMain;
void entry(Request r, Output o)
{
// Use your routing strategy here
// ...
// YourRouter router;
// router.do(r, "/hello/world", );
// router.do(r, "/bla", );
}
```
Andrea
Re: Release: serverino - please destroy it.
On Monday, 9 May 2022 at 20:37:50 UTC, Andrea Fontana wrote:
On Monday, 9 May 2022 at 20:08:38 UTC, Sebastiaan Koppe wrote:
As an example, how many requests per second can you manage if
all requests have to wait 100 msecs?
For non critical workload you will probably still hit good
enough performance though.
Firstly, it depends on how many workers you have.
Then you should consider that a lot of (most?) websites use
php-fpm, that works using the same approach (but php is much
slower than D). The same goes for cgi/fastcgi/scgi and so on.
Let's say you have just 20 workers. 100msecs for each request
(a lot of time for my standards, I would say). That means 20*10
= 200 webpages/s = 720k pages/h. I don't think your website has
so much traffic...
And I hope not every request will take 100msecs!
100msecs is on the upper end for sure, but if you add a database,
external service call, etc. it is not uncommon to reach that.
The point however, is that the architecture breaks down because
it is unable to do work concurrently. Every requests blocks a
worker from start to finish.
Unless it is CPU heavy the system will be under utilized. That is
not necessarily bad though. The simplicity has something going
for it, but it is definitely a tradeoff that you should consider
highlighting.
```
@endpoint void my_end(Request r, Output o)
{
if (r.uri == "/asd") // or whatever you want: regex,
or checking another field
return false; //
}
```
This is just like:
```
@matchuda(uri, "/asd") void my_end() { ... }
```
What's the difference? The first one is much more flexible,
IMHO.
The difference is that with the route uda you can *only* map
routes 1:1 exhaustively. With your approach it is up to the
programmer to avoid errors. It is also hard to reason about the
flow of requests through all those functions, and you have to
look at the body of them to determine what will happen.
