PHP Stability Advice

[Canman2005]

Hello all

 

I wonder if someone can give me some advice, sorry if this is in the wrong place, I couldn't seem to find the right forum to put it in.

 

I am helping a friend to build a PC support ticket system for use by around 100 support groups, 50 schools and 20 universities, over time a total potential student population of between 300,000 and 800,000 might use it.

 

Of course they as not all going to be accessing the system at once, but of something major happens, there could be almost half the students submitting a ticket at once, but I want to build it in a way that it could cope with 1,000,000 users, I know server space maybe expensive and luckily I wont have to pickup the bill for that.

 

So my questions are;

 

[*]Can PHP handle this volume of traffic with multiple SELECTS, INSERTS etc

 

[*]Can PHP ever crash due to overload or is it always the server which has the overload and crashes, if it's PHP, what can be done to stop that?

 

[*]What would be the best way to hold user data? Is is best to spread the data over multiple tables

 

[*]Is there anything I should consider in PHP when working out a viable system

 

[*]Any advice on the type and level of server we should use

 

 

I assume PHP would be the best to use as companies like Facebook seem to use PHP and they handle 500 millions users, so I guess it's stable enough.

 

I guess Cloud hosting would be best to balance the load??

 

I was going to code this all myself over time and learn advanced PHP a bit more, is this a good idea or should I be learning using a framework like ZEND or something like Drupal?

 

Thanks all

[jamesxg1]

You will need a dedi/vps server.

 

    * Can PHP handle this volume of traffic with multiple SELECTS, INSERTS etc - YES.

    * Can PHP ever crash due to overload or is it always the server which has the overload and crashes, if it's PHP, what can be done to stop that? - GENERALLY THE SERVER.

    * What would be the best way to hold user data? Is is best to spread the data over multiple tables - MYSQL.

    * Is there anything I should consider in PHP when working out a viable system - THERE ARE A LOT OF DEPRECIATED OR SLOW FUNCTIONS, AND ALSO CODE IN PHP5 AS IT IS GOOD WITH OOP.

    * Any advice on the type and level of server we should use - DEDI/VPS.

 

James.

[Canman2005]

thanks James, anyone else?

[gizmola]

PHP is a 2 tier architecture.  You have the web clients and they talk to the webserver which has PHP built in.  So once you need to scale there are a lot of different strategies involved.  Here's some things to consider:

 

-Front end performance and overhead of apache

 

When your application is running, it needs memory, and this becomes a limiting factor on the webserver.  If apache can not fork new child process memory out of available ram, the machine starts swapping, and things get slow fast.

 

-Database performance:

There are plenty of bottlenecks that can occur here including, IO performance of the db machine, locking bottlenecks, and other issues that I can't explain in a soundbite.  The database engine, and the specific design of the system directly impact these issues.  There is no magic bullet list of items I can give you, however, it tends to be that most large PHP/MySQL based sites tend to use a Reader/Writer architecture.  This often works because web apps are often skewed to have a high ratio of read to to write activity. 

 

Using mysql replication you can spread the load out, and have an array of "reader" mysql db's that can be used for selects.  When there is insert/update activity, then the readers are used.

 

Caching is also a pretty essential scaling activity.  Many large sites like Facebook make use of memcached to cache database reads in memory.  Memcached is a distributed cache, so they have invested in arrays of machines that are basically cpu+memory+network servers, and do nothing other than serve as memcached machines.  The individual apache/php servers are configured to know about the memcached cluster, and get data from it as much as possible to minimize db load.

 

In regards to db design there are some obvious concerns: 

 

- Keys.  You need a scheme for assigning keys so that you can move individual rows around without causing key collisions.  If I have db1.user and db2.user and I use auto_increment, I willl then have 2 users with user_id = 1.  This is a problem for scaling, so people have to come up with something different. There are a lot of different approaches, but one I've seen frequently is the use of a GUID as the primary key for rows.

 

PHP sessions are by default local files on the server.  Once you have a cluster, the session data can no longer live on a single server if there's any possibility that someone might be routed to a different apache/php server for load balancing purposes.  So you need to have an alternative serialization mechanism.  People frequently use either the database, or memcached for session storage.

 

Unless you have a really clear cut idea of how to develop this from scratch I would certainly recommend using a framework that provides you an MVC implementation.  Many people also welcome the use of an ORM component that provides database abstraction.

 

Setting up an infrastructure and maintaining it, requires some really good sysadmin skills.  Hopefully you will be able to find someone to aid you there.

 

Zend Framework or Symfony are both frameworks you should take a serious look at for a project like this. 

 

That's all I can think of off the top of my head.  Good luck with the project.

[btherl]

PHP can become unstable if you deal with large amounts of data, and with complex structures, especially those involving references.  There's a hard limit on the number of references a single variable can have, and if you exceed it php will just die.  The limit is around 65k, so you won't meet it unless you're doing something unusual.  I've encountered instability when dealing with arrays with around 100k entries, where memory usage is getting into the gigabytes.

 

As long as you stick to small operations though, it's rock solid.  We use it in production systems and never have problems, except in those unusual circumstances listed above.

 

gizmola seems to have covered the other things I would have mentioned.