The "fastest" way to store session data is just within your Apache process.

But usually, you are running more than one Apache process (unless you run the MPM threads model only). So you will want to share the session data among processes because you never know which process will handle the next request of the user. So you maybe want to use some shared memory that Apache also provides, like APR::Table.

But that information gets lost if you have more than one machine and don't want the headache of pinning a source IP address to a server. Then maybe you want to persist the session data to some other shared medium, like a Redis server, or a database, or just as a JSON file to a shared disk.

There are many options and not all of them are equally suitable to all situations. This is why there are modules like CGI::Session that implement various methods of storing sessions.

If you are Google-scale, you maybe want to keep the session stored on the users machine and just verify that the session is still as you sent it to the user by using cryptographically signed session cookies. This is what JWT is all about.

Usually, if you are going the route of using a database table as session store, you will have to create that table yourself.

When you choose mod_perl for new projects, which nobody at all does these days in my experience, this means tying yourself into old-fashioned architecture ideas which revolve around tightly coupling your application to a specific webserver. I suggest you at least have a look at http://plackperl.org/. I personally haven't worked on any mod_perl projects since 2011 (and this was a legacy system which I doubt exists in that form anymore).

Dancer is a perfectly sane choice for modern web development with Perl, and the one I have a lot of professional experience with, so are Mojolicious or Catalyst (though I have never ever liked the way Catalyst handles dispatch). If you really want to create your own framework (be my guest, I have never had the urge but <shrug>), then you ought to be looking at how these frameworks do things. The problem space is a well trodden path that thousands of developers have traveled already.

Serious question... What is the general consensus on the best server(s) to run PSGI apps? I am a long time user of Apache/mod_perl and I know it's frowned upon nowadays, but it continues to be the most stable and fastest server for my Catalyst apps. I have tried Starman and uWSGI, both of which would crash or run out of memory over time. They also would report slower times for processing queries. Are there certain tweaks or optimizations that need to be done in the apps to work better under these servers? As of now, I continue to use Apache/mod_perl, but I would prefer not to be living in the past if there is a better way out there.

In my experience Starman is highly unstable. It might have been a bad combination of environment issues and older Perl but I got hangs and segfaults all the time and had to ditch it.

uWSGI RFC:SHOULD be the best, easily. You might review the docs to see your usage is cromulent and update to the latest version for good measure. I run a couple of applications on it, not high traffic but up to many thousands of views a day, most pages dynamic, and I've never had any issues whatsoever. I've stress tested it out to high traffic levels with excellent results. It runs from server reboot to reboot without any attention. Longest stretch I've left it running is a year-ish. If you're having trouble, especially regardless of app engine, you might have a memory leak or various other problems in your Perl or things it calls beneath.

I don't know what the consensus is. I've worked on projects which were deployed into production on nginx/starman and apache/starman.

As a long-time user of and fan of mod_perl, I would say that there is no good reason today to be building such a framework using it.

Use an existing framework and extend it to fit your needs. For example, if you use Dancer2 you handle sessions simply like this in the application config:

engines:
  session:
    Simple:
      cookie_name: your_app.session
[download]

Using a framework like this in no way prevents you from building tools to simplify menus, etc. But using a modern framework does mean that you will avoid lots of struggles and pain with dated libraries.

Never heard of Dancer2. I will look into it. I understand rolling my own is not the most efficient way of building a web application, but this project is also a way for me to learn how to improve my web development and coding skills for large projects in general.

$PM = "Perl Monk's";
$MCF = "Most Clueless Friar Abbot Bishop Pontiff Deacon Curate";
$nysus = $PM . ' ' . $MCF;
Click here if you love Perl Monks

The best way to improve your web development skills is to do some web development. Writing a framework isn't web development. What you've described is more on the order of saying you want to build a shed, but first you want to (re)invent all the tools for building the shed before getting on with actually building the shed.

this project is also a way for me to learn how to improve my web development and coding skills for large projects in general

That is a good goal and developing something at home is the right approach. But it's all the more reason to use something that has on-going development and support, and which you could well encounter in the real world in either a job opportunity or a community project to join.



The way forward always starts with a minimal test.

1) What's the fastest way to store session data? In the DB? In a file? What are the advantages/disadvantages of the different methods?

Generally (you know this), RAM is faster than disk ...

The only way to know for sure is to benchmark

Most people don't base their decision on speed alone

2) If I use a DB, do I have to set up the DB table for storing session data ahead of time or prep the DB in any way?

Of course, it depends, see Apache::Session::Store::MySQL for details (or ::Oracle or ... )

3) There is a module called Apache::SessionManager. Not sure if that is the direction to take or not. It looks like it might do the same thing as Apache::Session but is built specifically for mod_perl. Is that right?

Ignore that its old , less generic, hasn't been updated since 2004...

Any other useful guidance or general pointers is appreciated. Thank you very much for your time.

Remember to remind yourself Apache::Session is generic and not apache specific, you can use it from Dancer or Mojolicious or Catalyst or ...

However, it is old, the fallback random id generator isn't as good/modern/best practice as what the frameworks use

When one of the mojo(?) users discovered a better/proper sessionid/rand generator, he updated the Dancer and Catalyst guys on the issue -- there is a lot of overlap between the mojo/dancer/catalyst guys -- they don't keep up with Apache::Session -- i dont think anybody does -- the CGI::Session guys do seem to keep up ...

However

If you're aware of these things, and you like to learn, go for it, the frameworks aren't that different from "best" practices (cgi101)

All the frameworks give you a request object

All the frameworks want you to give them a response object

If you're using CGI.pm and following CGI to mod_perl Porting. mod_perl Coding guidelines you're 98% modern , only 2% away from using any "modern frameworks" which have a response object

cgi101