I have a php webservice which can be called (from mobile phones) to perform certain task. For these tasks to be done, the caller must be “logged in.” What is the best way to handle the authentication?
Currently, I’m just using SESSIONS. The client calls a login API, and any other API needed. But I’m concerned about the impact of having 200,000 people all calling this service and have all of those sessions. I not sure how the server will respond. Any tips? How is this typically handled? Like facebook, flickr, etc….
If this is being called by a custom client program (i.e. you mobile phones), and not the browser, why “log them in” at all. Rather, simply use HTTP Authentication (either DIGEST or BASIC if you’re going SSL, or your own scheme), and “log them in” every time.
Then you don’t have to worry about sessions, about load balancing, and fail over, etc. Keep it stateless.
Addenda:
Certainly, fewer hits to the DB are better, that’s just a general rule. But at the same time, many hits to the DB are handled by cached pages on the DB server, or possibly application caches so that they never hit the DB server. So, in some cases, particularly single row queries against an indexed column, DB hits can be very cheap.
Now, one might consider if they’re both stored and readily accessed, what’s really the difference between a cache bit of the database, and a unique user session.
Well, primarily, the difference is in the contract with the data. A cached item has lifespan directly proportional to the amount of memory you have and the amount of uncached activity happening. Give it a small amount of memory, and the cached item likely has a very short lifespan. Give it a lot of memory, and the cached item has a much better chance of hanging around. If the amount of memory for cached data is large enough to where repeated activity for that data continues to use the cache, the cache is a big win. If your cache is recycling so fast nothing is ever “in” the cache, you cache has almost no value. But the point is that the system will work with or without the cache, the cache is simply a performance enhancement.
A session, however, has a different contract. Many sessions have a specific, minimum lifespan, typically measured in minutes: 10, 20, even 30 minutes.
That means that if a user hit your site just once, you must dedicate resources to that user even if he never comes back. You have to, otherwise the session offer effectively no value.
If you get a lot of traffic, you get a lot of new sessions to manage. In theory, under bad circumstance, sessions can spike without limit. If you suddenly get 10,000 hits on your site, you get to manage the remains of those hits for the minimal lifespan of your session. You have to dedicate resources (memory or disk) to them, you have to keep track of them, and then, inevitably, you have to clean them up.
A cache is a fixed resource. It only grows to the size you configure it. You have no obligation to keep anything in the cache, and as discussed earlier, the system will function with or without the cache. Caches naturally recycle. If you get that surge of 10,000 hits, they’ll possibly roll your cache, but after that they leave no mark on your system. They can hit and be gone in 1 or 2 minutes, never to be seen again.
Finally, with sessions, you need to share them among your infrastructure so that they travel with the user if they hop from machine to machine (for whatever reason). Caches don’t. Ideally you want to keep a user local to a set of resources, so that the caches can do their job, but the system works whether they move or stay (it just works better if they stay, because of the cache reuse). If you don’t replicate your sessions, they don’t work at all.
DB hits add up, they can be cheap, but they’re never free. But a session has its own costs as well, so it important to consider them both and how they apply within your architecture.