<<
I remember it was October 2005, shortly after Open Source Site went live, with an article. Back then, I still limited my understanding of high availability, heavy loads, and high traffic to the mindset of “stacking hardware.” A subsequent document didn’t seem to break out of this scope either. Due to my work content later on, I never really continued to explore this topic. I only briefly touched on architecture trends in an article about GAE.
After more than 5 years, let’s revisit this from a new perspective and discuss how a LAMP architecture website can support the maximum possible load. A disclaimer: this article represents the personal opinion of Litrin, the site owner. Discussions are welcome, but trolls should stay away.
First and foremost, the following somewhat dry text targets sites with at least 100K PV or higher. Smaller websites don’t necessarily need to follow these practices; cost-effectiveness should always be the priority. By the time you reach that PV level, you’ll likely have the corresponding financial and material resources for a redesign.
Initial Planning
This mainly refers to preliminary work like design models. The MVC design pattern is deeply ingrained, and admittedly, it’s often the first choice for most architecture designers. In reality, on a website, the most readily available and abundant resources are CPU and memory; the biggest bottleneck always lies in IO.
The biggest problem with LAMP architecture is that the MVC overhead is too high. Layers of encapsulation mean repeated judgment; opening numerous program files will severely drag down performance. Many free, open-source PHP frameworks online, like ThinkPHP and ZF, which I’ve used, are absolutely fine for small to medium websites but unsuitable for high-load sites. Even pure template engines like Smarty, with their heavy IO operations, will bog down overall performance. Disregarding other factors, I even considered the garbage “All in 1” structure — which of course is not practical. But paradoxically, this “All in 1” is precisely the most suitable structure for high loads. A strange contradiction.
Influenced by GAE, I once considered implementing the website architecture using an API+XML approach, but later dismissed the idea. XML itself has a lot of structural redundancy, meaning a low information-carrying rate. There’s no need to use XML for communication between a few internal servers; if a similar model were needed, the CSV format would be a better choice. XML is meant for opening up to third-party users.
Database Design
Read-write separation is a well-known secret. MySQL’s Master + Slave design is truly convenient! At most, you just implement multiple tiers of read-write separation.
Splitting tables, splitting databases, distributing across machines: vertically split large tables, horizontally split wide tables, and distribute unrelated data across different machines. Vertical splitting saves time, horizontal splitting saves memory, and distributing across machines shares the load. MySQL performs very well below a few million rows of data; exceeding this magnitude, no matter how powerful the machine is, performance will degrade horribly, and MySQL‘s terrible table-locking mechanism will show its true colors. Nobody wants to wait for a response time of over 30 seconds, let alone a SELECT operation I once encountered that took over 45 minutes (a single operation, no LIKE used, indexes were utilized). I’ve used MySQL’s partitioned tables before and felt this method was more like applying a patch — adapting the database structure to suit the application is a strange workflow. Besides, even if you escape splitting this time, you’ll inevitably have to come back and split it someday.
Indexes, have all the necessary ones, but for tables with frequent write operations, indexes become a burden instead. It’s a conventional standard not to let the index count exceed 30% of