Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Scaling PHP Book: I will teach you to scale PHP to millions of users

scalingphpbook.com

Post reply on HN
Print view View original

51–60 of 105 posts

Re: Scaling PHP Book: I will teach you to scale PHP to millions of users

#51

Post by snorkel »

qeorge wrote: post #46
snorkel wrote: post #38

Here's a short list: 1. Cache the output at the edges: Use Varnish or other reverse proxy cache. 2. Cache byte code: Use APC or XCache PHP opcode cache. 3. Cache and minimize database I/O: reduce database touches using memcached, redis, file caches, and application-level caches (ie. global vars) 4. Do event logging in local files, not to the database: Make all write operations as simple and fast as possible, any data…

I'm expecting the book to go much further than this. Your list is a fine starting point, but its fairly basic and lacks specifics. I want to know about the weird things that happen when you push your PHP stack to really ridiculous limits. I think that's what this book will offer. If it ends up being stuff like "use APC! minimize trips to the DB!" I would be very surprised and disappointed.

If it's pushing PHP to ridiculous limits you seek then you want Facebook's HipHop compiler. But web stack design is really an art form, hard to summarize in an HN comment.

Re: Scaling PHP Book: I will teach you to scale PHP to millions of users

#52

Post by whatorm »

"Don't use ORMs"? I'm sorry, that's just plain wrong, or you were exposed to the wrong ORMs. Doctrine2 has great scalability - it has all sorts of caching built into it - result caching, query caching, and so on and so forth. It's actually -way- more scalable, and easier to develop for, than writing raw SQL (which, by the way, is a portability nightmare). Also, if you want to use a decent MVC framework, not using an ORM would be quite dumb. And if you're not using a good, modern, scalable MVC framework in this day and age, well, I pray for your soul.

So, USE AN ORM!!!

Re: Scaling PHP Book: I will teach you to scale PHP to millions of users

#53

Post by maratd »

dangrossman wrote: post #50
rlander wrote: post #44

This fetishism with scaling... to me it's just procrastination. It feels like work because you're doing something technical but, in the end, you're adding very little to your product. Yesterday I had a meeting with a potential customer and I hated it. I hate to try to explain my SaaS software to non-technical people who treat me like some 17-year-old webmaster. I'd much rather be refactoring Clojure code. But I got o…

> It's 2012 for god's sake, you can rent a 32GB server for less than $100. Where, in the US, can I rent a 32GB server for less than $100?

I don't think he meant RAM. Otherwise, I want to know too!

Re: Scaling PHP Book: I will teach you to scale PHP to millions of users

#54

Post by alexitosrv »

Mikushi wrote: post #8

Good to know other people want to share about successful scaling with PHP. On the downside, I have a book cooking on the same exact subject, with release planned September (self-publish, about 80% done), but now not sure if it's worth continuing. [edit]Slight moment of "panic", as seeing someone else releasing a book on the same subject made me sad, but you're right, no reason not to continue.

Just continue your work and let us know when it's ready!

Re: Scaling PHP Book: I will teach you to scale PHP to millions of users

#55

Post by stevencorona »

qeorge wrote: post #46
snorkel wrote: post #38

Here's a short list: 1. Cache the output at the edges: Use Varnish or other reverse proxy cache. 2. Cache byte code: Use APC or XCache PHP opcode cache. 3. Cache and minimize database I/O: reduce database touches using memcached, redis, file caches, and application-level caches (ie. global vars) 4. Do event logging in local files, not to the database: Make all write operations as simple and fast as possible, any data…

I'm expecting the book to go much further than this. Your list is a fine starting point, but its fairly basic and lacks specifics. I want to know about the weird things that happen when you push your PHP stack to really ridiculous limits. I think that's what this book will offer. If it ends up being stuff like "use APC! minimize trips to the DB!" I would be very surprised and disappointed.

I agree- good starting point, but the book will be much more in depth. It's going to include a fair amount of high-level design, identifying how and where to scale, weird issues you run into (fun fact: we don't use APC @ Twitpic), solutions to PHP anti-scaling quirks (you can't set sub-1s mySQL timeouts, for instance, although I think this is due to libmysql, not PHP), lots of case studies, scaling design patterns, and way more cool stuff.

Re: Scaling PHP Book: I will teach you to scale PHP to millions of users

#56

Post by stevencorona »

whatorm wrote: post #52

"Don't use ORMs"? I'm sorry, that's just plain wrong, or you were exposed to the wrong ORMs. Doctrine2 has great scalability - it has all sorts of caching built into it - result caching, query caching, and so on and so forth. It's actually -way- more scalable, and easier to develop for, than writing raw SQL (which, by the way, is a portability nightmare). Also, if you want to use a decent MVC framework, not using an…

I agree. We use our own lightweight ORM at Twitpic (similar to PHP ActiveRecord). It produces SQL for you unless you feed it your own optimized query, but "does the right thing" 99.9% of the time.

IMO, "ORM produces bad SQL" is a myth and more often a case of bad indexes and not bad SQL.

Re: Scaling PHP Book: I will teach you to scale PHP to millions of users

#57

Post by maratd »

whatorm wrote: post #52

"Don't use ORMs"? I'm sorry, that's just plain wrong, or you were exposed to the wrong ORMs. Doctrine2 has great scalability - it has all sorts of caching built into it - result caching, query caching, and so on and so forth. It's actually -way- more scalable, and easier to develop for, than writing raw SQL (which, by the way, is a portability nightmare). Also, if you want to use a decent MVC framework, not using an…

Every layer of abstraction you add, not only adds a layer of complexity and extra points of failure, but also adds restrictions.

By definition, an abstraction is more restrictive ... otherwise, you're not really abstracting anything.

If you're making a simple web app, an ORM is just fine. If you're building enterprise-level software, it is a really really bad idea. Half your code will be using it, the other half will be forced to use half-assed SQL queries that try to fit into your ORM. Because, quite simply, you will need all that SQL has to offer to make things work right. You can't afford to abstract SQL away. Trust me, I tried. In the end, the best you can do is go with something like LINQ.

I built a LINQ like system for PHP a while before Microsoft did it for .NET =)

On a side note, I would also stay away from all the frameworks and build one yourself. If you're on a long-term project, it's worth it. You'll understand what is happening and what each call really costs you. You can also refactor an existing framework. Either way works.

Re: Scaling PHP Book: I will teach you to scale PHP to millions of users

#58

Post by jumby »

whatorm wrote: post #52

"Don't use ORMs"? I'm sorry, that's just plain wrong, or you were exposed to the wrong ORMs. Doctrine2 has great scalability - it has all sorts of caching built into it - result caching, query caching, and so on and so forth. It's actually -way- more scalable, and easier to develop for, than writing raw SQL (which, by the way, is a portability nightmare). Also, if you want to use a decent MVC framework, not using an…

I can't stand the 'portability nightmare' comment/sentiment from ORM (ab)users. How often do you swap out your DBMS from MySQL to Oracle to Postgres? Writing SQL should not be anathema.
Post reply on HN