Large Scale PHP Application Design Questions

[Jesse Burns]

I'm about to start working on my first large scale site (in my opinion) that
will hopefully have 1000+ users a day. ok, this isn't on the google/facebook
scale, but it's going to be have more hits than just family and friends.

Either way, I'm planning on this site blowing up once I have enough of a
feature set, so I'm concerned about performance and scalability in the long
run.

I've worked for a software company, but I've never programmed PHP
professionally (looking for an entry level job, wink wink ).

I was wondering if sites like Sitepoint, MySpace, Facebook, etc... actually
use DB abstraction layers and template engines.

I also plan on using the code for this site for my portfolio, so I'd like to
have as much original code as possible, that's why I'm not even considering
using a framework (I've dabbled a bit with CakePHP and ZF), so I won't
bother asking about using them for large scale sites.

I've been doing a lot of research, and it seems to me that using PHP as a
templating engine itself and creating my own DB class using native DB calls
(going to use MySQL until I find it no longer suites my needs) would be the
most efficient approach.

I do plan on separating Data/Business/Presentation logic to make maintenance
easier, so that's the only reason I'm considering using a Template engine to
separate the Business/Presentation layers, and then either PDO, ADOdb or
PEAR::DB for the data layer.

But once again, I've come to the conclusion that using pure PHP to separate
the Business/Presentation layers, while using my own home brewed DB class as
the data layer would be the best way to go regarding
performance/scalability.

Are there professionals out there with experience working on large scale
sites/applications that can lend their two cents?

[Jerry Stuckle]

Jesse Burns wrote:

I'm about to start working on my first large scale site (in my opinion) that
will hopefully have 1000+ users a day. ok, this isn't on the google/facebook
scale, but it's going to be have more hits than just family and friends.

Either way, I'm planning on this site blowing up once I have enough of a
feature set, so I'm concerned about performance and scalability in the long
run.

I've worked for a software company, but I've never programmed PHP
professionally (looking for an entry level job, wink wink ).

I was wondering if sites like Sitepoint, MySpace, Facebook, etc... actually
use DB abstraction layers and template engines.

I also plan on using the code for this site for my portfolio, so I'd like to
have as much original code as possible, that's why I'm not even considering
using a framework (I've dabbled a bit with CakePHP and ZF), so I won't
bother asking about using them for large scale sites.

I've been doing a lot of research, and it seems to me that using PHP as a
templating engine itself and creating my own DB class using native DB calls
(going to use MySQL until I find it no longer suites my needs) would be the
most efficient approach.

I do plan on separating Data/Business/Presentation logic to make maintenance
easier, so that's the only reason I'm considering using a Template engine to
separate the Business/Presentation layers, and then either PDO, ADOdb or
PEAR::DB for the data layer.

But once again, I've come to the conclusion that using pure PHP to separate
the Business/Presentation layers, while using my own home brewed DB class as
the data layer would be the best way to go regarding
performance/scalability.

Are there professionals out there with experience working on large scale
sites/applications that can lend their two cents?

Don't worry about performance until it becomes a problem. 1000 visitors
a day is nothing.

Design a good site and use good programming practices. Things like
templating engines have their use - mostly in rapid development. They
don't necessarily make maintenance any easier or harder.

But also, this may not be the best site for you to cut your teeth on.

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attgl obal.net
=============== ===

[larry]

Don't expect everything to go just right the first time. Working on a
big project myself (as I learn PHP) I've repeatedly had to go back and
recode finished sections when I ran into a roadblock or potential
design flaw.

If its something that's going to grow, look early-on into how to
organize your files and present your page(s) - partly for security
partly for sanity.

Name your variables, fields, and functions well ( I use: table_field
for all DB fields, and local variables are pretty descriptive too)

Format your code (the PEAR formatting tips are an excellent start).

Setup function libraries for your POST, GET, and DB input/output calls
(just about anything else that gets repeated) so you have just one
place to refine data filtering as you progress.
Find and use a good IDE (I use Quanta on Linux) it does sooo many
great things like project-wide search-replace.

Also PHPMyAdmin is THE BEST utility for doing MySQL development work,
(you should still know how to do MySQL from the MYSQLprompt/ and
direct calls) PHPMyAdmin just makes MySQL work go so much quicker.

[C. (http://symcbean.blogspot.com/)]

On 17 Oct, 03:36, "Jesse Burns" <jburns...@jbwe bware.comwrote:

I'm about to start working on my first large scale site (in my opinion) that
will hopefully have 1000+ users a day. ok, this isn't on the google/facebook
scale, but it's going to be have more hits than just family and friends.

This is not a huge volume.

>
I was wondering if sites like Sitepoint, MySpace, Facebook, etc... actually
use DB abstraction layers and template engines.

I also plan on using the code for this site for my portfolio, so I'd like to
have as much original code as possible, that's why I'm not even considering
using a framework (I've dabbled a bit with CakePHP and ZF), so I won't
bother asking about using them for large scale sites.

I've been doing a lot of research, and it seems to me that using PHP as a
templating engine itself and creating my own DB class using native DB calls
(going to use MySQL until I find it no longer suites my needs) would be the
most efficient approach.

I do plan on separating Data/Business/Presentation logic to make maintenance
easier, so that's the only reason I'm considering using a Template engine to
separate the Business/Presentation layers, and then either PDO, ADOdb or
PEAR::DB for the data layer.

But once again, I've come to the conclusion that using pure PHP to separate
the Business/Presentation layers, while using my own home brewed DB class as
the data layer would be the best way to go regarding
performance/scalability.

Are there professionals out there with experience working on large scale
sites/applications that can lend their two cents?

Think about version control before you start writing the code - it'll
make life a lot simpler in the long run. Similarly plan the testing
ahead - I'd recommend going for continious integration testing as a
must have and unit testing as a nice to have.

Using abstraction anywhere is a trade-off between productivity and
performance - IME having an abstraction layer does not really make
code portable across DBMS. I'm not a fan of pure ORM but encapsulating
data sources as objects (using a factory pattern) can make portability
less painful and make for better code management.

As Larry suggests, stick to a good, standard style guide. Document
your code properly - and find a code document tool which suits you
(PHPDocumentor, PHPXRef....).

Do structure your common code as includes within a directory named in
the include_path, and always include/require using the path relative
to this dir.

When doing your database design - don't use autoincrement ids - this
closes the door on a lot of routes for scaling your application beyond
a single DBMS (use a sequence number and repository identifier (e.g.
DB host name) instead if there is no intrinsic key).

Get your DNS registration seperately from your hosting - if you tie
them both to the same supplier you could end up being held hostage by
their provision plans if you really do hit the big time.

The guideline I've always followed is to avoid writing code wherever
necessary - there is a lot of good quality PHP code published already
and free to use - unfortunately its a very small amount in comparison
to the amount of bad PHP code. You'll always get lots of opinions
here.

HTH

C.

[Erwin Moller]

C. (http://symcbean.blogspot.com/) schreef:

(A few comments)

>
Do structure your common code as includes within a directory named in
the include_path, and always include/require using the path relative
to this dir.

That is good advise.

I always include 1 file everywhere in my project too.
Put stuff like this into it:

$newincludepath =
get_include_pat h().PATH_SEPARA TOR.'/whatever/myproject/www/includes';
ini_set("includ e_path", $newincludepath );

Makes life a lot easier indeed, especially when you include other files
in your already included file (or more nesting).

>
When doing your database design - don't use autoincrement ids - this
closes the door on a lot of routes for scaling your application beyond
a single DBMS (use a sequence number and repository identifier (e.g.
DB host name) instead if there is no intrinsic key).

What?
I don't think that is good advise.
IMHO it is ALWAYS a good idea to use autoincrement PRIMARY KEYS on every
table when designing relational databases.

I do not see how this closes the door if you scale your app up to
multiple databases.
Care top explain?

The guideline I've always followed is to avoid writing code wherever
necessary - there is a lot of good quality PHP code published already
and free to use - unfortunately its a very small amount in comparison
to the amount of bad PHP code. You'll always get lots of opinions
here.

Hmm, I prefer writing my own code for excactly that reason! ;-)
It is VERY hard for a newbie to judge which code is good and which code
is bad.
Writing your own code increases your understanding of whatever problem
it is you are working on.

just my 2 cent.

Regards,
Erwin Moller

>
HTH

C.

--

[Erwin Moller]

Michael Vilain schreef:

In article <48************ *********@news. xs4all.nl>,
Erwin Moller
<Si************ *************** *************** @spamyourself.c omwrote:

>C. (http://symcbean.blogspot.com/) schreef:

(A few comments)

>>Do structure your common code as includes within a directory named in
the include_path, and always include/require using the path relative
to this dir.

That is good advise.

I always include 1 file everywhere in my project too.
Put stuff like this into it:

$newincludepat h =
get_include_pa th().PATH_SEPAR ATOR.'/whatever/myproject/www/includes';
ini_set("inclu de_path", $newincludepath );

Makes life a lot easier indeed, especially when you include other files
in your already included file (or more nesting).

>>When doing your database design - don't use autoincrement ids - this
closes the door on a lot of routes for scaling your application beyond
a single DBMS (use a sequence number and repository identifier (e.g.
DB host name) instead if there is no intrinsic key).

What?
I don't think that is good advise.
IMHO it is ALWAYS a good idea to use autoincrement PRIMARY KEYS on every
table when designing relational databases.

I do not see how this closes the door if you scale your app up to
multiple databases.
Care top explain?

>>The guideline I've always followed is to avoid writing code wherever
necessary - there is a lot of good quality PHP code published already
and free to use - unfortunately its a very small amount in comparison
to the amount of bad PHP code. You'll always get lots of opinions
here.

Hmm, I prefer writing my own code for excactly that reason! ;-)
It is VERY hard for a newbie to judge which code is good and which code
is bad.
Writing your own code increases your understanding of whatever problem
it is you are working on.

just my 2 cent.

Regards,
Erwin Moller

>>HTH

C.

--

Hi Michael,

I've also only coded small projects and not bothered to use anything but
autoincremented primary keys for my tables that needed them. But I can
see schreef's point for MySQL databases.

His name is NOT schreef.
I am from the Netherlands and my usenetclient is in Dutch.
'Schreef' means 'wrote'.
His nick here is 'C'.
Sorry for the confusion (I'll try to teach my thunderbird to speak
english soon.) ;-)
MySQL doesn't really have the

behind-the-scenes ability to put it's storage in alternate locations.
Then again, I haven't managed large MySQL installations (e.g.
multi-million row tables). There may be a way to store such files
distributed around a filesystem, but I'm not aware of it. Oracle and
other production-class DBMS's allow for allocating tablespaces whereever
you want. It was a common thing to add disks to a server and setup
Oracle data on them when I managed Solaris systems.

Yes, my favorite Postgres can also do that.
And besides that: If you use multiple database (not just a larger
filesystem), you can also still use a (centrally distibuted)
autoincrement PK.

>
So, I think schreef's workaround for this shortcoming is to use
multi-system databases. schreef, can you explain what you mean and why?

C (alias 'schreef' from now on ;-) ), generally knows very well what he
is talking about, so I am curious too. :-)

Regards,
Erwin Moller

[Norman Peelman]

Michael Vilain wrote:

In article <48************ *********@news. xs4all.nl>,
Erwin Moller
<Si************ *************** *************** @spamyourself.c omwrote:

>C. (http://symcbean.blogspot.com/) schreef:

(A few comments)

>>Do structure your common code as includes within a directory named in
the include_path, and always include/require using the path relative
to this dir.

That is good advise.

I always include 1 file everywhere in my project too.
Put stuff like this into it:

$newincludepat h =
get_include_pa th().PATH_SEPAR ATOR.'/whatever/myproject/www/includes';
ini_set("inclu de_path", $newincludepath );

Makes life a lot easier indeed, especially when you include other files
in your already included file (or more nesting).

>>When doing your database design - don't use autoincrement ids - this
closes the door on a lot of routes for scaling your application beyond
a single DBMS (use a sequence number and repository identifier (e.g.
DB host name) instead if there is no intrinsic key).

What?
I don't think that is good advise.
IMHO it is ALWAYS a good idea to use autoincrement PRIMARY KEYS on every
table when designing relational databases.

I do not see how this closes the door if you scale your app up to
multiple databases.
Care top explain?

>>The guideline I've always followed is to avoid writing code wherever
necessary - there is a lot of good quality PHP code published already
and free to use - unfortunately its a very small amount in comparison
to the amount of bad PHP code. You'll always get lots of opinions
here.

Hmm, I prefer writing my own code for excactly that reason! ;-)
It is VERY hard for a newbie to judge which code is good and which code
is bad.
Writing your own code increases your understanding of whatever problem
it is you are working on.

just my 2 cent.

Regards,
Erwin Moller

>>HTH

C.

--

I've also only coded small projects and not bothered to use anything but
autoincremented primary keys for my tables that needed them. But I can
see schreef's point for MySQL databases. MySQL doesn't really have the
behind-the-scenes ability to put it's storage in alternate locations.
Then again, I haven't managed large MySQL installations (e.g.
multi-million row tables). There may be a way to store such files
distributed around a filesystem, but I'm not aware of it. Oracle and
other production-class DBMS's allow for allocating tablespaces whereever
you want. It was a common thing to add disks to a server and setup
Oracle data on them when I managed Solaris systems.

MySQL5.1 has tablespaces and the ability to store tables in different
places via the: DATA DIRECTORY='/full/path', and INDEX
DIRECTORY='/full/path/' directives.

http://dev.mysql.com/doc/refman/5.1/...ate-table.html

....about half way down the page. Some catches, haven't tried it myself.

So, I think schreef's workaround for this shortcoming is to use
multi-system databases. schreef, can you explain what you mean and why?

--
Norman
Registered Linux user #461062

[Jesse Burns]

Thanks for the feedback folks, it's much appreciated.
"Jesse Burns" <jb*******@jbwe bware.comwrote in message
news:gd******** **@aioe.org...

I'm about to start working on my first large scale site (in my opinion)
that will hopefully have 1000+ users a day. ok, this isn't on the
google/facebook scale, but it's going to be have more hits than just
family and friends.

Either way, I'm planning on this site blowing up once I have enough of a
feature set, so I'm concerned about performance and scalability in the
long run.

I've worked for a software company, but I've never programmed PHP
professionally (looking for an entry level job, wink wink ).

I was wondering if sites like Sitepoint, MySpace, Facebook, etc...
actually use DB abstraction layers and template engines.

I also plan on using the code for this site for my portfolio, so I'd like
to have as much original code as possible, that's why I'm not even
considering using a framework (I've dabbled a bit with CakePHP and ZF), so
I won't bother asking about using them for large scale sites.

I've been doing a lot of research, and it seems to me that using PHP as a
templating engine itself and creating my own DB class using native DB
calls (going to use MySQL until I find it no longer suites my needs) would
be the most efficient approach.

I do plan on separating Data/Business/Presentation logic to make
maintenance easier, so that's the only reason I'm considering using a
Template engine to separate the Business/Presentation layers, and then
either PDO, ADOdb or PEAR::DB for the data layer.

But once again, I've come to the conclusion that using pure PHP to
separate the Business/Presentation layers, while using my own home brewed
DB class as the data layer would be the best way to go regarding
performance/scalability.

Are there professionals out there with experience working on large scale
sites/applications that can lend their two cents?

[Hugh Oxford]

Jesse Burns wrote:

I'm about to start working on my first large scale site (in my opinion) that
will hopefully have 1000+ users a day. ok, this isn't on the google/facebook
scale, but it's going to be have more hits than just family and friends.

Although I agree with other commentators, I would say that for really
heavyweight stuff don't start with MySQL, but PostGres.

I wish I had started with Postgres on my main project.

[Jerry Stuckle]

Hugh Oxford wrote:

Jesse Burns wrote:

>I'm about to start working on my first large scale site (in my
opinion) that will hopefully have 1000+ users a day. ok, this isn't on
the google/facebook scale, but it's going to be have more hits than
just family and friends.

Although I agree with other commentators, I would say that for really
heavyweight stuff don't start with MySQL, but PostGres.

I wish I had started with Postgres on my main project.

Although PostGres is also a good database, MySQL is quite capable with
large projects.

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attgl obal.net
=============== ===