CODEWITHSUNDEEP
javaphpmysqloptimization
Ajant
Ajant

Reputation: 158

Keeping data in database or in session

I'm in the early stages of doing a web project which will require working with arrays containing around 500 elements of custom object type. Objects will likely contain between 10 and 40 fields (based on user input), mostly booleans, strings and floats. I'm gonna use PHP for this project, but I'm also interested to know how to treat this problem in Java.

I know that "premature optimization is the root of all evil", but I think I need to decide now, how do I handle those arrays. Do I keep them in the Session object or do I store them in the database (mySQL) and keep just a minimum amount of keys in the session. Keeping data in the session would make application work faster, but when visitor numbers start growing I risk using up too much memory. On the other hand reading and writing from and into database all the time will degrade performance.

I'd like to know where the line is between those two approaches. How do I decide when it's too much data to keep inside session?

Upvotes: 3

Views: 929

Answers (2)

casablanca
casablanca

Reputation: 70701

I would be surprised if you had that amount of unique data for each user. Ideally, some of this data would be shared across users, and you could have some kind of application-level cache that stores the most recently used entries, and transparently fetches them from the database if they're missing.

This kind of design is relatively straightforward to implement in Java, but somewhat more involved (and possibly less efficient) with PHP since it doesn't have built-in support for application state.

Upvotes: 0

Andrea Colleoni
Andrea Colleoni

Reputation: 6021

When I face a problem like this I try to estimate the size of per user data that I want to keep fast.

If your case, suppose for example to have 500 elements with 40 fields each of which sizing 50 bytes (making an average among texts, numbers, dates, etc.). So we have to keep in memory about 1MB per user for this storage, so you will have about 1GB every 1000 users only for this cache.

Depending on your server resource availability you can find bottlenecks: 1000 users consume CPU, memory, DB, disks accesses; so are in this scenario 1GB the problem? If yes keep them in DB if no keep them in memory.

Another option is to use an in-memory DB or a distributed cache solution that does it all for you, at some cost:

  • architectural complexity
  • eventually licence costs

Upvotes: 2

Related Questions