4 ms·

A 100MB per request is going to seriously limit scalability (or inflate hardware costs at least)

• Kiro 13y ago
  It doesn't say it's 100MB per request, just that it's raised for safety in the rare case where it's actually needed. Would you prefer serving a 500 to that user instead?
  • nwh 13y ago
    I can't think of a single reason a PHP script like this would need that much memory to serve a single user. Everything big would be handled by the database, what could 500MB possibly be used for?
    • robryan 13y ago
      They would be applying some search logic in memory in PHP. Depending on what you are doing it does make sense to load in a heap of data from the database then narrow it down in PHP.
      • nwh 13y ago
        That sounds grossly ineffective. Reminds me of some production PHP I saw once, returned the entire database (`SELECT * from 'db'`) and manually walked through it with a for() loop. It wasn't very efficient at scale.
        • encoderer 13y ago
          Yeah, you're right... It's way better to do expensive joins on the database where horizontal scalability is just a fantasy than in the shared-nothing www frontends that can be duplicated in clusters ad infinitum. If you're building SomeSimpleBasicSite.com and you do this, you're probably a bad programmer. If you're truly facing scalability problems, it's table stakes. Based on your comments in this thread you're out of your depth, man.
          • nwh 13y ago
            I still can't imagine not find an example of where anybody would want to return 500MB of results to PHP for processing.
            • AaronIG 13y ago
              I think Kiro meant 500, as in the HTTP status code, due to PHP running out of memory, not 500MB.
        • deleted 13y ago
          [deleted]
  • nilved 13y ago
    Yes
  • mratzloff 13y ago
    Guess what happens when a lot of people search.
• blowski 13y ago
  It would seem that Facebook has been able to scale. Perhaps this line of code worked for them in 2007, and they changed it only when it started to be a problem.
  • Kiro 13y ago
    It's probably still there and has probably never caused any problems. In other words I think iand is exaggerating.
    • asdasf 13y ago
      It is certainly not still there given that facebook doesn't run PHP any more. They wrote a compiler to translate a subset of PHP to C++, which they then compiled into a massive executable. The compiler is open source and called hiphop, and it does not implement the PHP memory limits.
      • MichaelGG 13y ago
        By that logic, no one runs any programming languages, since they all get translated to x64 or other instruction sets.
        • asdasf 13y ago
          That makes no sense at all. The function in question sets the memory limit for the PHP interpreter. A specific piece of software. Facebook does not use that specific piece of software.
          • MichaelGG 13y ago
            Your comment was ambiguous then. It sounded like your logic was "they don't run PHP because they wrote their own implementation"... which is still running PHP. I think you meant to say they're not running the normal PHP interpreter, so that particular functional call might not be implemented (but it could be, still...).