I am programming in PHP mysql.
I have recently got into OOP programming.
So I need to serialize my objects and store them to SESSIONS. However I think the huge sessions are slowing down refreshing and loading of my webpages.
Is there an alternative approach (than serializing deserializing) so that I can still share my objects from webpage to webpage and improve loading time.
Thanks
Rahul
You should first analyze what the actual bottleneck is. Is it really the object serialization/deserialization?
If so, ask yourself, if all the objects need to be present on every request or if they can be reconstructed on demand. Then you could just store the key values to reconstruct those objects instead of the whole objects.
But if you need all those objects though, use more performant storage location than the default (files in the file system), maybe the memory (memcache).
Are all the objects you store necessary from page load to page load? If not then you need to keep those objects out of the session and only reconstruct them on the pages that you need them.
Every object you store in the session will get serialized and unserialized on every page load regardless if you actually need it. So you'll want to keep that to a minimum.
Another option is store only what you need to reconstruct the object in the session and not the entire object. For instance you can store a database id in the session and reconstruct the objects from the database when you need them.
As a rule of thumb you should try to limit your Session-size to 4KB or less (independent on what programming language you use). If your data get's bigger than that, you should start using Tables in a Database (like MySQL/PostgreSQL/...) to persist the data.
Example: Store a draft for a Blog Article
In the Session (with all it's images etc) vs
In the Article-DB-Table (where a flag draft=1).
Believe me, it's more convenient if you choose the DB (and you don't have to hassle with serialization).
Related
Good day to all,
I have a form with around 90 to 100 fields, divided into sub forms, which are loaded using ajax each time a form has to be displayed. but i would like to retain the data on the form fields every time a subform is loaded(lets say on an accidental page refresh or even if the user is switching between sub forms). What is the best way that this can be done.
I was thinking that i can store it in cookies or lets say in the database. But, storing it in the database would mean that i would have to query for the fields data every time a sub form is loaded. And again, if it was cookies, it has to read the data stored in the cookie files. I need some help with deciding what is the most efficient way, more in terms of speed.
What is the best way among these, or is there any other possibility to retain the fields data in the sub forms, every time they are loaded (which are loaded via AJAX each time.)
I am working with PHP and Codeigniter framework.
Thanks!!
A form like that needs to be durably stored. I would consider session state to smooth out the sub form loads, with writes to the database whenever the user updates something of consequence. Personally, I would start with a database-only solution, and then add session state if performance is an issue.
Cookies aren't meant to store large amounts of data. Even if it were possible, they bloat the request considerably (imagine 100 form fields all being transmitted with every request).
Local storage in the browser is also an option, though I would consider other options first.
I would first simplify it by using serialize:
$data = serialize(array_merge($_POST,$olddata));
Then that may be enough for you, but it's now super easy to store it anywhere since it is just a string. To reform it into its original state:
$data = unserialize($data);
.. wherever you end up pulling it from - database,session,etc..
Prose of database
It can also access from other computer too
You can store far far more data then cookie
Cones
If you retrive data by ajax it coukd cose more load on server
Cookie
Faster than database no query , fetch and all process .
Cones
Limited amount of space
However you can use local storage
So answer is database storage
Sorry if this seems obvious to the non-noob. Is it faster to:
Recreate an object instance each time someone goes to a page during a session
or
Store the object instance in a session variable when it first gets created, then always grab it from there when the page is accessed again
I'm not sure if this will turn out to be a "How long is a piece of string?" sort of question, but if it does, then perhaps you could let me know what factors are involved in making the decision?
Session data is stored as text, not binary data so somewhere behind the scenes when you toss it into the session the object is recreated anyway. It's probably a little bit slower than initializing it yourself since it has to do some string parsing but I doubt it's much to worry about. In short, it probably doesn't make a difference either way.
It certainly depends on how much logic is done, when the object is created. You should do some benchmarks with both variations.
Without measuring it, i'd say storing and retrieving should most times be faster.
For recreating objects you have to call possibly multiple constructors, etc, whereas retrieving shouldn't invoke any function calls.
It obviously depends on what fields you have in object, how many of them and how they are populated. Instantion of an object occurs every time you load a page anyway, so it's the matter of fields and their sources.
Just be wary of trying too hard to optimise this. Bear in mind that storing items in session can be heavy, particularly if your site is high traffic.
Also, I've seen a lot of people create an object, which accesses a database and loads it's attributes. This then gets stored in session, updated on postback and then saved back to teh database.
This is fine, but it makes for difficult concurrency checking - say your object has a timestamp of the last time saved - if you reload it each time prior to saving, you can easily check if the timestamp has changed since the last load, in which case you may need to stop the save from going ahead.
Either way, the difference is not going to be huge.
Assumption
I understand that it's not good to store to much data and it is needed to be as simple.
State today
Now I use as minimum needed and using simple data types (int and strings)
mainly for storing user's id and to tell if he is logged in.
must of my functions are static or singleton that has to be built each post/get.
I have trouble to representing the current state and changing it.
and get a largely static site.
most of state representing goes into javascript .
Target
for the other hand if I'll create a object that represent the entire website it will be much easier for me to maintain user's input , including database interaction.
simple question, how much data should be stored there?
example
One of the things i want to implement is
objects that relate to Database tables,
Let's take a page for a "car.update()".
Now if i store an object for it, that extends a connection to the Database with methods
for CRUD.
When I handle a post back from that page with details i could just put them in properties needed and call the update method.
situation now: I need to create a new object with that details and make an static update
Another example
storing previous search result and filter it using new data
In many cases the ideal amount would be none. Store the username in a cookie along with an HMAC hash used to verify the cookie was created by your site, and get everything else from the database (or cache) as needed. This makes it easy to load balance across servers because any server can handle any request and there's no state that needs to be shared between them.
This approach wouldn't be appropriate for banking or other top-security uses because if someone gets your cookie they connect as you. But for sites where you're not doing anything super critical it's great. The risk can also be mitigated somewhat by adding an expiration mechanism to your cookie handling. See chubbards great answer related to another HMAC question for more info.
note you can switch the way PHP stores data using session_set_save_handler. Then you don't have to change the calls and you improve performances/maintenance with the efficiency of database.
The minimum would be the user I.D.—assuming it is a logging in type of interface. But it is often helpful to include the most common aspects of that, like the user's permission and other items which are stored in the database, but are frequently referenced when constructing pages.
You shouldn't store an enormous amount of data, but you can without problems store some user-information if it helps you server you pages faster.
But if you want to build a more dynamic website, you will probably retreive more and more data from the database. So when you're connecting to a database after all, you could skip storing all kinds of information in the session, because you can just as well get them from the database. Most databases (including MySQL) have a quite efficient query cache that will make repeated queries lightning fast.
So in that case you'll need to save little more than the userid and maybe a small amount of flags.
I want to add some static information associated with string keys to all of my pages. The individual PHP pages use some of that information filtered by a query string. Which is the better approach to add this information? Generate a 100K (or larger if more info is needed later) PHP file with an associated array or add an other DB table with this info and query that?
The first solution involves loading the 100K file every time even if I use only some of the information on the current page. The second on the other hand adds an extra database call to the rendering of every page.
Which is the less costly if there are a large number of pages? Loading a PHP file or making an extra db call?
Unless it is shown to really be a bottleneck (be it including the php file or querying the database), you should choose the option that is best maintainable.
My guess is that it is the second option. Store it in a database.
Storing it in a database is a much better plan. With the database you can provide better data constraints, more easily cross reference with other data and create strong relationships. You may or may not need that at this time, but it's a much more flexible solution in the end.
What is the data used for? I'm wondering if the data you need could be stored in a session variable/cookie once it is pulled from the database which would allow you to not query the db on the rendering of every page.
If you were to leverage a PHP file then utilizing APC or some other opcode cache will mitigate performance concerns as your PHP files will only be loaded each time the file changes.
However, as others have noted, a database is the best place to store this stuff as it is much easier to maintain (this should be your priority to begin with).
Having ensured ease of maintenance and a working application, should you require a performance boost then generally accepted practice would be to cache this static data in an in-memory key/value store such as memcached. This will give you rapid access to your static values (for most requests).
I wouldn't call this information "static".
To me, it's just a routine call to get dome information from the database, among other calls being made to assemble whole page. What I am missing?
And I do agree with Dennis, all optimizations should be based on real needs and profiling. Otherwise it's effect could be opposite.
If you want to utilize some caching, consider to implement Conditional GET for the whole page.
whats the performance issues when we are storing 2-3 extra variables in session??
for:
to save 1-2 queries(per page load)?
To make code simpler?
Hit rate to the website is normal..
Edit
#all I m talking about two three session variables...simple values like number,ids etc
Every time a PHP script/page that uses sessions is accessed, the session data has to be read.
By default, that data is stored on disk as files (you can override that and use a database, for example)
So, basically, for every page load some amount of session data has to be read (and, very likely, written) by PHP. The more data you store in a session, the bigger the session files get.
If you only store a few variables, there is no problem. But if you start storing something like huge arrays, you'll run into problems if your hit rate increases.
--
If you want to "keep code simpler" by storing as much data as possible in a session, you might create more problems instead. For example - should you want to enable API access in the future, you'll possibly have to remove a lot of session data storage/retrieval code and replace it with other methods.
--
Might be unrelated to your problem:
If you want to store some sort of global application state in a session so you don't have to recalculate it, you should use some other caching methods instead of sessions.
There wouldnt be a performance issue. You can store objects and variables, in the session, and it wouldnt make much of a degrade of performance.
Actually, it sounds like you're going to end up saving yourself a bit, performance wise. If these values are simple strings or numbers, or even small arrays or objects, this will be your better option. If you are saving an array with thousands of key => value pairs, however, then it might be better to re-run the query, depending on whether you will need it in given circumstances.
Just remember, that each time you refresh, you will be firing the constructor of each object stored in the session variable. Big objects = heavy payload.
Its not as much of a performance question than it is practicality. Its obvious to me by reading your question that you would not contemplate storing huge arrays in a session.
The issue becomes practical when some action by another user needs to influence values stored in a current session, i.e. an array of bools that shows what a user can and can not access. Having those cached in a session makes revoking permissions impractical.
There's no reason to avoid storing strings and values that are considered to be immutable, or which can easily be re-set by an action of the current user (i.e. changing their user name).