handling thouthands of users simultineously...what it takes

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

Post Reply
User avatar
newmember
Forum Contributor
Posts: 252
Joined: Fri Apr 02, 2004 12:36 pm

handling thouthands of users simultineously...what it takes

Post by newmember »

Hi,

Sites with thouthands of simulteneous users...

I'm curious what are design considerations when you try to build (from scrach) one ?
(I'm ignoring here the obvious need for suitable server/software enviroment)

More specifically:

1) database complications/practices?

2) php code complications/practices?


if these topics were discussued elsewhere be kind to give a link :)


thanks
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

(some random things from Advanced PHP Programming.

Learn about clustering, caching and distributed environments.

Multiple servers = redundancy + capacity

Never assume that two people have access to the same data unless it is an explicitly shared resource (no files for dynamic information, no DBMs, no requirement that subsequent requests use same resource)

Plan to fail.

Design for cohabitation.

Namespace functions.

Master/slave database setups.
User avatar
newmember
Forum Contributor
Posts: 252
Joined: Fri Apr 02, 2004 12:36 pm

Post by newmember »

i don't quite grasp most of things you wrote :?
Never assume that two people have access to the same data unless it is an explicitly shared resource (no files for dynamic information, no DBMs, no requirement that subsequent requests use same resource)
why it is important?
Plan to fail.


i assume you mean data backups...
Design for cohabitation.
please explain more...
Namespace functions.
What is it?
User avatar
Chris Corbyn
Breakbeat Nuttzer
Posts: 13098
Joined: Wed Mar 24, 2004 7:57 am
Location: Melbourne, Australia

Post by Chris Corbyn »

I'm going to answer from a server point of view here about apache configuration.

If you're HTTPd server is putting a heavy load on your server through many simultaneous connections try keeping KeepAlive on but bring it right down to 2-3 seconds. Without that, proccesses hang around for a while (default 20 secs I think) after they've exhausted themselves and waste RAM that could be being used elsewhere.

That aside, as Ambush mentioned, clustering is also a great way to scale up an app to handle more connections (I was just rambling about this in a thread in General Discussion a few moment ago :P).

As for practises in your coding.

Benchmark.

Make calls to microtime throughout your code, check where things are lagging a see if you can refactor or modify the code in some way to bring the load down. Don't use persistent MySQL connections... that really would add a heavy load to your server.

If you get into a habit of benchmarking code though you'll pick up on where things get slow and you'll figure out ways to improve upon it ;)
User avatar
newmember
Forum Contributor
Posts: 252
Joined: Fri Apr 02, 2004 12:36 pm

Post by newmember »

can you shed more ligth on some of the things Ambush Commander wrote?
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

access to same data
This is important for clustering. If your app write a file to the server, expecting it will be available to another request, and it turns out that the next request gets routed to a different server, you'll have problems.
plan to fail
More in terms of commodity hardware, or if one server goes down the whole site doesn't crash.
Design for cohabitation.
If you decide that it's necessary to split up services on to different servers, be careful to design the code that it's still possible to put them back on the same server if a server is underutilized.
Namespace functions.
Instead of displayError(), name it something like Common_displayError. This is more important for larger applications.
User avatar
Chris Corbyn
Breakbeat Nuttzer
Posts: 13098
Joined: Wed Mar 24, 2004 7:57 am
Location: Melbourne, Australia

Post by Chris Corbyn »

newmember wrote:i don't quite grasp most of things you wrote :?
Never assume that two people have access to the same data unless it is an explicitly shared resource (no files for dynamic information, no DBMs, no requirement that subsequent requests use same resource)
why it is important?
I think Ambush is referring to row-level-locking that certain MySQL database engine implement. Never assume every script has exclusive access to the same data simultaneously.
Plan to fail.


i assume you mean data backups...
Not backups... though that's one of the first things you should have organised :) Plan to fail: Don't assume everything's going to work first time. Write what you planned, test it, improve it. Test it again, imporve it again. There's always room for improvement.
Design for cohabitation.
please explain more...
Namespace functions.
What is it?
Hmm... Ambush? :? No clue what this refers too :P

EDIT | Meh I'm too slow... and mis-interpretted some of your statements :P
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

Heehee, post phasing. All the points are important, anyway.
User avatar
newmember
Forum Contributor
Posts: 252
Joined: Fri Apr 02, 2004 12:36 pm

Post by newmember »

thanks :D guys(or girls :P )
Post Reply