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

81–90 of 105 posts

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

#81

Post by dools »

duggan wrote: post #67
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.

Personally, one of my favourite discussions is Laurie Voss' "ORM is an anti-pattern": http://seldo.com/weblog/2011/08/11/orm_is_an_antipattern

Which, really, should be "ActiveRecord is an anti-pattern"

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

#82

Post by dools »

FuzzyDunlop wrote: post #77
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.

It could be as simple as the performance loss incurred by an ORM is greater than the benefit of using it. You have PDO with PHP, which can be used quite adequately as an ORM itself (you can fetch a tailored SQL query into a class as opposed to working with basic arrays). I'd argue that, in some cases, an ORM is only used as a reaction to the separation of concerns. Writing SQL mixes up your languages, so why not try…

PDO doesn't handle mapping of nested relationships, though which is where it falls down when compared to ActiveRecord implementations. For example I want to fetch an author and all of the author's books in a single query then loop over and print out author name, and each book. A standard ActiveRecord ORM will give you an array of authors where each author contains an array of books, where as with PDO you're still left to manually detect a change in author by a change in the primary key which is more complex than just writing a nested for loop.

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

#85

Post by jameswyse »

Seems your site doesn't scale very well..

404 Not Found

Code: NoSuchBucket Message: The specified bucket does not exist BucketName: www.scalingphpbook.com RequestId: 403C0590E064E19F HostId: a+UggS1lMBgPJrT5X/kbdzsRK1kx+iKBQw6u4dZxieNkspwHbLZBWzXMa9CiHEAu

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

#86

Post by boyter »

josephmoniz wrote: post #76
riledhel wrote: post #72

Earlier quoted context omitted.

What was your experience with APC? You still use some opcode cache, right?

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?

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

#87

Post by notJim »

DanielN wrote: post #61
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 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 comments I read was something along of the lines of "Every project I've ever worked on that 'didn't use an ORM' implemented the same functionality of one in a less-maintainable way."

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

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

#88

Post by notJim »

duggan wrote: post #67
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.

Personally, one of my favourite discussions is Laurie Voss' "ORM is an anti-pattern": http://seldo.com/weblog/2011/08/11/orm_is_an_antipattern

The key criticism in that article seems to be "ORMs are imperfect abstractions for SQL." Who the hell cares? This is the real world. We don't need perfect abstractions.

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

#89

Post by invisible »

rlander wrote: post #47
debaserab2 wrote: post #45

Earlier quoted context omitted.

Performance isn't a problem until it is, and then when it is a problem, it's bigger than any other problem in the world because you have nothing to sell if it does not operate. I always thought I was being wise by not doing any premature optimization, but after a few lessons learned the hard way I certainly factor in performance to the design of software before I build now. Scalability is not a "feature" tacked on at…

Scaling will only become a problem when/if you achieve product/market fit. What percentage of startups on HN have achieved product/market fit, are past a 128GB commodity box AND have no dedicated engineering team for scaling issues?

As an engineer, not knowing how to scale when working on something that may need to scale could spell the downfall of whatever product you're working on. Yes, all is well and fine until you hit a natural growth cycle and can't commission new boxes fast enough because each request is taking 300ms. Your database isn't accepting enough requests (plus, some of your bad queries that aren't indexing are blocking too long). Then your web servers run out of memory because you are using an ORM for large lists of items that you're just returning as an array...

Once you get to the point of no return you have to know what to do or you'll suffer. Learning that when fire is falling from the skies is the worst way in retrospect.

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

#90

Post by stevencorona »

jameswyse wrote: post #85

Seems your site doesn't scale very well.. 404 Not Found Code: NoSuchBucket Message: The specified bucket does not exist BucketName: www.scalingphpbook.com RequestId: 403C0590E064E19F HostId: a+UggS1lMBgPJrT5X/kbdzsRK1kx+iKBQw6u4dZxieNkspwHbLZBWzXMa9CiHEAu

Sorry man. The site is completely static and hosted on Amazon S3/CloudFront. I made a typo fix earlier and Transmit totally nixed the permissions, but CloudFront didn't pick it up until now. It should be fixed.
Post reply on HN