8 ms·
Scaling PHP Book: I will teach you to scale PHP to millions of users
- stevencorona 14y agoI have a pretty comprehensive list of chapters, but I'm still adding content to the book, so if you guys have any ideas or suggestions for topics you'd like to see covered, feel free to email me or post them here. Thanks so much!
- xd 14y agoAre you looking for any proofreaders?
- Udo 14y agoI'd be interested in your opinion about premature optimizations and how your experiences with bottlenecks matched up compared to your initial expectations. I often find myself overthinking performance and scalability issues that turn out to be not relevant in the end...
- JOfferijns 14y agoI'm very interested what differences microptimizations (like using while(list() = each()) instead of foreach) make when scaling. Also, I noticed that when I clicked the return to website after clicking on the subscribe button your website, it went to google.com instead, and when I clicked continue to our website button after clicking the email confirmation link, it went to http://www.phpscalingbook.com/ http://www.phpscalingbook.com/ (404 error). And if you need any proofreaders, I'd be more than happy to help!
- snorkel 14y agoOn a typical LAMP web site the hottest bottlenecks are usually PHP is waiting for database I/O, it's not typical that slight code optimizations will produce a dramatic improvement.
- Udo 14y agoSounds interesting, especially since your stack matches mine pretty well, so count me in. However, it should be pointed out there is nothing there at your site to see yet (apart from the discount and announcement thing).
- rexreed 14y agoWhat is the expected price point of the book? Since you're in the middle of writing, do you have any opportunities for "beta" testers who can provide feedback in exchange for complementary copies?
- stevencorona 14y agoProbably $39.99, similar to bootstrappingdesign. Shoot me an email using the contact form on my website and we can coordinate some kind of beta testing once I push it to leanpub.
- rexreed 14y agoWill do - I see the subscribe link, but no contact info, just twitter. I've signed up for the list.
- esbwhat 14y agoVery exciting! I hope this will be released on amazon or have affordable shipping to Germany.
- Mikushi 14y agoGood 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.
- orthecreedence 14y agoJust because one person releases a book doesn't mean you don't have something valuable to share as well. I say go for it. There's bound to be a lot of stuff in your book this one misses, and probably vice versa. People who are facing large-scale situations generally want all the information they can get their hands on.
- rexreed 14y agoPublish your book and let the market decide. Certainly don't let a pre-announcement of a book that's not fully written yet (yet alone reviewed) discourage you!
- nodata 14y agoDefinitely publish. What if your book covered all the stuff he doesn't.
- kayoone 14y agoDont get discouraged by this. For example, Dropbox didnt get discouraged by the rumors of GDrive in 2007 and look where they are :) Of course totally different ball game, just saying: Try all you can before giving up especially since you are almost there! Good Luck!
- esbwhat 14y agoSounds interesting. Do you have any method of "keeping in touch", so I can check it out when it's ready?
- jhowell 14y agoThe majority of readers of these books will not have products that require scaling to millions and will probably purchase both books. Sounds like market validation to me.
- HyprMusic 14y agoSounds very interesting, will be keeping a close eye on this. On a side note: What is the icon for "Happy Users" supposed to be? It looks like Facebook's like icon but without a thumb.
- Fizzadar 14y agoSounds awesome; using my favorite php stack too :) Would be nice to see a preview of different bits of the book when written as well.
- stevencorona 14y agoI'll be pushing it to leanpub soon, so there will be an opportunity to check it out and get beta editions.
- darkmethod 14y agoThanks! This is perfectly timed. I'm looking forward to it. I signed up immediately. However, it looks like your mailchimp account is setup to link to phpscalingbook.com (which is the wrong domain). I clicked on the "continue to website" link after confirming.
- stevencorona 14y agoThanks for letting me know, I fixed it!
- darkmethod 14y agoMuch appreciated. Good luck to you! Looking forward to the book.
- nascro 14y agoIn what formats will this book be available? When I see a new self-published book, I assume it will be available digitally. Your site (which is really well-designed) mentions nothing of the format. Either way, I would like to see images of what the product will look like. For someone like me who doesn't need this book but is still interested in its topic, images of a well-designed book might make the difference in whether or not I purchase it.
- stevencorona 14y agoThanks for the feedback- all really good points. As the month goes on, I'll have some pictures of the cover-art and chapter list available. It will be self-published, DRM-free in PDF, mobi, epub. Looking into what it takes to publish on the Amazon Store/Kindle/iBooks, but hopefully that's something I can figure out after launching.
- fiatmoney 14y agoMy understanding is that no one finds it hard in a purely technical sense to scale the pure page-serving portion of your website, whether it's PHP, Rails, Lift, etc., because you can always throw up another caching layer or another box to serve pages. The hard part is scaling access to your underling data, which heavily depends on your exact use case.
- giberti 14y agoNice to see someone who actually created a large volume site discuss their learnings vs. theoretical works discussing how stuff (c|s)hould be done without real experience. Would love to see a chapter list!
- tnorthcutt 14y ago+1 for a chapter list (even a rough one)
- stevencorona 14y agoI'll have one posted in the next day or two.
- rmATinnovafy 14y agoGood timing on the pre-release promotion. Now keep us updated in a weekly basic and you will sell a lot of copies here. I'm glad you are writing the book. It seems like a worthy addition to my bookshelf. Will you be blogging about specifics mentioned in the book?
- snorkel 14y agoHere'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 that is not needed in realtime can be written to a plain old file and processed later. 5. Use a CDN, especially for delivering static assets 6. Server tuning: Apache, MySQL, and Linux have lots of settings that affect performance, especially the timeout settings ought to be turned down. 7. Identify bottlenecks: At the system level use tools such strace, top, iostat, vmstat, and query logging to see which layer is using the most time and resources. Also there's an excellent PHP code profiling service called New Relic that drops you right into the function and db query that's eating up most of the time in slow requests. 8. Load testing: DoS yourself. Stress test your stack to find bottlenecks and tune them out 9. Remove unused modules: For each component in the stack unload any default modules that are not needed to deliver your service. 10. Don't use ORMs and other dummy abstractions: Take off the training wheels and write your own queries. 11. Make the entry pages fast, simple, and cacheable. Nobody is reading that silly news feed in bottom corner of your front page and it's killing your database, so take it out. Most of the time a PHP slows down because each PHP process is blocked waiting for I/O from some other layer, either a slow disk, or overloaded database, or hung memcached process, or slow REST API call to a 3rd party service ... often just strace'ing a live PHP process will show you what its waiting for ... in short, blocking I/O slows down everything. The key to going faster is: * keep it simple * cache as much as possible in local memory * do as few blocking I/O operations as possible per request
- JOfferijns 14y agoCould you post this on StackOverflow or would you allow me to? It's very useful, way more people could benefit from this!
- snorkel 14y agoCopy away. I don't care. Information wants to be beer.
- rlander 14y agoThis 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 out of my comfort zone and this client will probably add hundreds of thousands to my bottom line. And I'm glad I was at that meeting while my competitors were fetishizing about non-existent scaling issues. It's 2012 for god's sake, you can rent a 32GB server for less than $100.
- debaserab2 14y agoPerformance 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 the end development.
- rlander 14y agoScaling 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?
- invisible 14y agoAs 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.
- whatorm 14y ago"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!!!
- stevencorona 14y agoI 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.
- maratd 14y agoEvery 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.
- jumby 14y agoI 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.
- xsc 14y agoHow long has this been in the works? Domain was registered yesterday... Great way to measure interest :)
- TheRevoltingX 14y agoYou don't scale a language, you scale an architecture.
- voidfiles 14y agoIs it just me, or is the site 404ing. Good joke whomever put this all together.
- cheeze 14y agoMy thoughts exactly. "I can teach you to scale to millions." Site dies with large amounts of traffic...
- jameswyse 14y agoSeems 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
- stevencorona 14y agoSorry 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.
- phaemon 14y ago404 errors are not due to lack of scaling. I can't think of a case where you'd get that. Scaling problems will usually return 5xx errors, most commonly 502, 503 and 504.
- jameswyse 14y agoIt was a joke :p