4 ms·

The downside is literally exactly the same as the upside: you have to bootstrap from literally nothing for every single request. Think about how ActiveRecord in

by mikey_p 10y ago

The downside is literally exactly the same as the upside: you have to bootstrap from literally nothing for every single request. Think about how ActiveRecord in Rails reads from the DB schema to generate it's magic methods, etc. This is usually done on startup or at least cached in memory once it's loaded. This is something that you have to manage more carefully with a PHP app since you can't have anything initialized before a request starts. Code paths, auto-loaders, database connections, config files, etc. All that has to happen over and over for each request. You can cache that stuff, but it's still overhead that isn't central to handling a request. There's actually work being done to build PHP frameworks that get around this with ReactPHP, ZeroMQ, Photon, etc. Essentially this is what HHVM does as well, by at least keeping your compiled bytecodes in memory (similar to APC/eAccelarator/ZendOptimizer, etc). See: http://reactphp.org http://reactphp.org http://www.photon-project.com http://www.photon-project.com https://gnugat.github.io/2016/04/13/super-speed-sf-react-php.html https://gnugat.github.io/2016/04/13/super-speed-sf-react-php... Even the idea of an alternative runtime for PHP (ala HHVM) is nothing new: http://quercus.caucho.com http://quercus.caucho.com

toast0 10y ago
> Code paths, auto-loaders, database connections, config files, etc. All that has to happen over and over for each request. Do you most of those need to happen at all, ever? In my mind, auto-loader is a sign that nobody knows what's being loaded (if they did, they would just require it). Requires should be full pathed (because have you seen what happens when you search the include path). Mysql_pconnect has been doing connection pooling for a long time, mysqli supports it too (so yes, you do need to connect sometimes), anyway, if you're loading a framwork, loading that probably takes longer than connecting to a mysql server in the same colo.
- dpcx 10y ago
  IMHO, developer time is more expensive than CPU time; I don't want or need to have to write out all of those requires. That's the job of the autoloader. And if I'm writing my code remotely well enough, each section only uses the things that it needs. Granted, there may be some things that each request get that they don't need with the autoloader. But I can optimize later. "Make it work, make it right, make it fast"
  - toast0 10y ago
    Users' time is more important than developer time or CPU time. Burning cpu and maybe i/o looking for code all over the place is going to make it really hard to make it fast later.
  - avisser 10y ago
    > I don't want or need to have to write out all of those requires. That's the job of the autoloader. Or the IDE. IntelliJ or ReSharper does that for me. And I like dealing with any naming conflicts right then and there, which those tools allow me to do.
  - Twirrim 10y ago
    > IMHO, developer time is more expensive than CPU time; I don't want or need to have to write out all of those requires. Every wasted millisecond on the server side matters. It impacts scalability, customer experience (and revenue) etc. You should take every easy win you can get there. Not doing full includes is just ridiculously lazy. It doesn't take that long to write them out, and your IDE can help you out there. I bet you spend more time on social media during office hours than you'd ever save from not having to type out those import statements.
    - bpicolo 10y ago
      Except you still need autoloading configured for most libraries in the ecosystem to work, unless you want to manually chain absolutely huge quantities of requires.
  - cagataygurturk 10y ago
    > IMHO, developer time is more expensive than CPU time I see that you've never worked on a project where the CPU time needed to handle the traffic with crappy code is much more expensive than developer time to write efficient software.
    - dpcx 10y ago
      I have. And one of my first steps after starting to clean things up is to switch to composer and autoload; because then I can start ripping things out much more easily, and still make improvements to both code quality and performance.
- stephenr 10y ago
  > In my mind, auto-loader is a sign that nobody knows what's being loaded Or that, you know. There is an extremely powerful language feature and the developers are taking advantage of it.
SolarUpNote 10y ago
Doesn't Opcache take care of that? Using a large framework isn't really a problem because all of the classes, configuration, etc is all kept in ram.
- TazeTSchnitzel 10y ago
  The code itself is held in shared memory, so it doesn't need to be recompiled. However, you still have the application startup time to worry about.
bkanber 10y ago
> Code paths, auto-loaders, database connections, config files, etc. All that has to happen over and over for each request. So? If it takes < 1ms, what's the harm? And opcode cache comes out of the box and most PHP DB drivers can use connection pooling. We serve most of our requests in < 10ms, and we're not even on PHP7 yet.
- pharrington 10y ago
  Is machine computation mostly responsible for your revenue? If so, would it make more sense to measure web server responses in terms of cpu cycles and such instead of time?
colllectorof 10y ago
>Think about how ActiveRecord in Rails reads from the DB schema to generate it's magic methods, etc. All the magic you ever need can be dynamically created in __get, __set and __call. It works, it works well, and it makes not only reasoning, but also deployment an order of magnitude simpler. >Code paths, auto-loaders, database connections, config files, etc. Use a single code path, a single autoloader and a single database connection. Cache the opcodes of stuff you load. Write config files and templates in pure PHP, so they're cached as well. Done. I've never, ever had problems with bringing PHP page generation time below .1 seconds. Usually it took something like .03 seconds on crappy hardware. And that was without extensive caching of DB results or anything else that's particularly clever.
forgottenpass 10y ago
The downside is literally exactly the same as the upside: you have to bootstrap from literally nothing for every single request. Well, it depends on how it's implemented, and how pedantic someone gets about what "shared nothing" means. There is a long history of unix daemons that initialize, listen(), and then fork off a child process whenever a client connects. The child does all the work and the parent goes back to listening. You can do the "up front" work once and then each child can only modify their copy of the data, preventing it from interfering with the next request.

by mikey_p 10y ago

toast0 10y ago

> Code paths, auto-loaders, database connections, config files, etc. All that has to happen over and over for each request. Do you most of those need to happen at all, ever? In my mind, auto-loader is a sign that nobody knows what's being loaded (if they did, they would just require it). Requires should be full pathed (because have you seen what happens when you search the include path). Mysql_pconnect has been doing connection pooling for a long time, mysqli supports it too (so yes, you do need to connect sometimes), anyway, if you're loading a framwork, loading that probably takes longer than connecting to a mysql server in the same colo.

dpcx 10y ago
IMHO, developer time is more expensive than CPU time; I don't want or need to have to write out all of those requires. That's the job of the autoloader. And if I'm writing my code remotely well enough, each section only uses the things that it needs. Granted, there may be some things that each request get that they don't need with the autoloader. But I can optimize later. "Make it work, make it right, make it fast"
- toast0 10y ago
  Users' time is more important than developer time or CPU time. Burning cpu and maybe i/o looking for code all over the place is going to make it really hard to make it fast later.
- avisser 10y ago
  > I don't want or need to have to write out all of those requires. That's the job of the autoloader. Or the IDE. IntelliJ or ReSharper does that for me. And I like dealing with any naming conflicts right then and there, which those tools allow me to do.
- Twirrim 10y ago
  > IMHO, developer time is more expensive than CPU time; I don't want or need to have to write out all of those requires. Every wasted millisecond on the server side matters. It impacts scalability, customer experience (and revenue) etc. You should take every easy win you can get there. Not doing full includes is just ridiculously lazy. It doesn't take that long to write them out, and your IDE can help you out there. I bet you spend more time on social media during office hours than you'd ever save from not having to type out those import statements.
  - bpicolo 10y ago
    Except you still need autoloading configured for most libraries in the ecosystem to work, unless you want to manually chain absolutely huge quantities of requires.
- cagataygurturk 10y ago
  > IMHO, developer time is more expensive than CPU time I see that you've never worked on a project where the CPU time needed to handle the traffic with crappy code is much more expensive than developer time to write efficient software.
  - dpcx 10y ago
    I have. And one of my first steps after starting to clean things up is to switch to composer and autoload; because then I can start ripping things out much more easily, and still make improvements to both code quality and performance.
stephenr 10y ago
> In my mind, auto-loader is a sign that nobody knows what's being loaded Or that, you know. There is an extremely powerful language feature and the developers are taking advantage of it.

SolarUpNote 10y ago

Doesn't Opcache take care of that? Using a large framework isn't really a problem because all of the classes, configuration, etc is all kept in ram.

TazeTSchnitzel 10y ago
The code itself is held in shared memory, so it doesn't need to be recompiled. However, you still have the application startup time to worry about.

bkanber 10y ago

> Code paths, auto-loaders, database connections, config files, etc. All that has to happen over and over for each request. So? If it takes < 1ms, what's the harm? And opcode cache comes out of the box and most PHP DB drivers can use connection pooling. We serve most of our requests in < 10ms, and we're not even on PHP7 yet.

pharrington 10y ago
Is machine computation mostly responsible for your revenue? If so, would it make more sense to measure web server responses in terms of cpu cycles and such instead of time?

colllectorof 10y ago

>Think about how ActiveRecord in Rails reads from the DB schema to generate it's magic methods, etc. All the magic you ever need can be dynamically created in __get, __set and __call. It works, it works well, and it makes not only reasoning, but also deployment an order of magnitude simpler. >Code paths, auto-loaders, database connections, config files, etc. Use a single code path, a single autoloader and a single database connection. Cache the opcodes of stuff you load. Write config files and templates in pure PHP, so they're cached as well. Done. I've never, ever had problems with bringing PHP page generation time below .1 seconds. Usually it took something like .03 seconds on crappy hardware. And that was without extensive caching of DB results or anything else that's particularly clever.

forgottenpass 10y ago

The downside is literally exactly the same as the upside: you have to bootstrap from literally nothing for every single request. Well, it depends on how it's implemented, and how pedantic someone gets about what "shared nothing" means. There is a long history of unix daemons that initialize, listen(), and then fork off a child process whenever a client connects. The child does all the work and the parent goes back to listening. You can do the "up front" work once and then each child can only modify their copy of the data, preventing it from interfering with the next request.