Perl Dancer Rewrite url
Hello I use perl dancer with Apache in mod_proxy + starman.pl ProxyPass / http://localhost:5002/ retry=0 Keepalive=on ProxyPassReverse / http://localhost:5002/ I've got path like /website/about /website/contact etc..; for www.mydomain.com I would like to rewrite url /about /contat etc.. I try with RewriteRule ^/website/(.*) / RewriteRule ^/(.*) http://localhost:5002/$1 [P] but result is no good, I go to /.... if someone has a idea ? Thanks Hugues.
I think I have this right. The doc says The RewriteRule directive is the real rewriting workhorse. The directive can occur more than once, with each instance defining a single rewrite rule. The order in which these rules are defined is important - this is the order in which they will be applied at run-time. Your RewriteRule ^/website/(.*) / rule appears to get rid of everything after the first "/" in the case of /website. The second rule has nothing to operate on for /website. So whate.ver/website/contact becomes whate.ver/ Also note that context is important. Again from the docWhat is matched? In |VirtualHost <http://httpd.apache.org/docs/current/mod/core.html#virtualhost>| context, The /Pattern/ will initially be matched against the part of the URL after the hostname and port, and before the query string (e.g. "/app1/index.html"). In |Directory <http://httpd.apache.org/docs/current/mod/core.html#directory>| and htaccess context, the /Pattern/ will initially be matched against the /filesystem/ path, after removing the prefix that led the server to the current |RewriteRule| (e.g. "app1/index.html" or "index.html" depending on where the directives are defined). If you wish to match against the hostname, port, or query string, use a |RewriteCond <http://httpd.apache.org/docs/current/mod/mod_rewrite.html#rewritecond>| with the |%{HTTP_HOST}|, |%{SERVER_PORT}|, or |%{QUERY_STRING}| variables respectively. --john On 10/22/2015 9:49 AM, Hugues wrote:
Hello I use perl dancer with Apache in mod_proxy + starman.pl
ProxyPass / http://localhost:5002/ retry=0 Keepalive=on ProxyPassReverse / http://localhost:5002/
I've got path like /website/about /website/contact etc..;
for www.mydomain.com I would like to rewrite url
/about /contat etc..
I try with
RewriteRule ^/website/(.*) / RewriteRule ^/(.*) http://localhost:5002/$1 [P]
but result is no good, I go to /....
if someone has a idea ? Thanks
Hugues. _______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
-- John J. McDermott, CPLP Learning and Performance Consultant jjm at jkintl.com 575/737-8556 Check out my security blog posts <http://cybersecurity.learningtree.com> Add an A for the Arts To STEM and get STEAM and a strong engine to move forward.
Hello see my rewrite log init rewrite engine with requested uri /website/about applying pattern '^/website/(.*)' to uri '/website/about' rewrite '/website/about' -> '/' applying pattern '^/(.*)' to uri '/' rewrite '/about' -> 'http://localhost:5002/about' forcing proxy-throughput with http://localhost:5002/about go-ahead with proxy request proxy:http://localhost:5002/about [OK] but /about route do not existe, this is /website/about and I've got a 404... It seems like Rewrite Rules is not a possible ( or if I create fake routes /about....) Le 22/10/2015 18:02, John J. McDermott, CPLP a écrit :
I think I have this right. The doc says
The RewriteRule directive is the real rewriting workhorse. The directive can occur more than once, with each instance defining a single rewrite rule. The order in which these rules are defined is important - this is the order in which they will be applied at run-time.
Your RewriteRule ^/website/(.*) / rule appears to get rid of everything after the first "/" in the case of /website. The second rule has nothing to operate on for /website. So whate.ver/website/contact becomes whate.ver/
Also note that context is important. Again from the docWhat is matched?
In |VirtualHost <http://httpd.apache.org/docs/current/mod/core.html#virtualhost>| context, The /Pattern/ will initially be matched against the part of the URL after the hostname and port, and before the query string (e.g. "/app1/index.html").
In |Directory <http://httpd.apache.org/docs/current/mod/core.html#directory>| and htaccess context, the /Pattern/ will initially be matched against the /filesystem/ path, after removing the prefix that led the server to the current |RewriteRule| (e.g. "app1/index.html" or "index.html" depending on where the directives are defined).
If you wish to match against the hostname, port, or query string, use a |RewriteCond <http://httpd.apache.org/docs/current/mod/mod_rewrite.html#rewritecond>| with the |%{HTTP_HOST}|, |%{SERVER_PORT}|, or |%{QUERY_STRING}| variables respectively.
--john
On 10/22/2015 9:49 AM, Hugues wrote:
Hello I use perl dancer with Apache in mod_proxy + starman.pl
ProxyPass / http://localhost:5002/ retry=0 Keepalive=on ProxyPassReverse / http://localhost:5002/
I've got path like /website/about /website/contact etc..;
for www.mydomain.com I would like to rewrite url
/about /contat etc..
I try with
RewriteRule ^/website/(.*) / RewriteRule ^/(.*) http://localhost:5002/$1 [P]
but result is no good, I go to /....
if someone has a idea ? Thanks
Hugues. _______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
-- John J. McDermott, CPLP Learning and Performance Consultant jjm at jkintl.com 575/737-8556 Check out my security blog posts <http://cybersecurity.learningtree.com> Add an A for the Arts To STEM and get STEAM and a strong engine to move forward.
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
I am confused. I thought the goal was to rewrite whatever.com/website/about to http://localhost:5002/about If someone goes to http://whatever.com/websiet/about where do you want the redirection to go? --john On 10/22/2015 10:11 AM, Hugues wrote:
Hello
see my rewrite log
init rewrite engine with requested uri /website/about applying pattern '^/website/(.*)' to uri '/website/about' rewrite '/website/about' -> '/' applying pattern '^/(.*)' to uri '/' rewrite '/about' -> 'http://localhost:5002/about' forcing proxy-throughput with http://localhost:5002/about go-ahead with proxy request proxy:http://localhost:5002/about [OK]
but /about route do not existe, this is /website/about and I've got a 404...
It seems like Rewrite Rules is not a possible ( or if I create fake routes /about....)
Le 22/10/2015 18:02, John J. McDermott, CPLP a écrit :
I think I have this right. The doc says
The RewriteRule directive is the real rewriting workhorse. The directive can occur more than once, with each instance defining a single rewrite rule. The order in which these rules are defined is important - this is the order in which they will be applied at run-time.
Your RewriteRule ^/website/(.*) / rule appears to get rid of everything after the first "/" in the case of /website. The second rule has nothing to operate on for /website. So whate.ver/website/contact becomes whate.ver/
Also note that context is important. Again from the docWhat is matched?
In |VirtualHost <http://httpd.apache.org/docs/current/mod/core.html#virtualhost>| context, The /Pattern/ will initially be matched against the part of the URL after the hostname and port, and before the query string (e.g. "/app1/index.html").
In |Directory <http://httpd.apache.org/docs/current/mod/core.html#directory>| and htaccess context, the /Pattern/ will initially be matched against the /filesystem/ path, after removing the prefix that led the server to the current |RewriteRule| (e.g. "app1/index.html" or "index.html" depending on where the directives are defined).
If you wish to match against the hostname, port, or query string, use a |RewriteCond <http://httpd.apache.org/docs/current/mod/mod_rewrite.html#rewritecond>| with the |%{HTTP_HOST}|, |%{SERVER_PORT}|, or |%{QUERY_STRING}| variables respectively.
--john
On 10/22/2015 9:49 AM, Hugues wrote:
Hello I use perl dancer with Apache in mod_proxy + starman.pl
ProxyPass / http://localhost:5002/ retry=0 Keepalive=on ProxyPassReverse / http://localhost:5002/
I've got path like /website/about /website/contact etc..;
for www.mydomain.com I would like to rewrite url
/about /contat etc..
I try with
RewriteRule ^/website/(.*) / RewriteRule ^/(.*) http://localhost:5002/$1 [P]
but result is no good, I go to /....
if someone has a idea ? Thanks
Hugues. _______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
-- John J. McDermott, CPLP Learning and Performance Consultant jjm at jkintl.com 575/737-8556 Check out my security blog posts <http://cybersecurity.learningtree.com> Add an A for the Arts To STEM and get STEAM and a strong engine to move forward.
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
-- John J. McDermott, CPLP Learning and Performance Consultant jjm at jkintl.com 575/737-8556 Check out my security blog posts <http://cybersecurity.learningtree.com> Add an A for the Arts To STEM and get STEAM and a strong engine to move forward.
Hello the goal is to remove website in this url http://whatever.com/website/about but without to change my Dancer code and my routes my appli has 2 parts , a authenticate par with /about a public part with /website/about but different than /about - /website/ is not very nice see and I looking for a solution to remove it only in url Hugues. Le 22/10/2015 18:19, John J. McDermott, CPLP a écrit :
I am confused. I thought the goal was to rewrite whatever.com/website/about to http://localhost:5002/about
If someone goes to http://whatever.com/websiet/about where do you want the redirection to go?
--john
On 10/22/2015 10:11 AM, Hugues wrote:
Hello
see my rewrite log
init rewrite engine with requested uri /website/about applying pattern '^/website/(.*)' to uri '/website/about' rewrite '/website/about' -> '/' applying pattern '^/(.*)' to uri '/' rewrite '/about' -> 'http://localhost:5002/about' forcing proxy-throughput with http://localhost:5002/about go-ahead with proxy request proxy:http://localhost:5002/about [OK]
but /about route do not existe, this is /website/about and I've got a 404...
It seems like Rewrite Rules is not a possible ( or if I create fake routes /about....)
Le 22/10/2015 18:02, John J. McDermott, CPLP a écrit :
I think I have this right. The doc says
The RewriteRule directive is the real rewriting workhorse. The directive can occur more than once, with each instance defining a single rewrite rule. The order in which these rules are defined is important - this is the order in which they will be applied at run-time.
Your RewriteRule ^/website/(.*) / rule appears to get rid of everything after the first "/" in the case of /website. The second rule has nothing to operate on for /website. So whate.ver/website/contact becomes whate.ver/
Also note that context is important. Again from the docWhat is matched?
In |VirtualHost <http://httpd.apache.org/docs/current/mod/core.html#virtualhost>| context, The /Pattern/ will initially be matched against the part of the URL after the hostname and port, and before the query string (e.g. "/app1/index.html").
In |Directory <http://httpd.apache.org/docs/current/mod/core.html#directory>| and htaccess context, the /Pattern/ will initially be matched against the /filesystem/ path, after removing the prefix that led the server to the current |RewriteRule| (e.g. "app1/index.html" or "index.html" depending on where the directives are defined).
If you wish to match against the hostname, port, or query string, use a |RewriteCond <http://httpd.apache.org/docs/current/mod/mod_rewrite.html#rewritecond>| with the |%{HTTP_HOST}|, |%{SERVER_PORT}|, or |%{QUERY_STRING}| variables respectively.
--john
On 10/22/2015 9:49 AM, Hugues wrote:
Hello I use perl dancer with Apache in mod_proxy + starman.pl
ProxyPass / http://localhost:5002/ retry=0 Keepalive=on ProxyPassReverse / http://localhost:5002/
I've got path like /website/about /website/contact etc..;
for www.mydomain.com I would like to rewrite url
/about /contat etc..
I try with
RewriteRule ^/website/(.*) / RewriteRule ^/(.*) http://localhost:5002/$1 [P]
but result is no good, I go to /....
if someone has a idea ? Thanks
Hugues. _______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
-- John J. McDermott, CPLP Learning and Performance Consultant jjm at jkintl.com 575/737-8556 Check out my security blog posts <http://cybersecurity.learningtree.com> Add an A for the Arts To STEM and get STEAM and a strong engine to move forward.
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
-- John J. McDermott, CPLP Learning and Performance Consultant jjm at jkintl.com 575/737-8556 Check out my security blog posts <http://cybersecurity.learningtree.com> Add an A for the Arts To STEM and get STEAM and a strong engine to move forward.
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
Ahh, OK. So you need to ensure that your Dancer routes are /about and so forth. You said but /about route do not existe, this is /website/about and I've got a 404... Since you rewrite to http://whatever.com/about your Dancer routes need to be /about and so forth. --john On 10/22/2015 10:28 AM, Hugues wrote:
Hello the goal is to remove website in this url
http://whatever.com/website/about
but without to change my Dancer code and my routes
my appli has 2 parts , a authenticate par with /about a public part with /website/about but different than /about -
/website/ is not very nice see and I looking for a solution to remove it only in url
Hugues.
Le 22/10/2015 18:19, John J. McDermott, CPLP a écrit :
I am confused. I thought the goal was to rewrite whatever.com/website/about to http://localhost:5002/about
If someone goes to http://whatever.com/websiet/about where do you want the redirection to go?
--john
On 10/22/2015 10:11 AM, Hugues wrote:
Hello
see my rewrite log
init rewrite engine with requested uri /website/about applying pattern '^/website/(.*)' to uri '/website/about' rewrite '/website/about' -> '/' applying pattern '^/(.*)' to uri '/' rewrite '/about' -> 'http://localhost:5002/about' forcing proxy-throughput with http://localhost:5002/about go-ahead with proxy request proxy:http://localhost:5002/about [OK]
but /about route do not existe, this is /website/about and I've got a 404...
It seems like Rewrite Rules is not a possible ( or if I create fake routes /about....)
Le 22/10/2015 18:02, John J. McDermott, CPLP a écrit :
I think I have this right. The doc says
The RewriteRule directive is the real rewriting workhorse. The directive can occur more than once, with each instance defining a single rewrite rule. The order in which these rules are defined is important - this is the order in which they will be applied at run-time.
Your RewriteRule ^/website/(.*) / rule appears to get rid of everything after the first "/" in the case of /website. The second rule has nothing to operate on for /website. So whate.ver/website/contact becomes whate.ver/
Also note that context is important. Again from the docWhat is matched?
In |VirtualHost <http://httpd.apache.org/docs/current/mod/core.html#virtualhost>| context, The /Pattern/ will initially be matched against the part of the URL after the hostname and port, and before the query string (e.g. "/app1/index.html").
In |Directory <http://httpd.apache.org/docs/current/mod/core.html#directory>| and htaccess context, the /Pattern/ will initially be matched against the /filesystem/ path, after removing the prefix that led the server to the current |RewriteRule| (e.g. "app1/index.html" or "index.html" depending on where the directives are defined).
If you wish to match against the hostname, port, or query string, use a |RewriteCond <http://httpd.apache.org/docs/current/mod/mod_rewrite.html#rewritecond>| with the |%{HTTP_HOST}|, |%{SERVER_PORT}|, or |%{QUERY_STRING}| variables respectively.
--john
On 10/22/2015 9:49 AM, Hugues wrote:
Hello I use perl dancer with Apache in mod_proxy + starman.pl
ProxyPass / http://localhost:5002/ retry=0 Keepalive=on ProxyPassReverse / http://localhost:5002/
I've got path like /website/about /website/contact etc..;
for www.mydomain.com I would like to rewrite url
/about /contat etc..
I try with
RewriteRule ^/website/(.*) / RewriteRule ^/(.*) http://localhost:5002/$1 [P]
but result is no good, I go to /....
if someone has a idea ? Thanks
Hugues. _______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
-- John J. McDermott, CPLP Learning and Performance Consultant jjm at jkintl.com 575/737-8556 Check out my security blog posts <http://cybersecurity.learningtree.com> Add an A for the Arts To STEM and get STEAM and a strong engine to move forward.
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
-- John J. McDermott, CPLP Learning and Performance Consultant jjm at jkintl.com 575/737-8556 Check out my security blog posts <http://cybersecurity.learningtree.com> Add an A for the Arts To STEM and get STEAM and a strong engine to move forward.
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
-- John J. McDermott, CPLP Learning and Performance Consultant jjm at jkintl.com 575/737-8556 Check out my security blog posts <http://cybersecurity.learningtree.com> Add an A for the Arts To STEM and get STEAM and a strong engine to move forward.
On Thu, Oct 22, 2015 at 6:11 PM, Hugues <hugues@max4mail.com> wrote:
Hello
see my rewrite log
init rewrite engine with requested uri /website/about applying pattern '^/website/(.*)' to uri '/website/about' rewrite '/website/about' -> '/' applying pattern '^/(.*)' to uri '/' rewrite '/about' -> 'http://localhost:5002/about' forcing proxy-throughput with http://localhost:5002/about go-ahead with proxy request proxy:http://localhost:5002/about [OK]
but /about route do not existe, this is /website/about and I've got a 404...
It seems like Rewrite Rules is not a possible ( or if I create fake routes /about....)
So, what are you trying to do: 1 map http://mydomain.com/website/(.*) to http://localhost:5002/$1 ? 2 map http://mydomain.com/website/(.*) to http://localhost:5002//website/$1 ? 3 map http://mydomain.com/website/(.*) to http://localhost:5002/$1 ? 4 map http://mydomain/(.*) to http://localhost:5002/website/$1 ? Also you can easily change the prefix of the whole Dancer application by using the prefix feature, see the cookbook examples.
Hi, I am currently using some routes in my app that render a template, which then fires some ajax queries which I catch in ajax routes via Dancer2::Plugin::Ajax. For deployment I use Starman with 10 workers. My question now is, what is the best way to make sure that ajax queries stay within the right session? The ajax routes use variables which I set in the other routes and are available within the same session, but when using Starman, how do I make sure that the ajax calls stay within the session the template comes from that fires the ajax calls? I hope the question is clear enough, Thanks for any help, Best --joerg
Hi! 2015-10-30 11:36 GMT+02:00 Joerg Fallmann <fall@tbi.univie.ac.at>:
The ajax routes use variables which I set in the other routes and are available within the same session, but when using Starman, how do I make sure that the ajax calls stay within the session the template comes from that fires the ajax calls? I hope the question is clear enough,
As HTTP is stateless protocol, the sessions are built on 2 technics: cookies and id in query parameters. So, when user has session set up for browser/html, it is usually done via cookies. Same cookies (in same domain) are included in every next request browser does, so be they then ordinary get-calls or ajax-calls, no matter. If yuo need keep sessions up without cookies, you should use session id-value in every request URL-s. But this is hardly case in your situation. Wbr, -- Kõike hääd, Gunnar
Thanks for the very fast reply, I switched from Session::Simple to Session::Cookie and it works fine. No need for me to keep sessions without cookies. --joerg On 10/30/2015 11:31 AM, WK wrote:
Hi!
2015-10-30 11:36 GMT+02:00 Joerg Fallmann <fall@tbi.univie.ac.at>:
The ajax routes use variables which I set in the other routes and are available within the same session, but when using Starman, how do I make sure that the ajax calls stay within the session the template comes from that fires the ajax calls? I hope the question is clear enough, As HTTP is stateless protocol, the sessions are built on 2 technics: cookies and id in query parameters. So, when user has session set up for browser/html, it is usually done via cookies. Same cookies (in same domain) are included in every next request browser does, so be they then ordinary get-calls or ajax-calls, no matter.
If yuo need keep sessions up without cookies, you should use session id-value in every request URL-s. But this is hardly case in your situation.
Wbr,
2015-10-30 15:04 GMT+02:00 Joerg Fallmann <fall@tbi.univie.ac.at>:
Thanks for the very fast reply, I switched from Session::Simple to Session::Cookie and it works fine. No need for me to keep sessions without cookies.
Pretty sure Session::Simple uses cookies too. Session::Simple is meant only for development phase and it keeps session info in memory. So it is not meant for production. And I think, it had some bugs too. As far as I recall, Session::Cookie stores _all_ session info _in_ cookies (encrypted, I think), which basically means storing session info client-side. Contrary any other session plugin, where cookie holds only session ID and session info itself is stored server side. Wbr, -- Kõike hääd, Gunnar
On Oct 30, 2015, at 9:03 AM, WK <wanradt@gmail.com> wrote:
2015-10-30 15:04 GMT+02:00 Joerg Fallmann <fall@tbi.univie.ac.at>:
Thanks for the very fast reply, I switched from Session::Simple to Session::Cookie and it works fine. No need for me to keep sessions without cookies.
Pretty sure Session::Simple uses cookies too.
It does.
Session::Simple ... is not meant for production.
That’s only true if “production” means a cluster of computers, or if you need sessions to survive a restart of the Dancer app. If you never need to scale beyond a single computer, and it’s fine if restarting the Dancer app logs everyone out, Session::Simple not only works fine, it’s faster than the alternatives because you don’t have the I/O overheads associated with the more complicated mechanisms.
And I think, it had some bugs too.
It’s working fine for us. Maybe you’re referring to the fact that it’s essentially single-threaded, which means you have to use it with a single-threaded HTTP server on the Dancer side. (e.g. HTTP::Server::Simple::PSGI instead of Starman.) This is also fine for smaller applications, since you get plenty of parallelism by proxying static assets with something like nginx. It does mean dynamic page hits choke down to a bottleneck, but in many web apps, that’s only one out of every hundred hits or so. A site that can be served from a single server might in fact never bottleneck this way in practice, since most of its clients will be idle, so that there is only ever zero or one dynamic page requests in progress at any given time. The rare cases where two or more dynamic page requests come in at a time are not worth optimizing; let the second wait until the first is finished. This does assume each Dancer transaction finishes quickly. It might not be practical if you’re doing something with WebSockets, for example.
2015-10-31 0:56 GMT+02:00 Warren Young <wyml@etr-usa.com>:
Session::Simple ... is not meant for production.
That’s only true if “production” means a cluster of computers, or if you need sessions to survive a restart of the Dancer app.
Docs says, it is meant for testing purposes only.
And I think, it had some bugs too.
It’s working fine for us.
Maybe you’re referring to the fact that it’s essentially single-threaded, which means you have to use it with a single-threaded HTTP server on the Dancer side. (e.g. HTTP::Server::Simple::PSGI instead of Starman.)
Yes, it was something like that. When I started app with multiple workers, they don't share session data. So it was meaningless. But your explanation give me good ideas, how Session::Simple would be still very useful. Thank you for sharing. Wbr, -- Kõike hääd, Gunnar
On Oct 31, 2015, at 3:48 AM, WK <wanradt@gmail.com> wrote:
2015-10-31 0:56 GMT+02:00 Warren Young <wyml@etr-usa.com>:
Session::Simple ... is not meant for production.
That’s only true if “production” means a cluster of computers, or if you need sessions to survive a restart of the Dancer app.
Docs says, it is meant for testing purposes only.
That’s because in today’s cloud everything, shard everything, no-SQL, multi-core, scale until Google buys us world, people are starting to forget that there are still a great many real-world tasks that run just fine on a single computer, and have no reasonable prospect of needing a second CPU core, much less a second computer. Just for one public example, the Dancer Advent calendar. Someone recently said it typically gets less than 2000 visits monthly. That’s about one visitor every *20 minutes* on average. You could probably run the site from a Raspberry Pi, single-threaded, and never even know the difference from how it’s run now.
On 2 Nov 2015, at 19:29, Warren Young <wyml@etr-usa.com> wrote:
Just for one public example, the Dancer Advent calendar. Someone recently said it typically gets less than 2000 visits monthly. That’s about one visitor every *20 minutes* on average. You could probably run the site from a Raspberry Pi, single-threaded, and never even know the difference from how it’s run now.
Funny you should say that - I have a site that gets about 100 hits a day (must check the logs) It’s dancer2 on an old PI just 1 core Does exactly fine (it manages a door lock) — Clive
"Warren" == Warren Young <wyml@etr-usa.com> writes:
Warren> On Oct 31, 2015, at 3:48 AM, WK <wanradt@gmail.com> wrote:
2015-10-31 0:56 GMT+02:00 Warren Young <wyml@etr-usa.com>:
Session::Simple ... is not meant for production.
That’s only true if “production” means a cluster of computers, or if you need sessions to survive a restart of the Dancer app.
Docs says, it is meant for testing purposes only.
Warren> That’s because in today’s cloud everything, shard everything, Warren> no-SQL, multi-core, scale until Google buys us world, people Warren> are starting to forget that there are still a great many Warren> real-world tasks that run just fine on a single computer, and Warren> have no reasonable prospect of needing a second CPU core, much Warren> less a second computer. Warren> Just for one public example, the Dancer Advent calendar. Warren> Someone recently said it typically gets less than 2000 visits Warren> monthly. That’s about one visitor every *20 minutes* on Warren> average. You could probably run the site from a Raspberry Pi, Warren> single-threaded, and never even know the difference from how Warren> it’s run now. This is exaclty where my usecase is for Dancer, small, simple sites. Would I like to work on the big stuff? Sure, but not as a side project. And as much as Warren and I have semi-clashed on this list, I think we're both in violent agreement here. *grin* So having Dancer do both big stuff, and small stuff, well is a good goal. For me, the next cliff is the leap to Starman deployments. It's yet another layer to learn and control for a deployment. John
Hi John I've found this is a good gentle starting point for Starman, http://perlmaven.com/getting-started-with-perl-dancer-on-digital-ocean Andrew On Tue, Nov 3, 2015 at 3:04 PM, John Stoffel <john@stoffel.org> wrote:
"Warren" == Warren Young <wyml@etr-usa.com> writes:
Warren> On Oct 31, 2015, at 3:48 AM, WK <wanradt@gmail.com> wrote:
2015-10-31 0:56 GMT+02:00 Warren Young <wyml@etr-usa.com>:
Session::Simple ... is not meant for production.
That’s only true if “production” means a cluster of computers, or if
you need sessions to survive a restart of the Dancer app.
Docs says, it is meant for testing purposes only.
Warren> That’s because in today’s cloud everything, shard everything, Warren> no-SQL, multi-core, scale until Google buys us world, people Warren> are starting to forget that there are still a great many Warren> real-world tasks that run just fine on a single computer, and Warren> have no reasonable prospect of needing a second CPU core, much Warren> less a second computer.
Warren> Just for one public example, the Dancer Advent calendar. Warren> Someone recently said it typically gets less than 2000 visits Warren> monthly. That’s about one visitor every *20 minutes* on Warren> average. You could probably run the site from a Raspberry Pi, Warren> single-threaded, and never even know the difference from how Warren> it’s run now.
This is exaclty where my usecase is for Dancer, small, simple sites. Would I like to work on the big stuff? Sure, but not as a side project.
And as much as Warren and I have semi-clashed on this list, I think we're both in violent agreement here. *grin*
So having Dancer do both big stuff, and small stuff, well is a good goal. For me, the next cliff is the leap to Starman deployments. It's yet another layer to learn and control for a deployment.
John _______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
-- Andrew Solomon Mentor@Geekuni http://geekuni.com/ http://www.linkedin.com/in/asolomon
participants (9)
-
Alex Mestiashvili -
Andrew Solomon -
Clive Eisen -
Hugues -
Joerg Fallmann -
John J. McDermott, CPLP -
John Stoffel -
Warren Young -
WK