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

91–100 of 105 posts

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

#91

Post by Firehed »

notJim wrote: post #87
DanielN wrote: post #61

Earlier quoted context omitted.

I'm curious why you suggest avoiding ORMs. I've been debating this for a while and while I like the accessibility and abstraction that ORMs provide in Django and Rails I'm not familiar enough with Doctrine, DB_DataObject or the other PHP options to really have formed my own opinions yet. Is this a language specific suggestion or something broader? I would love to hear a deeper debate on the subject.

I think the advice to not use an ORM* is very misguided. Use the ORM for the 80-90% of queries that are "SELECT * FROM table WHERE id=5" and "UPDATE table SET name='jim' WHERE id=5". For the rest of the queries, use your ORM's ability to run custom queries. People who have problems with ORMs are probably not using them correctly. There was a debate on HN about ORM's a while ago, and one of the most significant commen…

I totally agree. ORMs are not a bad thing and save you from writing the same code over and over again. The key is to understand what it's doing behind the scenes and not be afraid to go in and change it if it's generating stupid queries.

Is there some extra overhead? Of course. Probably a lot less than cleaning up the damage from some cowboy coding.

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

#92

Post by patio11 »

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.

If you need to know PHP scaling, a) the amount of money that two books cost is still absolutely meaningless to you, b) you will, very probably, still have questions after thoroughly reading your first book and c) it is worth having a second book just to have a second shot at book cover art which will convince one of your engineers to actually read the damn thing instead of re-inventing it poorly as need arises.

Absolutely finish and release your book. Half-writing a book is an even worse decision than writing a book. (Tongue only somewhat in cheek there: if you have actionable information on how to scale PHP, a book is one of the worse ways to change people's lives with that information while simultaneously making money from it.)

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

#93

Post by pwaring »

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…

"Identify bottlenecks" - I hope this is the first topic covered. There's no point in fiddling about with PHP if the actual bottleneck is the fact that you're sharing a slow connection with dozens of other companies or are hosted on the opposite side of the world to most of your customers.

Having said that, I'm looking forward to the book, as there doesn't seem to have been much on this topic since the O'Reilly books on scaling web applications (2006 I think).

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

#94

Post by Loic »

boyter wrote: post #86
josephmoniz wrote: post #76

Earlier quoted context omitted.

If you use a persistent PHP stack like mongrel2 + photon an opcode cache is just a waste of a php module. http://www.photon-project.com/

Wouldn't you lose one of the advantages of PHP which is that every request is stateless and that when it fails it doesn't fail hard killing the application?

Not any more nowadays. I am the original author of Photon and today PHP is extremely robust and you can catch all the exceptions/errors (outside the ones which are making your code invalid, but hey, do your homework). The current PHP 5.3 is also wonderful at not leaking memory. So you get the speed of bare PHP with a framework (because nothing is reloaded, the framework can really load once, reuse many times).

On a small system, a standard HTTP request through Mongrel2, to the framework and back is about 2ms (including 1ms of network latency between the hosts, data from my production monitoring). This is the "hello world" latency. It makes using PHP very fun and very fast. Also, a single PHP process running in the background uses about 12MB, it means that with 12MBx3 + 10MB Mongrel2, you can serve 1000's of users with nearly no load on your system (if you push the load only when needed at the DB level). Tracing a PHP process, you can run it without system calls at all (only gettimeoftheday for logging).

But, this is cutting edge, so, you need to be open minded and ready to dig in the code (less than 25k SLOC anyway I think).

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

#95

Post by ralph »

danudey wrote: post #79
jakejake wrote: post #65

Earlier quoted context omitted.

scale is one of those problems that sneaks up on you (well unless you're an instant hit site I suppose) In all of my cases dealing with scale issues it's been due to the DB growing very large in size to the point where you can't use the same techniques that you're used to using. That usually happens in combination with more concurrent users. Depending on how large and how organized your code is, things can get very u…

One of the issues I've run into in the past was a MySQL problem where their system was creating tons of temporary tables, and because of the massive amount of traffic they were getting, it was killing their database server because it was choking out the disk's I/O, and the server was at 80% iowait most of the time because the disk cache was paging things in and out like crazy. I went back and forth with them about op…

tmpfs for mysqld's tmpdir is a similar option, perhaps even better if, as I'd hope, tmpfs's internals are simpler and faster because it has an easier job to do that ext3-sans-journal. Obviously needs the RAM though.

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

#96

Post by iaskwhy »

pwaring wrote: post #93
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…

"Identify bottlenecks" - I hope this is the first topic covered. There's no point in fiddling about with PHP if the actual bottleneck is the fact that you're sharing a slow connection with dozens of other companies or are hosted on the opposite side of the world to most of your customers. Having said that, I'm looking forward to the book, as there doesn't seem to have been much on this topic since the O'Reilly books…

What's the best way to identify bottlenecks?

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

#97

Post by pwaring »

iaskwhy wrote: post #96
pwaring wrote: post #93

Earlier quoted context omitted.

"Identify bottlenecks" - I hope this is the first topic covered. There's no point in fiddling about with PHP if the actual bottleneck is the fact that you're sharing a slow connection with dozens of other companies or are hosted on the opposite side of the world to most of your customers. Having said that, I'm looking forward to the book, as there doesn't seem to have been much on this topic since the O'Reilly books…

What's the best way to identify bottlenecks?

Not sure about 'best', but the way I go about it is to measure the total time required for an application to complete a task, then attempt to measure the individual components (time spent in PHP, data transfer, rending on client side etc.) and keep narrowing it down until you find the exact cause, such as a database query which requires optimisation.

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

#98

Post by ichilton »

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.

Is there anywhere to register to receive more information on your book when you get nearer?

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

#99

Post by Muzza »

notJim wrote: post #87
DanielN wrote: post #61

Earlier quoted context omitted.

I'm curious why you suggest avoiding ORMs. I've been debating this for a while and while I like the accessibility and abstraction that ORMs provide in Django and Rails I'm not familiar enough with Doctrine, DB_DataObject or the other PHP options to really have formed my own opinions yet. Is this a language specific suggestion or something broader? I would love to hear a deeper debate on the subject.

I think the advice to not use an ORM* is very misguided. Use the ORM for the 80-90% of queries that are "SELECT * FROM table WHERE id=5" and "UPDATE table SET name='jim' WHERE id=5". For the rest of the queries, use your ORM's ability to run custom queries. People who have problems with ORMs are probably not using them correctly. There was a debate on HN about ORM's a while ago, and one of the most significant commen…

> * Or other object-oriented abstraction layer for database access, ORMs aren't the only option.

What do you mean by this? That you should consider a non-relational database? Clearly any mapping from an OOP language to a relational database is an object-relational mapping.

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

#100

Post by notJim »

Muzza wrote: post #99
notJim wrote: post #87

Earlier quoted context omitted.

I think the advice to not use an ORM* is very misguided. Use the ORM for the 80-90% of queries that are "SELECT * FROM table WHERE id=5" and "UPDATE table SET name='jim' WHERE id=5". For the rest of the queries, use your ORM's ability to run custom queries. People who have problems with ORMs are probably not using them correctly. There was a debate on HN about ORM's a while ago, and one of the most significant commen…

> * Or other object-oriented abstraction layer for database access, ORMs aren't the only option. What do you mean by this? That you should consider a non-relational database? Clearly any mapping from an OOP language to a relational database is an object-relational mapping.

What I meant to say is that ActiveRecord isn't the only pattern.
Post reply on HN