Comments on: Scalable PHP with phpa, memcached and LVS (Part 1) http://morgamic.com/2006/03/19/scalable-php-with-phpa-memcached-and-lvs-part-1/ stuff and things, according to Mike Morgan Fri, 05 Mar 2010 22:04:02 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Performance overwegingen voor AMO | Scriptorama http://morgamic.com/2006/03/19/scalable-php-with-phpa-memcached-and-lvs-part-1/comment-page-1/#comment-1123 Performance overwegingen voor AMO | Scriptorama Sun, 16 Apr 2006 08:02:40 +0000 http://morgamic.com/?p=94#comment-1123 [...] Scalable PHP with APC, memcached and LVS (Part 1) Scalable PHP with APC, memcached and LVS (Part 2) [...] [...] Scalable PHP with APC, memcached and LVS (Part 1) Scalable PHP with APC, memcached and LVS (Part 2) [...]

]]> By: Mike Morgan - morgamic.com » Blog Archive » Scalable PHP with phpa APC, memcached and LVS (Part 2) http://morgamic.com/2006/03/19/scalable-php-with-phpa-memcached-and-lvs-part-1/comment-page-1/#comment-1087 Mike Morgan - morgamic.com » Blog Archive » Scalable PHP with phpa APC, memcached and LVS (Part 2) Fri, 14 Apr 2006 21:28:32 +0000 http://morgamic.com/?p=94#comment-1087 [...] In part 1 of this post I talked about some of the challenges we encountered when trying to scale a LAMP application. It’s pretty much what you’d read on danga’s memcached site, just dumbed down. [...] [...] In part 1 of this post I talked about some of the challenges we encountered when trying to scale a LAMP application. It’s pretty much what you’d read on danga’s memcached site, just dumbed down. [...]

]]> By: morgamic http://morgamic.com/2006/03/19/scalable-php-with-phpa-memcached-and-lvs-part-1/comment-page-1/#comment-805 morgamic Tue, 21 Mar 2006 18:05:38 +0000 http://morgamic.com/?p=94#comment-805 It was, but there are more factors than when a language gets compiled: <ul> <li>barrier-to-entry</li> <li>ability to find volunteers or hire contractors</li> <li>flexibility</li> <li>scalability</li> </ul> We found that although PHP out-of-the-box on one server isn't the best-case scenario if you are hosting millions of hits a day, it can be alleviated with good infrastructure, optimization and caching. If you touch on scalability, then from it's large following PHP pretty much kicks ass in the other areas: <ul> <li>Easy to learn, so a lot of people understand it and are willing to pick it up</li> <li>Lots of people out there already know PHP and do it for work / play, so there's a decent pool of workers out there who don't have to get paid six</li> <li>figures, or who can easily volunteer 5-10 hour a week and be immedeately effective</li> <li>Between PEAR and PECL most of what you'd need has been done (I admit, not as great as CPAN, but close)</li> </ul> So not using PHP would be an option, but a year ago when we decided to stick with it, those were some of the reasons why we stuck with it. I could see using Python or Ruby, but in terms of flexibility, ease-of-use, hiring and maintainability it's hard to beat the well-roundedness of PHP at this point. That's not saying it won't change. If the best tool for the job down the road is Ruby or Python, so be it. We'll take a look at it when we get there. It was, but there are more factors than when a language gets compiled:

  • barrier-to-entry
  • ability to find volunteers or hire contractors
  • flexibility
  • scalability

We found that although PHP out-of-the-box on one server isn’t the best-case scenario if you are hosting millions of hits a day, it can be alleviated with good infrastructure, optimization and caching.

If you touch on scalability, then from it’s large following PHP pretty much kicks ass in the other areas:

  • Easy to learn, so a lot of people understand it and are willing to pick it up
  • Lots of people out there already know PHP and do it for work / play, so there’s a decent pool of workers out there who don’t have to get paid six
  • figures, or who can easily volunteer 5-10 hour a week and be immedeately effective
  • Between PEAR and PECL most of what you’d need has been done (I admit, not as great as CPAN, but close)

So not using PHP would be an option, but a year ago when we decided to stick with it, those were some of the reasons why we stuck with it.

I could see using Python or Ruby, but in terms of flexibility, ease-of-use, hiring and maintainability it’s hard to beat the well-roundedness of PHP at this point.

That’s not saying it won’t change. If the best tool for the job down the road is Ruby or Python, so be it. We’ll take a look at it when we get there.

]]> By: James http://morgamic.com/2006/03/19/scalable-php-with-phpa-memcached-and-lvs-part-1/comment-page-1/#comment-803 James Tue, 21 Mar 2006 11:52:30 +0000 http://morgamic.com/?p=94#comment-803 I guess not using PHP isn't an option? I guess not using PHP isn’t an option?

]]> By: Roger http://morgamic.com/2006/03/19/scalable-php-with-phpa-memcached-and-lvs-part-1/comment-page-1/#comment-802 Roger Tue, 21 Mar 2006 06:37:05 +0000 http://morgamic.com/?p=94#comment-802 I used eaccelerator for a small Drupal site and it made a significant improvement for page loading speed. Of course, I have no idea how well it scales. I think the real key is making your site really bad so nobody visits. Worked for me! I used eaccelerator for a small Drupal site and it made a significant improvement for page loading speed. Of course, I have no idea how well it scales. I think the real key is making your site really bad so nobody visits. Worked for me!

]]>