view release on metacpan or  search on metacpan

lib/Dancer2/Manual/Deployment.pod  view on Meta::CPAN

The Shotgun, while effective, can quickly cause you performance issues, even
during the development phase of your application. As the number of plugins
you use in your application grows, as the number of static resources (images,
etc.) grows, the more requests your server process needs to handle. Since
each request recompiles the application, even simple page refreshes can get
unbearably slow over time. Use with caution.

You can bypass Shotgun's auto-reloading of specific modules with the
C<-M> switch:

    plackup -L Shotgun -M<MyApp::Foo> -M<MyApp::Bar> bin/app.psgi

On Windows, the Shotgun loader is known to cause huge memory leaks in a
fork-emulation layer. If you are aware of this and still want to run the
loader, please use the following command:

    PLACK_SHOTGUN_MEMORY_LEAK=1 plackup -L Shotgun bin\app.psgi

B<Please note:> if you are using Dancer 2's asynchronous capabilities, using
Shotgun will kill Twiggy. If you need async processing, consider an
alternative to Shotgun.

=head1 Running a PSGI-Based Web Server

For production environments, use a PSGI-compatible web server. These
servers provide improved performance, scalability, and better resource
management.

=head2 Using C<plackup>

You can use C<plackup> in production by configuring it to run without
live reloading and with proper performance settings:

    plackup -E production --host 0.0.0.0 --port 5000 bin/app.psgi

This approach is simple but lacks advanced features like process
management and load balancing.

=head2 Using Starman

L<Starman> is a high-performance, pre-forking PSGI server for Perl
applications. It is designed for production environments.

To run your app with Starman:

    plackup -s Starman --workers 5 --port 5000 bin/app.psgi

The C<--workers> flag specifies the number of worker processes to handle
requests. Adjust this based on your server's resources.

=head2 Using Gazelle

L<Gazelle|https://metacpan.org/pod/Gazelle> is another PSGI server that
focuses on long-lived connections and minimal overhead.

Run your app with Gazelle like this:

    plackup -s Gazelle -p 5000 bin/app.psgi

Gazelle provides options for optimizing keep-alive connections and
handling large numbers of requests efficiently.

=head2 Using Server::Starter for Zero-Downtime Deployments

L<Server::Starter> provides you with a superdaemon and instance script
for managing PSGI-based Perl application servers. The superdaemon is
responsible for starting new processes and shutting down old ones. It
provides hot-deployment capability by watching for restart requests and
ensuring new processes successfully start up before terminating the old
processes. F<start_server> is the command-line program that allows you
to interact with the superdaemon.

You can manage most PSGI-based app server with F<start_server>:

    start_server --port 5000  -- plackup -s Gazelle -a app.psgi

=head2 Using uWSGI

L<uWSGI|https://uwsgi-docs.readthedocs.io/en/latest/> is a robust
application server that supports PSGI. It is written in C and provides
excellent performance.

For configuring uWSGI with a Dancer2 application, refer to the official
documentation: L<https://uwsgi-docs.readthedocs.io/en/latest/Perl.html>.

A basic configuration might look like this:

    uwsgi --http :5000 --plugin psgi --psgi bin/app.psgi

uWSGI is powerful and supports features like process management, load
balancing, and integration with NGINX.

=head1 Running Behind a Reverse Proxy

Using another webserver like NGINX to reverse proxy your application can
improve the scalability and security of your application. A reverse proxy
handles incoming requests, forwards them to your PSGI server, and manages
features like SSL termination and caching. Reverse proxies can help
improve the performance of your applications by serving static content
more efficiently than your application can.

When running your Dancer2 application behind a reverse proxy, make sure
to set the C<behind_proxy> configuration setting to make sure all URLs
and headers are set properly:

    behind_proxy: 1

For more information, see L<the configuration guide|Dancer2::Manual::Config/behind_proxy (boolean)>.

=head2 Example: Using NGINX with Starman

Here’s a basic NGINX configuration for a Dancer2 app running on Starman:

    server {
        listen 80;
        server_name example.com;

        location / {
            proxy_pass http://127.0.0.1:5000;
            proxy_set_header Host $host;