For those who were curious, I ran some benchmarks on the Container along
these lines. (Thanks to Lukas for suggesting how to do so.) They were
run in a Drupal context, but I think the basic conclusions and trends
are fairly universal:
http://drupal.org/node/1915774#comment-7127330
Long story short: As long as your compiled DIC class fits into APC, the
added CPU overhead is basically flat. There's a linear memory impact
that scales more or less linearly with the number of services due to the
class itself getting more lines of code. So the answer to the question
of "how big does the DIC scale?" is "if you can tweak your APC settings,
pretty damned far." :-)
--Larry Garfield
On 02/20/2013 10:41 AM, Benjamin Eberlei wrote:
I don't see how this is relevant for production usage (when the
container is generated), and the building process can be split up into
packages based on service groupings or something at some point i suppose.
On Tue, Feb 19, 2013 at 5:55 PM, Lukas Smith <sm...@pooteeweet.org
<mailto:sm...@pooteeweet.org>> wrote:
On Feb 17, 2013, at 21:30 , Larry Garfield <la...@garfieldtech.com
<mailto:la...@garfieldtech.com>> wrote:
> Greetings, Symfonians.
>
> I know that there is some difference of opinion within the
Symfony world about making controllers ContainerAware vs making
them fully injected services. There's decent arguments both
directions. We're discussing that self-same issue in Drupal right
now:
>
> http://drupal.org/node/1915774
>
> Generally, there seems to be a sense that making them services
would be "better". However, one concern we have there is the
scalability of the DI Container. We're using a PHP compiled
container, which from previous conversations Lukas Smith has told
me should scale fine to a thousand or so services before you need
to start worrying.
>
> Of course, "about a thousand" is a reasonable approximation for
the number of controllers a small Drupal site has[1]. (A powerful
and complex administration system means lots of pages, which means
lots of controllers.) That means if we establish a pattern of
always making controllers services, rather than ContainerAware, we
will run into the point where we have to start worrying about the
Container's scalability with just Drupal core. That's before
getting into contributed modules, which a typical site has in the
dozens. And then there's all of the "real" services that we will
have. Then there's EventSubscribers, which are registered as
services.
>
> That makes the potential scalability of the Container a rather
pressing question for us.
>
> Does anyone have any hard data on just how far the Container
will scale before compiling it becomes a memory or CPU hog, or the
runtime parsing cost gets too big to handle, etc? Just how far
have people pushed the Container before it fell over? We're going
to be pushing it pretty far, so want to make sure it won't fall
over. :-)
>
> (And if you have more direct thoughts on ContainerAware
controllers vs. controller services, please do weigh in on the
issue above.)
i have faint recollections that someone once made some benchmarks
before we want to 2.0 but it wasnt totally conclusive IIRC. it was
enough that we didnt make commands services, but it also did not
make anyone too considered about moving logic from controllers
into services. so better do your own benchmarks with todays code.
regards,
Lukas
--
--
If you want to report a vulnerability issue on Symfony, please
read the procedure on http://symfony.com/security
You received this message because you are subscribed to the Google
Groups "symfony developers" group.
To post to this group, send email to symfony-devs@googlegroups.com
<mailto:symfony-devs@googlegroups.com>
To unsubscribe from this group, send email to
symfony-devs+unsubscr...@googlegroups.com
<mailto:symfony-devs%2bunsubscr...@googlegroups.com>
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
---
You received this message because you are subscribed to the Google
Groups "Symfony developers" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to symfony-devs+unsubscr...@googlegroups.com
<mailto:symfony-devs%2bunsubscr...@googlegroups.com>.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
If you want to report a vulnerability issue on Symfony, please read
the procedure on http://symfony.com/security
You received this message because you are subscribed to the Google
Groups "symfony developers" group.
To post to this group, send email to symfony-devs@googlegroups.com
To unsubscribe from this group, send email to
symfony-devs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
---
You received this message because you are subscribed to the Google
Groups "Symfony developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to symfony-devs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
If you want to report a vulnerability issue on Symfony, please read the
procedure on http://symfony.com/security
You received this message because you are subscribed to the Google
Groups "symfony developers" group.
To post to this group, send email to symfony-devs@googlegroups.com
To unsubscribe from this group, send email to
symfony-devs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
---
You received this message because you are subscribed to the Google Groups "Symfony developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to symfony-devs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
