What are the implications of storing large amounts of data in the session cookie?

If you store a large amount of data within a session, you'll have input/output performance drops since there's going to be a lot of reading/writing.

Sessions in PHP, by default, are stored in /tmp directory in a flat file. Therefore, your session data is written in a data-file of some sort.

PHP allows you to override its default session handler by session_set_save_handler() function where you can redefine the way sessions are read / written / maintained.

You can also override this via php.ini file where you specify it via session.save_handler directive.

Now, the implication of having a large number of sessions storing large data is that a lot of files will be created and it will take some time to find them due to the ways hard drives operate (mechanical ones of course, which are the common ones still). The more you have, the longer it takes to find it. The larger they are, longer it takes to read it. If you have a lot of them and they are large - double the trouble, a change in approach is needed.

So what's the solution?

Usually, when met with performance drop - people load balance their websites. That doesn't work with sessions unfortunately because load balancing is choosing which computer to use that will serve the current request. That means that different computers will serve pages you browse at some website. Which means, if those computers use default mechanism of session storage (/tmp directory), the sessions will not be preserved across the servers since they cannot access each other's /tmp directory. You can solve this by mounting a NAS and making it globally visible to all of the computers in the cluster, but that's both expensive and difficult to maintain.

The other option is to store the sessions in a database. A database is accessible from any of the computers in our fictional cluster. Usually, there are specialised databases used for handling sessions, specialised in sense of being separate from the database storing your website content or whatever. In the time of NoSQL popularity - in my opinion, NoSQL is great for handling sessions. They scale easily, they are faster in writing the data to storage devices than RDBMSs are.

Third option is to boost all of this, ditch hard drives as permanent storage solution and just use your server's memory for session storage. What you get is incredible performance, however all your RAM might be quickly gone. You can also create a cluster of computers that store sessions in their RAM. Redis and Memcache are great for this task, googling a bit will give you good resources that explain how to use Redis or Memcache to store sessions.

Bottom line of all this is: don't store too much data in your sessions. According to your needs and budget - there are 3 options available how to store and work with sessions.