There is certain userdata read from the (MySQL) database that will be needed in subsequent page-requests, say the name of the user or some preferences.
Is it beneficial to store this data in the $_SESSION variable to save on database lookups?
We're talking (potentially) lots of users. I'd imagine storing in $_SESSION contributes to RAM usage (very-small-amount times very-many-users) while accessing the database on every page request for the same data again and again should increase disk activity.
The irony of your question is that, for most systems, once you get a large number of users, you need to find a way to get your sessions out of the default on-disk storage and into a separate persistence layer (i.e. database, in-memory cache, etc.). This is because at some point you need multiple application servers, and it is usually a lot easier not to have to maintain state on the application servers themselves.
A number of large systems utilize in-memory caching (memcached or similar) for session persistence, as it can provide a common persistence layer available to multiple front-end servers and doesn't require long time persistence (on-disk storage) of the data.
Well-designed database tables or other disk-based key-value stores can also be successfully used, though they might not be as performant as in-memory storage. However, they may be cheaper to operate depending on how much data you are expecting to store with each session key (holding large quantities of data in RAM is typically more expensive than storing on disk).
Understanding the size of session data (average size and maximum size), the number of concurrent sessions you expect to support, and the frequency with which the session data will need to be accessed will be important in helping you decide what solution is best for your situation.
You can use multiple storage backends for session data in PHP. Per default its saved to files. One file for one session. You can also use a database as session backend or whatever you wan't by implementing you own session save handler
If you want your application most scalable I would not use sessions on file system. Imagine you have a setup with mutiple web servers all serving your site as a farm. When using session on filesystem a user had to be redirected to the same server for each request because the session data is only available on that servers filesystem. If you not using sessions on filesystem it would not matter which server is being used for a request. This makes the load balancing much easier.
Instead of using session on filesystem I would suggest
use cookies
use request vars across multiple requests
or (if data is security critical)
use sessions with a database save handler. So data would be available to each webserver that reads from the database (or cluster).
Using sessions has one major drawback: You cannot serve concurrent requests to the user if they all try to start the session to access data. This is because PHP locks the session once it is started by a script to prevent data from getting overwritten by another script. The usual thinking when using session data is that after your call to session_start(), the data is available in $_SESSION and will get written back to the storage after the script ends. Before this happens, you can happily read and write to the session array as you like. PHP ensures this will not destroy or overwrite data by locking it.
Locking the session will kill performance if you want to do a Web2.0 site with plenty of Ajax calls to the server, because every request that needs the session will be executed serially. If you can avoid using the session, it will be beneficial to user's perceived performance.
There are some tricks that might work around the problem:
You can try to release the lock as soon as possible with a call to session_write_close(), but you then have to deal with not being able to write to the session after this call.
If you know some script calls will only read from the session, you might try to implement code that only reads the session data without calling session_start(), and avoid the lock at all.
If I/O is a problem, using a Memcache server for storage might get you some more performance, but does not help you with the locking issue.
Note that the database also has this locking issue with all data it stores in any table. If your DB storage engine is not wisely chosen (like MyISAM instead of InnoDB), you'll lose more performance than you might win with avoiding sessions.
All these discussions are moot if you do not have any performance issues at all right now. Do whatever serves your intentions best. Whatever performance issues you'll run into later we cannot know today, and it would be premature optimization (which is the root of evil) trying to avoid them.
Always obey the first rule of optimization, though: Measure it, and see if a change improved it.
Related
Is there a more contemporary alternative to PHP session or is PHP session still the main choice to store information? I read this: https://pasztor.at/blog/stop-using-php-sessions. I'm still learning PHP and frankly, I'm quite clueless.
Your first assumption is incorrect. PHP Sessions are not where you store data. Databases, files, Document stores, etc. are where you store your data.
Session "data" is simply the variables included in the $_SESSION array in serialized form. You can run serialize() and unserialize() on variables to gain some insight into what these look like.
In your script, once you have started a session using session_start(), when you add change or delete variables in $_SESSION, php serializes this and stores it for you.
Once a session exists, and a user makes another request that is identified as being the same user (having the same session id) which has typically passed to the client via a cookie, then upon issuing session_start(), PHP reads the serialized data in the session file, and unserializes it, and stores it back into $_SESSION.
By default, PHP will store the individual session data as files on the filesystem. For a small or medium size application, this is highly performant.
So to be clear, what people store in PHP sessions is basically variables read out of whatever other persistent storage you might have, so that you can avoid doing things like re-querying a database to get the name and user_id for a user who has already logged into your application.
It is not the master version of that data, nor the place through which you will update that data should it change. That will be the original database or mongodb collection.
The article you posted has a number of stated and unstated assumptions including:
Devops/Sysadmins just decide to reconfigure PHP applications to change the session handlers (misleading/false)
The deployment involves a load balancer (possibly)
The load balancer doesn't support or use sticky sessions
He then goes on into some detail as to several alternatives that allow for shared session handlers to solve the race conditions he describes
As you stated, you aren't clear yet what sessions actually are, or how they work or what they do for you. The important thing to know about PHP scripts is that they are tied to a single request and sessions are a way of not repeating expensive database reads. It's essentially variable cache for PHP to use (or not) when it suits your design.
At the point you have a cluster, as pointed out in the article people often store data into shared resources which can be a relational database, or any of many other backends which each have different properties that match their goals.
Again, in order to change the session handlers, there is typically code changes being made to implement the session handler functions required, and there are ways to code things that mitigate the issues brought up in the article you posted, for just about every persistence product that people use.
Last but not least, the problems described exist to whatever degree with pretty much any clustered serverside process and are not unique to PHP or its session mechanism.
Usually, that will depends on the use case and other requirements of your application and most of the time people will use PHP frameworks to handle sessions.
Take for example, for Yii 2 framework, the framework provides different session classes for implementing the different types of session storage. Take a look at here https://www.yiiframework.com/doc/guide/2.0/en/runtime-sessions-cookies.
Learning the different types of sessions available out there, allows you to be able to make decisions by weighing the pros and cons. You can also read here for more understanding https://www.phparch.com/2018/01/php-sessions-in-depth/
Question basically says it all. I get a lot of traffic, about 200k hits a day. I want to store the original referrer (where they came from) in a session variable for various purposes. Is this a good idea or should I stick in a database instead?
You can do both at once :). PHP allows you define the storage logic of your sessions in scripts. This way it is possible to store sessions in a database as well. Check the manual of set_session_save_handler()
Using a database would have its advantages if you use load balancing (or plan to do it once). This way all web servers could read the session data from the same database (or cluster) and the load balancer would not have to worry about which request should be forwarded to which web server. If session data is stored in files, which is the default mechanism, then a load balancer has to forwared each request of a session to the same physical web server, which is much more complex, as the load balancer has to work on HTTP level.
You could just store the information in a cookie if you only need it for the user's current session. Then you don't need to store it at all on your end.
There are a few down sides as well:
They may have cookies disabled, so you may not be able to save it.
If you need the information next time you may not be able to get it, as it could have been deleted.
Not super secure so don't save passwords, bank info, etc.
So if needing this information is required no matter what, maybe its not the way to go. If the information is optional, then this will work.
The default PHP session handler is the file handler. So, the pertinent questions are:
Are you using more than 1 webserver without sticky sessions (load balancing)?
Are you running out of disk space?
Do you ever intend to do those?
If yes (to any), then store it in a database. Or, even better, calculate the stuff on every request (or cache it somewhere like Memcached). You could also store the stuff in a signed cookie (to prevent tampering).
I am developing a website. Currently, I'm on cheapo shared hosting. But a boy can dream and I'm already thinking about what happens with larger numbers of users on my site.
The visitors will require occasional database writes, as their progress in the game on the site is logged.
I thought of minimizing the queries by writing progress and other info live into the $_SESSION variable. And only when the session is destroyed (log out, browser close or timeout), I want to write the contents of $_SESSION to the database.
Questions:
Is that possible? Is there a way to execute a function when the sessions is destroyed by timeout or closing of the browser?
Is that sensical? Are a couple of hundred concurrent SQL queries going to be a problem for a shared server and is the idea of using $_SESSION as a buffer going to alleviate some of this.
Is there a way to execute a function when the sessions is destroyed by
timeout or closing of the browser?
Yes, but it might not work the way you imagine. You can define your own custom session handler using session_set_save_handler, and part of the definition is supplying the destroy and gc callback functions. These two are invoked when a session is destroyed explicitly and when it is destroyed due to having expired, so they do exactly what you ask.
However, session expiration due to timeout does not occur with clockwork precision; it might be a whole lot of time before an expired session is actually "garbage-collected". In addition, garbage collection triggers probabilistically so in theory there is the chance that expired sessions will never be garbage collected.
Is that sensical? Are a couple of hundred concurrent SQL queries going
to be a problem for a shared server and is the idea of using $_SESSION
as a buffer going to alleviate some of this.
I really wouldn't do this for several reasons:
Premature optimization (before you measure, don't just assume that it will be "better").
Session might never be garbage collected; even if this doesn't happen, you don't control when they are collected. This could be a problem.
There is a possibility of losing everything a session contains (e.g. server reboots), which includes player progress. Players do not like losing progress.
Concurrent sessions for the same user would be impossible (whose "saved data" wins and remains persisted to the database?).
What about alternatives?
Well, since we 're talking about el cheapo shared hosting you are definitely not going to be in control of the server so anything that involves PHP extensions (e.g. memcached) is conditional. Database-side caching is also not going to fly. Moreover, the load on your server is going to be affected by variables outside your control so you can't really do any capacity planning.
In any case, I 'd start by making sure that the database itself is structured optimally and that the code is written in a way that minimizes load on the database (free performance just by typing stuff in an editor).
After that, you could introduce read-only caching: usually there is a lot of stuff that you need to display but don't intend to modify. For data that "almost never" gets updated, a session cache that you invalidate whenever you need to could be an easy and very effective improvement (you can even have false positives as regards the invalidation, as long as they are not too many in the grand scheme of things).
Finally, you can add per-request caching (in variables) if you are worried about pulling the same data from the database twice during a single request.
It's not a good idea to write data when the session is destroyed. Since the session datas could be destroyed via a garbage collector configured by your hoster, you don't have any idea when the session is really closed until the user's cookie is out of date.
So... I suggest you to use either a shared memory (RAM) cache system like memcache (if your hoster offers it) or a disk based cache system.
By the way, if your queries are optimized, columns correctly indexed, etc., your shared hosting could take tons of queries at the "same time".
Is that sensical? Are a couple of hundred concurrent SQL queries going to be a problem for a shared server and is the idea of using $_SESSION as a buffer going to alleviate some of this.
No. First and foremost, you never know what happens to a session (logout is obvious, where a time-out is nearly undetectable), so it's not a trustworthy caching mechanism at any rate. If there are results that you query multiple times over the span of a few request, which don't change all too often, save the results of those queries to a dedicated caching mechanism, such as APC, or memcached.
Now, I understand your webhost will not provide these caching systems, but then, you probably can do different things to optimise your site. For starters, my most complex software products (which are fairly complex) query the database about 6 times per page, on average. If the result is reusable, I tend to use caching, so that lowers the number of queries.
On top of that, writing decent queries is more important; the quality of your design and queries is more important than the quantity. If you get your schema, indexes and queries right, 10 queries are faster than one query that's not optimised. I'd invest my time investigating how to write efficient queries, and read up on indexing, rather than trying to overcome the problem with a "workaround", such as caching in a session.
Good luck, I hope your site becomes that big of a success you will actually need the advice above ;)
Actually you could use the $_SESSION as a buffer to avoid duplicate reads, thet seems a good idea to me (memcached even better than that), surely not for delaying writing (that is much more complex and should be handled by the db);
you could use a simple hash that you save in $_SESSION
$cache = array();
$_SESSION['cache'] = $cache;
then when you have to make a query
if(isset($_SESSION['cache'][$id]){
//you have a cache it
$question = $_SESSION['cache'][$id];
}else{
//no cache, retrieve your $question and save it in the cache
$_SESSION['cache'][$id] = $question ;
}
Right now I'm stuck between using PHP's native session management, or creating my own (MySQL-based) session system, and I have a few questions regarding both.
Other than session fixation and session hijacking, what other concerns are there with using PHP's native session handling code? Both of these have easy fixes, but yet I keep seeing people writing their own systems to handle sessions so I'm wondering why.
Would a MySQL-based session handler be faster than PHP's native sessions? Assuming a standard (Not 'memory') table.
Are there any major downsides to using session_set_save_handler? I can make it fit my standards for the most part (Other than naming). Plus I personally like the idea of using $_SESSION['blah'] = 'blah' vs $session->assign('blah', 'blah'), or something to that extent.
Are there any good php session resources out there that I should take a look at? The last time I worked with sessions was 10 years ago, so my knowledge is a little stagnant. Google and Stackoverflow searches yield a lot of basic, obviously poorly written tutorials and examples (Store username + md5(password) in a cookie then create a session!), so I'm hoping someone here has some legitimate, higher-brow resources.
Regardless of my choice, I will be forcing a cookie-only approach. Is this wrong in any way? The sites that this code will power have average users, in an average security environment. I remember this being a huge problem the last time I used sessions, but the idea of using in-url sessions makes me extremely nervous.
The answer to 2) is - id depends.
Let me explain: in order for the session handler to function properly you really should implement some type of lock and unlock mechanism. MySQL conveniently have the functions to lock table and unclock table. If you don't implement table locking in session handler then you risk having race conditions in ajax-based requests. Believe me, you don't want those.
Read this detailed article that explains race condition in custom session handler :
Ok then, if you add LOCK TABLE and UNLOCK TABLE to every session call like you should, then the your custom session handler will become a bit slower.
One thing you can do to make it much faster is to use HEAP table to store session. That means data will be stored in RAM only and never written to disk. This will work blindingly fast but if server goes down, all session data is lost.
If you OK with that possibility of session being lost when server goes down, then you should instead use memcache as session handler. Memcache already has all necessary functions to be used a php session handler, all you need to do it install memcache server, install php's memcache extension and then add something like this to you php.ini
[Session]
; Handler used to store/retrieve data.
; http://php.net/session.save-handler
;session.save_handler = files
session.save_handler = memcache
session.save_path="tcp://127.0.0.1:11215?persistent=1"
This will definetely be much faster than default file based session handler
The advantages of using MySQL as session handler is that you can write custom class that does other things, extra things when data is saved to session. For example, let's say you save an object the represents the USER into session. You can have a custom session handler to extract username, userid, avatar from that OBJECT and write them to MySQL SESSION table into their own dedicated columns, making it possible to easily show Who's online
If you don't need extra methods in your session handler then there is no reason to use MySQL to store session data
PHP application loses session information between requests. Since Stanford has multiple web servers, different requests may be directed to different servers, and session information is often lost as a result.
The web infrastructure at Stanford consists of multiple web servers which do not share session data with each other. For this reason, sessions may be lost between requests. Using MySQL effectively counteracts this problem, as all session data is directed to and from the database server rather than the web cluster. Storing sessions in a database also has the effect of added privacy and security, as accessing the database requires authentication. We suggest that all web developers at Stanford with access to MySQL use this method for session handling.
Referred from http://www.stanford.edu/dept/its/communications/webservices/wiki/index.php/How_to_use_MySQL-based_sessions
This may help you.
Most session implementations of languages’ standard libraries do only support the basic key-value association where the key is provided by the client (i.e. session ID) and the value is stored on the server side (i.e. session storage) and then associated to the client’s request.
Anything beyond that (especially security measures) are also beyond that essential session mechanism of a key-value association and needs be added. Especially because these security measures mostly come along with faults: How to determine the authenticity of a request of a certain session? By IP address? By user agent identification? Or both? Or no session authentication at all? This is always a trade-off between security and usability that the developer needs to deal with.
But if I would need to implement a session handler, I would not just look for pure speed but – depending on the requirements – also for reliability. Memcache might be fast but if the server crashed all session data is lost. In opposite to that, a database is more reliable but might have speed downsides opposed to memcache. But you won’t know until you test and benchmark it on your own. You could even use two different session handlers that handle different session reliability levels (unreliable in memcache and reliable in MySQL/files).
But it all depends on your requirements.
They are both great methods, there are some downsides to using MySQL which would be traffic levels in some cases could actually crash a server if done incorrectly or the load is just too high!
I recommend personally given that standard sessions are already handled properly to just use them and encrypted the data you do not want the hackers to see.
cookies are not safe to use without proper precaution. Unless you need "Remember me" then stick with sessions! :)
EDIT
Do not use MD5, it's poor encryption and decryptable... I recommend salting the data and encrypting it all together.
$salt = 'dsasda90742308408324708324832';
$password = sha1(sha1(md5('username').md5($salt));
This encryption will not be decrypted anytime soon, I would considered it impossible as of now.
I'm interested in what is the more efficient way of handling user data in my game. When someone is playing the game, data from the server will constantly need to be queried from the database.
So I want to know if it is more efficient to keep querying the database or to store the data from the first query in a session and then keep using the session every time I need the data.
This is probably a stupid question as I think it is going to be sessions that are better, but it's best to be 100% sure :)
If the data will only be updated by the client session in question, then sure, cache it in the session. If other processes will be updating it, then you need to either reobtain it from the database or work out some method for invalidating your session's cached version.
Shared state goes in the database, unless you are ready to manage shared access yourself, which is a big pain.
Often-updated user-specific state goes into the session (if you issue an UPDATE every time anyone presses a key in your game, your database is dead).
If you need a superfast session architecture, try memcached.
Using sessions will be more efficient. But (assuming the data in the session as cache) any other script not invoked by the user, which updates the dataset you're using, should invalidate the cache somehow.
This means that the cache (now maitained in a session) should be accessible to other scripts. So it might be easier to maintain the cache in files (or you could use php_apc or memcached) instead of sessions.
I think there are many caching classes that are good but the only experience I have is with Zend_Cache and it is really easy to use. It supports APC, memcached, file, etc as backends (a.k.a storage)