A rough diagram of the architecture of the latest large scale project I was involved in.
It's only a basic outline, adapted from the actual architecture documents and presented in a way that resembles a typical n-tier approach combined with a typical MVC approach. As you can see the logic and data tiers are connected via a service layer, and more specifically a REST API, that was inspired by Recess, a lesser known PHP framework.
Don't reinvent the wheel
I work with three frameworks:
Zend Framework
The behemoth of PHP frameworks, with an impressively well written codebase and extensive list of features. On large scale applications you'll find yourself tweaking the framework more often than not, and I find ZF's codebase the most pleasant to work with. But beware, it's not an entry level framework.
Kohana
Kohana started out as a fork of CodeIgniter, and that was reason enough for me not to use it, initially. Nowadays it has grown into a solid and elegant framework that differentiates itself from every other by following an Hierarchical MVC approach. HMVC allows for a greater extend of modularization than MVC. For the project in the diagram I adapted Kohana's HMVC to ZF, but I've started using Kohana for smaller projects and considering it for larger as well.
CodeIgniter
I only use it because of a legacy project I inherited, avoid if possible.
As the other answers pointed out, an ORM always comes handy. I use Doctrine extensively, and you should take a look at its brand new mappers for CouchDB and MongoDB. Scalability is a must on large scale applications and you should evaluate NoSQL solutions.
All that said, the important thing to remember is that larger applications usually have unique challenges. You should evaluate every popular third party solution there is, and you will probably gain a lot from a couple of obscure ones. When I first evaluated Recess it was far from production ready but its approach essentially made it into the project.
Performance
On typical websites you may get away with simple output caching and opcode caching but on large scale applications you should really consider memory caching, that most commonly is build around memcached.
xdebug is mostly known as a debugger, but can serve as a profiler as well. I've recently started using Zend Server and I absolutely adore its code tracing features. Unfortunately those are not available in the Community Edition, but xdebug is a
pretty decent alternative.
If you are using Apache, make sure to optimize the hell out of it. nginx and lighttpd are apparently better choices, performance wise, but I haven't used them a lot and I can't really say.
As for the database, Doctrine's query & result caching works wonders, especially combined with memcached. And of course, we can't forget about the front end. Yahoo's Exceptional Performance team has assembled an extensive list of best practices. I'm not really a front end developer, but I've seen amazing results on solo projects.
Lastly PHP has a brand new garbage collection mechanism, worth looking into.
Security
The world of PHP security is chaotic, to say the least. I'm no expert, so treat the following as generic tips:
Open Web Application Security Project
Lot's of good stuff in there, but for a quick overview you should start with the top ten list. And research PHP solutions for those common vulnerabilities.
Stack vulnerabilities
A good habit is to periodically monitor PHP's open bugs. Even if you are no expert yourself, there are almost always workaround tips on security threats. And of course, you should extend the habit to every other part of the stack, especially the most vulnerable ones, like the web server and the database.
The crowd over at IT Security Stack Exchange can help you with more educated answers.
Further reading
