CODEWITHSUNDEEP
phpmysqlsession
Gary Olsson
Gary Olsson

Reputation: 1217

PHP Data session storage

On my website, users can currently compare multiple company for a prestation. For each company, I calculate the price of the prestation.

To calculate this price I have a very big SQL request in order to filter companies based on the user's previous input and get every parameter I need.

Once the query end, I loop througt the company list and calculate the price for each of them and for each additional services the company offer. Then I display those value to the user in HTML.

The user can then add or remove an option and order the company.

Then, when a user choose a price, I send the company_id along with the user's otpion (the different services he chose) to the server and get the price previously calculated from the user SESSION.

Prices are stored in user session in order to avoid the calculation process but, I have like ~6 prices by company and usually ~30 companies for one user request. Which mean that I store in session an array with around 180 different prices for one user.

I found it quite wastefull to store this many variables in session and I was wondering, is there a better way to store those variables ? Should I store them in database ?

By the way, server side, i'm using PHP along with Mysql for the database.

Upvotes: 0

Views: 91

Answers (1)

Sébastien Renauld
Sébastien Renauld

Reputation: 19662

What you're effectively doing is a very primitive form of caching. Sadly, the session is not the best place to do so, for a variety of reasons:

  • The session can never be shared between users. Some values cached may be the same for every user. It's good to have a cache that allows you to go the "unique" or "shared" routes at will.
  • Is your session cached data used on every page? If it is, then forget this point. If, however, it isn't, on every page, you're still incurring the cost of fetching (which, depending on your server configuration, may involve a few fs calls, or network calls, or a combination) and deserializing the data, on every request. This, if your session payload is large, can make a significant different to load times.
  • Another point to consider is the simple fact that, if you are running a straight-out-of-the-box LAMP stack and have not configured a shared session driver, you're going to find a very nasty surprise when you scale out :-)

Before we go any further, ask yourself these questions:

  1. Do the values in the session change on a user-by-user basis? And if they do, is it by a fixed amount of percentage?
  2. Do the values in the session change often?
  3. How are the values calculated?

If #1 is "No"

You are better off caching one copy and use it for every user.

If #2 is "No"

You are better off denormalizing (i.e. pre-calculating) the values in the database

If #3 is a complicated formula

See #2

In every case

MySQL is a very poor cache driver, and should be avoided if you can. Most people replace it with redis, but that's also not a very good way due to its inability to scale by itself (you need nutcracker/twemproxy to make it properly shard). Either way, if your data to be cached is relatively small, MySQL will do. However, plan for the future.

If you do plan on going the proper cache way, consider a key-value store such as Riak, or a document storage driver such as Aerospike.

Upvotes: 1

Related Questions