Sessions VS Cookies

use of sessions vs cookies

[eltreno]

Hi I am building a site which will (hopefully) have possibly 1000's of users logged in at once.

I am not using cookies at all, I am using sessions mainly because if cookies are not enabled I can use sessionid's in url and site can still be used.

My question is as I am only storing max 6 vars in each session which are mainly id's and a user name, access level and a maybe one other short stringsay(10) chars, Is there a problem with doing this or should I just be concerned on the amount of dick space that could be used when storing all sessions if 1000's are logged in at once?

Also would this become a performance issue as php has to search thru sessions to get info or does this need to be done anyway, ie find session to make sure it exists regardles?

I am curious, why use cookies over sessions if you don't want the session to last longer then current browser session as I feel it's just easier to use sessions?

Also found when validating with w3c, when php automatically writes session id's to URL they don't validate because it write & in url instead of &
Has anyone seen this problem before.?

OK theres a few questions here :) but I'm worried I might be to confident on using session over cookies.

Cheers
Trent

[Mr_Fern]

Usage of cookies with sessions over just sessions alone, this is an excerpt from the PHP manual on Session Handling Functions

Full Text: [us3.php.net...]

Sessions and security
The session module cannot guarantee that the information you store in a session is only viewed by the user who created the session. You need to take additional measures to actively protect the integrity of the session, depending on the value associated with it.

Assess the importance of the data carried by your sessions and deploy additional protections -- this usually comes at a price, reduced convenience for the user. For example, if you want to protect users from simple social engineering tactics, you need to enable session.use_only_cookies. In that case, cookies must be enabled unconditionally on the user side, or sessions will not work.

There are several ways to leak an existing session id to third parties. A leaked session id enables the third party to access all resources which are associated with a specific id. First, URLs carrying session ids. If you link to an external site, the URL including the session id might be stored in the external site's referrer logs. Second, a more active attacker might listen to your network traffic. If it is not encrypted, session ids will flow in plain text over the network. The solution here is to implement SSL on your server and make it mandatory for users.

External from that question, I'm curious how many servers you plan to purchase/lease out for this site?

[eltreno]

Well at this point I'm going to test the site with a group of around 10-500 users and see what the feedback is

If it's good then I shall go with a dedicated server, and basically 'live and learn' from there

I am currently testing on a shared server I know thats not the way to go to run a good site but as I am a startup and all cash is off my back I need to make sure there is some interest before taking a bigger plundge. But I am very keen for that plunge of course!

So to be honest I have no idea how many servers i will need etc, I have built the site to be minimum in page weight, very minimum actually the main part of this site is database usage, so I'll just have to live and learn I suppose

If you know any good sites explaining how many servers you need in ratio to users etc that is of great interest to me.

Thanks for your help

[Mr_Fern]

I was just curious because I'm currently running a site myself, with relatively small amount of queries per page, anywhere from 8 to 25, largely selects, few updates. Most if not all queries utilize indexes. The site however starts to slow in page load when users online starts growing beyond 1200. This is all on a Dual Xeon (4cpus) 2.4 Ghz machine with 8 GB of RAM. I'm sure there's some optimizations I could make on the PHP (using Zend or another accelerator, optimizing the code to be more memory intensive less CPU intensive), but still there are limitations.

I'm about to strip the coding and files to their own server and leave the database running on the current machine. I also plan to place any image files on a seperate server to further help out.

I failed to plan for a lot of this and I suffer from complaints and my own gripes with the speed. If you're intending on having 1000's of users logged in at a time, you're going to need a few servers, starting off with 2 might be a good bet, and then expanding on that as revenue grows.

[eltreno]

Thanks for that It's good to hear

Yes I think I'll take it day by day and go from there but I definatley expect to have to move servers, which will be another story when I come to it :)

Cheers

[asmtony]

What I have done to prevent time issues is. I have a timer class (many free ones out there if you are not sure how to write) that times all the individual queries/inserts as well as timing the full page. It is interesting watching the times go up as site grows but you can make a conscious decision about the point at which you will make changes to the speed of the queries. Eg if this query hits 2 seconds I will look at optimizing it (posh word for drop some data) or getting a new server. Hope this helps. by the way sessions for me

[eltreno]

I have used timers at simply top and bottom of script to see how long a page takes to make which simply looks at diff between top and bottom time.

So would a query timer simple do the same thing but around the query only

eg
start-timer
$sql = "select etc";
$result = mysql_query($sql) or showError();
end-time

time take = end-time - start-time;

Or am I way off! :)

Trent