4 ms·

c.f. https://news.ycombinator.com/item?id=9121008 https://news.ycombinator.com/item?id=9121008

• pjbrunet 12y ago
  Post links and downvote all you want. Drop in the microtimers yourself and see where your PHP apps are really spending time.
  • jdub 12y ago
    I run the numbers and monitor New Relic charts on large WordPress sites all the time. Yes, some request time is spent doing I/O, but the majority of request time in any healthy PHP (or Ruby, Python, etc.) site is spent in PHP. (When more time is spent elsewhere, you have a problem that needs to be fixed. For example, waiting for I/O because you've done something silly with a database query or you've pushed it beyond its scaling limits and everyone's waiting for I/O.)
    • pjbrunet 12y ago
      I wouldn't trust New Relic charts. Maybe that is the source of all this disinformation. Get in the actual code and time everything yourself. If PHP is actually slow, you should be able to isolate the problem, like a loop within a loop that's just bad coding. You can make any language go slow with bad code. Check out my blog post on this subject: http://pjbrunet.com/microtimers-on-hooks-to-measure-wordpress-performance/ http://pjbrunet.com/microtimers-on-hooks-to-measure-wordpres...
      • jdub 12y ago
        "I wouldn't trust New Relic charts." Good for you. Putting microtimers throughout your code is like using printf for "debugging": It's banging rocks together. Use xdebug, xhprof, New Relic, something sensible. You'll learn much more about your stack.
  • juliangregorian 12y ago
    I suspect if you are using scattered microtime() calls you're not getting the full picture. You should at least try profiling it with Xdebug/xhprof.