3 ms·

With Doctrine, you need to know what and when to enable caching in the correct layer. Complicated. Personally I avoid ORMs and write SQL, better control and be

With Doctrine, you need to know what and when to enable caching in the correct layer. Complicated. Personally I avoid ORMs and write SQL, better control and better performance.

naranha 10y ago
It's not just doctrine that makes it slow, it's the whole bootstrapping process on every request. Compare this to a Java Application using JPA and JAX-RS with >50 model classes and >10GB data which gives response times of <10ms with debugging enabled (OK it uses more RAM, but meh).
- fetbaffe 10y ago
  Yes, that is problem, therefore I avoid frameworks to have total control when bootstrapping.
- mschuster91 10y ago
  > It's not just doctrine that makes it slow, it's the whole bootstrapping process on every request. When you use proper opcode caching, you avoid the startup hit. And having a generous amount of RAM usable as disk cache also helps in framework-heavy projects - the more files can be cached in RAM, the less PHP has to hit the disk on require/include.
  - bad_login 10y ago
    > When you use proper opcode caching, you avoid the startup hit. In a setup with nginx, php-fpm and symfony here is how i understand the whole process. 1. A request hit nginx 2. Nginx parse the request and send it as fastcgi protocol specify to php-fpm. 3. Php-fpm looks it's pool of php processes if there is none available, it starts a php process (so some code is run). 4. Php-fpm fill the $_GET,$_POST etc... variable of the running php and give it a file to execute. 5. The php process check if the file is in opcache load the bytecode from it otherwise compile the file to bytecode and store it to opcache. 6. The process run the script and write back to php-fpm who write back to nginx. So now more on 6. from the point of view of a Symfony app. 1. the app.php will include an autoloader, this mean during the lifetime of the php process every time a new \Some\Class\Or\Function\Or\Whatelse is encounter the autoloader code will be run. To mitigate this composer could generate an autoload that is an associative array of \ClassName\And\The\Like => filename. 2. Then it include the bootstrap.cache.php this file is a concatenation of the Symfony classes (all or the most used) in order to reduce autoloader calls. 3. Then it create the kernel the it load more file (from app/cache) like the service container definition+configuration and the routing (and maybe more stuff but i don't know). 4. Then it put $_GET,$_POST etc... on it's own abstractions (HttpFoundation\Request etc...). 5. At this point the bootstraping is done. And i also want to remind that a class declaration like "class House {}" is a code, that create a datastruct that has to be run on every request, this is also what people call bootstraping. The bootstraping is take seriously enough to have : 1. composer -o (generate the associative array) 2. bootstrap.cache.php 3. the whole app/cache directory of symfony which i find pretty terrible as comp. sci. point of view (choose a limited language and build compilers to work around) even if they do a great job at error reporting. 4. php-fpm pool of thread 5. opcache
  - cagataygurturk 10y ago
    All those opcodes etc. are the "hacks" to accelerate php bootstrapping. For example in java there are already threads waiting for the request and when a request comes, the path of the request until the controller is much less. There are cache connection, db connection, everything is ready waiting for the request. In PHP for every request the same story is repeating and repeating. If you have a index.php, serving directly your logic, there is no problem, php is designed for those use cases. But if you are using a modern PHP framework that mimics Other platforms (I believe most of them are inspired by JAVA), you are having a big overhead because PHP is not designed to behave like this. Another question, with those modern PHP frameworks you are already learning and applying almost every concept that you can use with (let's say) JAVA. Then why not to use that powerful platform which inspires PHP? It is like you have driving licence for a truck and you can drive a truck almost perfectly after 3 months of practice, but still you prefer your old minivan to carry 10 tons of load. The minivan was not designed for 10 tons of load but there are some modifications allowing that, but if you spend 30% more fuel. Don't come with the argument of "php is easy". It is as hard as other similar languages.
    - fetbaffe 10y ago
      The language is as hard or as easy as any other similar language, yes, but the platform is much more easy to learn and use. Usually it is the platform, community and the environment that takes time to learn for any language. Large PHP frameworks I think is starting to reach end of line. Seems like a micro framework trend has started with Zend Expressive and similar middleware based frameworks. There was a trend of making PHP into Java, I think that is the wrong path, as you say, Java already exists. That trend also existed in JavaScript a long time ago. Seems like a natural instinct by some developers to do so when trying to create structure from a chaos like world. Much better to build on PHP strengths. Dynamic, stateless, fast development cycle.

With Doctrine, you need to know what and when to enable caching in the correct layer. Complicated. Personally I avoid ORMs and write SQL, better control and better performance.

naranha 10y ago

It's not just doctrine that makes it slow, it's the whole bootstrapping process on every request. Compare this to a Java Application using JPA and JAX-RS with >50 model classes and >10GB data which gives response times of <10ms with debugging enabled (OK it uses more RAM, but meh).

fetbaffe 10y ago
Yes, that is problem, therefore I avoid frameworks to have total control when bootstrapping.
mschuster91 10y ago
> It's not just doctrine that makes it slow, it's the whole bootstrapping process on every request. When you use proper opcode caching, you avoid the startup hit. And having a generous amount of RAM usable as disk cache also helps in framework-heavy projects - the more files can be cached in RAM, the less PHP has to hit the disk on require/include.
- bad_login 10y ago
  > When you use proper opcode caching, you avoid the startup hit. In a setup with nginx, php-fpm and symfony here is how i understand the whole process. 1. A request hit nginx 2. Nginx parse the request and send it as fastcgi protocol specify to php-fpm. 3. Php-fpm looks it's pool of php processes if there is none available, it starts a php process (so some code is run). 4. Php-fpm fill the $_GET,$_POST etc... variable of the running php and give it a file to execute. 5. The php process check if the file is in opcache load the bytecode from it otherwise compile the file to bytecode and store it to opcache. 6. The process run the script and write back to php-fpm who write back to nginx. So now more on 6. from the point of view of a Symfony app. 1. the app.php will include an autoloader, this mean during the lifetime of the php process every time a new \Some\Class\Or\Function\Or\Whatelse is encounter the autoloader code will be run. To mitigate this composer could generate an autoload that is an associative array of \ClassName\And\The\Like => filename. 2. Then it include the bootstrap.cache.php this file is a concatenation of the Symfony classes (all or the most used) in order to reduce autoloader calls. 3. Then it create the kernel the it load more file (from app/cache) like the service container definition+configuration and the routing (and maybe more stuff but i don't know). 4. Then it put $_GET,$_POST etc... on it's own abstractions (HttpFoundation\Request etc...). 5. At this point the bootstraping is done. And i also want to remind that a class declaration like "class House {}" is a code, that create a datastruct that has to be run on every request, this is also what people call bootstraping. The bootstraping is take seriously enough to have : 1. composer -o (generate the associative array) 2. bootstrap.cache.php 3. the whole app/cache directory of symfony which i find pretty terrible as comp. sci. point of view (choose a limited language and build compilers to work around) even if they do a great job at error reporting. 4. php-fpm pool of thread 5. opcache
- cagataygurturk 10y ago
  All those opcodes etc. are the "hacks" to accelerate php bootstrapping. For example in java there are already threads waiting for the request and when a request comes, the path of the request until the controller is much less. There are cache connection, db connection, everything is ready waiting for the request. In PHP for every request the same story is repeating and repeating. If you have a index.php, serving directly your logic, there is no problem, php is designed for those use cases. But if you are using a modern PHP framework that mimics Other platforms (I believe most of them are inspired by JAVA), you are having a big overhead because PHP is not designed to behave like this. Another question, with those modern PHP frameworks you are already learning and applying almost every concept that you can use with (let's say) JAVA. Then why not to use that powerful platform which inspires PHP? It is like you have driving licence for a truck and you can drive a truck almost perfectly after 3 months of practice, but still you prefer your old minivan to carry 10 tons of load. The minivan was not designed for 10 tons of load but there are some modifications allowing that, but if you spend 30% more fuel. Don't come with the argument of "php is easy". It is as hard as other similar languages.
  - fetbaffe 10y ago
    The language is as hard or as easy as any other similar language, yes, but the platform is much more easy to learn and use. Usually it is the platform, community and the environment that takes time to learn for any language. Large PHP frameworks I think is starting to reach end of line. Seems like a micro framework trend has started with Zend Expressive and similar middleware based frameworks. There was a trend of making PHP into Java, I think that is the wrong path, as you say, Java already exists. That trend also existed in JavaScript a long time ago. Seems like a natural instinct by some developers to do so when trying to create structure from a chaos like world. Much better to build on PHP strengths. Dynamic, stateless, fast development cycle.