5 ms·

Remember when the meme was "%90 of web apps will not reach a point where scaling is an issue"? Well, of those who do reach it, %90 will not reach a point when P

by nir 17y ago

Remember when the meme was "%90 of web apps will not reach a point where scaling is an issue"? Well, of those who do reach it, %90 will not reach a point when PHP's execution (assuming you use on of the existing code accelerator, all which are free IIRC and one will be bundled with PHP6) is the bottleneck. It's a cool hack, but really targets Facebook-level needs. For most users, the downside (eg compatibility issues) will far outweigh the benefits.

rythie 17y ago
Actually it's an efficiency gain, rather than scalability. Facebook already have a system they can add more servers at, but this is designed to let them use less and save money as a result. Also at least 90% of web apps are tiny or are startups that never made it, either way they don't need this for a long time, like you say.
- nir 17y ago
  efficiency -> scalability, in the sense that serving the request faster will free the server to serve another request. My point is that for nearly all apps, executing PHP is very small part of the total request handling time, so even a significant improvement will have little overall effect. I bet many people excited by HipHop could get a much bigger performance gain by adding some simple caching)
  - rythie 17y ago
    Not really, that type of efficiency is not predictable. From Wikipedia: "scalability is a desirable property of a system, a network, or a process, which indicates its ability to either handle growing amounts of work in a graceful manner or to be readily enlarged. For example, it can refer to the capability of a system to increase total throughput under an increased load when resources (typically hardware) are added."
    - nir 17y ago
      I realize we're nitpicking, but I don't really get it: Why isn't it predictable (in the sense that any execution time for an HTTP request ever is)? You run http_load for x seconds and see how many requests got served, then make change y and do it again. Obviously there are other variables but it's possible to get a fair idea.
      - rythie 17y ago
        Because as you described you have to try it to find out how much it will save you, by which point you could probably just roll it out already. Say you have 10 servers now and you expect business to grow by 10x in next year, so you put 6 months of dev. time into implementing caching. Then you get 10x the traffic in a month and you get V.C. investment as a result. You then have a problem, people are getting a bad experience and the development won't be done for another 5 months. Your CEO buys a rack full of servers, but you can't do anything with them because you don't have a scalable system. Alternatively you could find out after 6 months that you can't make that 10x performance jump after all. Twitter had this problem a while back, essentially their DB server got overloaded but it was already a 8 CPU, 64GB machine and despite having lots of money they couldn't quickly solve the problem, because you couldn't really get a bigger system. Facebook knows how to scale, they want to cut costs where they can to become (more) profitable.
    - deleted 17y ago
      [deleted]
  - lallysingh 17y ago
    It's more like scalability is the derivative of efficiency, for N_1 and N_2 user counts, scalability = (efficiency(N_2) - efficiency(N_1))/(N_2 - N_1)
- deleted 17y ago
  [deleted]
necro 17y ago
Though I agree that most single sites wont benefit from this. We have a single site serving 100 pages/sec and php is not even close to becoming a bottleneck. The other application where this may be helpful is the cloud. In a system like this you have 100s or 1000s of sites on a single machine that may reach the combined traffic where this optimization can come into play.
- viraptor 17y ago
  Or when you pay per cpu cycles / memory. If you can reduce that usage, then your costs are directly affected.
encoderer 17y ago
You might be surprised in some cases.... We recently did some tsung testing on an optimization system we've developed (purposely general here). Running it the developers workstation w/ APC and Memcache and local Percona MySQL, it maxed at 300 request/s. (It's just a workstation, remember). Anyway, there may be some observer effects here, but the profiler indicated that most the time was being spent on php functions and system calls. So we might be in the 1% you're describing. Or _maybe_ it's a more than 1% after all.

by nir 17y ago

rythie 17y ago

Actually it's an efficiency gain, rather than scalability. Facebook already have a system they can add more servers at, but this is designed to let them use less and save money as a result. Also at least 90% of web apps are tiny or are startups that never made it, either way they don't need this for a long time, like you say.

nir 17y ago
efficiency -> scalability, in the sense that serving the request faster will free the server to serve another request. My point is that for nearly all apps, executing PHP is very small part of the total request handling time, so even a significant improvement will have little overall effect. I bet many people excited by HipHop could get a much bigger performance gain by adding some simple caching)
- rythie 17y ago
  Not really, that type of efficiency is not predictable. From Wikipedia: "scalability is a desirable property of a system, a network, or a process, which indicates its ability to either handle growing amounts of work in a graceful manner or to be readily enlarged. For example, it can refer to the capability of a system to increase total throughput under an increased load when resources (typically hardware) are added."
  - nir 17y ago
    I realize we're nitpicking, but I don't really get it: Why isn't it predictable (in the sense that any execution time for an HTTP request ever is)? You run http_load for x seconds and see how many requests got served, then make change y and do it again. Obviously there are other variables but it's possible to get a fair idea.
    - rythie 17y ago
      Because as you described you have to try it to find out how much it will save you, by which point you could probably just roll it out already. Say you have 10 servers now and you expect business to grow by 10x in next year, so you put 6 months of dev. time into implementing caching. Then you get 10x the traffic in a month and you get V.C. investment as a result. You then have a problem, people are getting a bad experience and the development won't be done for another 5 months. Your CEO buys a rack full of servers, but you can't do anything with them because you don't have a scalable system. Alternatively you could find out after 6 months that you can't make that 10x performance jump after all. Twitter had this problem a while back, essentially their DB server got overloaded but it was already a 8 CPU, 64GB machine and despite having lots of money they couldn't quickly solve the problem, because you couldn't really get a bigger system. Facebook knows how to scale, they want to cut costs where they can to become (more) profitable.
  - deleted 17y ago
    [deleted]
- lallysingh 17y ago
  It's more like scalability is the derivative of efficiency, for N_1 and N_2 user counts, scalability = (efficiency(N_2) - efficiency(N_1))/(N_2 - N_1)
deleted 17y ago
[deleted]

necro 17y ago

Though I agree that most single sites wont benefit from this. We have a single site serving 100 pages/sec and php is not even close to becoming a bottleneck. The other application where this may be helpful is the cloud. In a system like this you have 100s or 1000s of sites on a single machine that may reach the combined traffic where this optimization can come into play.

viraptor 17y ago
Or when you pay per cpu cycles / memory. If you can reduce that usage, then your costs are directly affected.

encoderer 17y ago

You might be surprised in some cases.... We recently did some tsung testing on an optimization system we've developed (purposely general here). Running it the developers workstation w/ APC and Memcache and local Percona MySQL, it maxed at 300 request/s. (It's just a workstation, remember). Anyway, there may be some observer effects here, but the profiler indicated that most the time was being spent on php functions and system calls. So we might be in the 1% you're describing. Or _maybe_ it's a more than 1% after all.