Re^6: Help: Mojolicious+FastCGI+IIS

I wanted to harpoon your answer and I feel gratified. So much so that I'm ready to read other threads now. I answered your first round of questions since I criticized your answer first, have the last word if you want. If you would login I could just downvote and move on. shrug

Comment on Re^6: Help: Mojolicious+FastCGI+IIS

Replies are listed 'Best First'.
Re^7: Help: Mojolicious+FastCGI+IIS by Anonymous Monk on Feb 11, 2017 at 20:15 UTC
Both spidering and nice are not meant to go slow or make things go slower. The whole point of nice is to make something else go faster. And scheduled less often is not the same as going slow. I can be sure that I'm right because the program in question is named FAST <-- CGI. Not slow to startup CGI or functions as designed cgi. I believe the evolution was that CGI called out to a program with every load and fast cgi did the same but kept it in memory. It is not something I use, definitely never with IIS. Mojo comes with production and development web server and if I had a speed problem with Mojo I would try to solve it first with nginx. I wanted to harpoon your answer and I feel gratified. So much so that I'm ready to read other threads now. I answered your first round of questions since I criticized your answer first, have the last word if you want. If you would login I could just downvote and move on. shrug Hehe, thats what trolls do, call a response/suggestion "an answer", and then fail to criticize using faulty logic `$ mojo generate lite_app [exist] /foo/foo [write] /foo/foo/myapp.pl [chmod] /foo/foo/myapp.pl 744 $ perl -le"print ~~gmtime; system $^X, q[myapp.pl], q[daemon] " Sat Feb 11 20:24:52 2017 [Sat Feb 11 12:24:55 2017] [info] Listening at "http://*:3000" Server available at http://127.0.0.1:3000` [download] Oh no, hello world program is taking 3 seconds to start up, must be broken, need to throw another program on top	[reply] [d/l]

Replies are listed 'Best First'.

Re^7: Help: Mojolicious+FastCGI+IIS
by Anonymous Monk on Feb 11, 2017 at 20:15 UTC

Both spidering and nice are not meant to go slow or make things go slower. The whole point of nice is to make something else go faster. And scheduled less often is not the same as going slow. I can be sure that I'm right because the program in question is named FAST <-- CGI. Not slow to startup CGI or functions as designed cgi. I believe the evolution was that CGI called out to a program with every load and fast cgi did the same but kept it in memory. It is not something I use, definitely never with IIS. Mojo comes with production and development web server and if I had a speed problem with Mojo I would try to solve it first with nginx. I wanted to harpoon your answer and I feel gratified. So much so that I'm ready to read other threads now. I answered your first round of questions since I criticized your answer first, have the last word if you want. If you would login I could just downvote and move on. shrug

Hehe, thats what trolls do, call a response/suggestion "an answer", and then fail to criticize using faulty logic

$ mojo generate lite_app
  [exist] /foo/foo
  [write] /foo/foo/myapp.pl
  [chmod] /foo/foo/myapp.pl 744

$ perl -le"print ~~gmtime; system $^X, q[myapp.pl], q[daemon] "
Sat Feb 11 20:24:52 2017
[Sat Feb 11 12:24:55 2017] [info] Listening at "http://*:3000"
Server available at http://127.0.0.1:3000
[download]

Oh no, hello world program is taking 3 seconds to start up, must be broken, need to throw another program on top

[reply]
[d/l]