0

I have my database storing lots of information about products (year, name, release_date, volume, etc. etc.). I currently load all of the products once and store them in a session variable - right now there's only 8 products but the list will grow as time progresses. The reason why I did this was to (perhaps foolishly) save HDD reads every time the products page was accessed. Am I shooting myself in the foot by storing this information in the session?

JakeTheSnake
  • 343
  • 1
  • 8
  • 19

2 Answers2

1

Yes, you're probably shooting yourself in the foot. If every user session stores all the product information, you may run out of memory once you have a lot of users and a lot of products.

I'd suggest using something like memcached to cache the queries against the product table, so that you're not hitting the disk too hard but you're not running out of memory either.

But it really depends on what kind of scale you're expecting -- if you're only going to have 50kB of product data and 500 simultaneous user sessions, then you'll only be eating 25MB, and you can probably get away with it. If you're expecting 50MB of product data and 50,000 user sessions, then you'll be using 2.5TB of RAM, which you probably won't have.

Mike Scott
  • 7,903
  • 29
  • 26
  • I'm currently on a shared hosting plan with Bluehost; is memcache something I'd have to talk with them about or is it something I can install myself? – JakeTheSnake Jan 07 '11 at 17:11
0

If you only have 8 products you don't need a database :-)

If you want to use the database (which is probably a good idea if the site is going to grow) you may as well use the database and simply point a session product key array at it. Having duplicate information in the session is a pain and unecessary -- why have it in two places?

If the database is frequently being accessed all the product table information is most likely to be in memory anyway, so you don't need to add in any further complexity. For most sites, memcached is just a way of trying to speed up really badly designed database queries or ORMs.

rorycl
  • 848
  • 1
  • 6
  • 10