[WebProfilerBundle] [HttpKernel] Version feedback feature slows down application behind corporate proxy #14349
Comments
|
Yes, that's the issue I mentioned in PR for that feature. Better would be to remove whole external call & use pregenerate constant values like is used for versions etc. |
This was referenced Apr 14, 2015
No it's not German. It's sober man thing. 👍 |
Tobion
added a commit
that referenced
this issue
Apr 28, 2015
…rsion feedback (derrabus) This PR was squashed before being merged into the 2.7 branch (closes #14351). Discussion ---------- [WebProfilerBundle] [HttpKernel] A static approach to version feedback | Q | A | ------------- | --- | Bug fix? | yes | New feature? | yes | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #14349, #13626 | License | MIT | Doc PR | N/A This is an alternative approach for the version feedback feature of PR #13626. The original PR performed a server-side HTTP request to symfony.com, which might be problematic in certain environments, see #14349. This PR makes the following assumptions: * Symfony's release roadmap is rarely changed * After the first release of a branch, the Symfony development team is committed to the announced support dates. * The support period of a stable branch might be extended, but it's usually not reduced. Given those assumptions, the EOM and EOL dates may be shipped with the Symfony release and may be updated with a later bugfix release. The information would be available offline without any need to query Symfony's servers. If the user is running the latest bugfix release of a branch, the EOM/EOL dates should be accurate. If he's running an earlier version, he might get a false positive warning about reaching EOM or EOL if the support period has been extended in the meantime. But since he's running an outdated version anyway, would this really be a problem? Commits ------- f5f3bba [WebProfilerBundle] [HttpKernel] A static approach to version feedback
|
Fixed via #14351. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Now that the first beta release of Symfony 2.7 is available, I tried to upgrade my client's projects from Symfony 2.6 to 2.7. After the upgrade, the application became extremely slow: Each request took two minutes (!) to complete.
Tracing down the problem, I found that a
file_get_contents()call inside theConfigDataCollectorclass of the HttpKernel component took so much time. Obviously, it's the version feedback feature introduced with #13626 that causes this trouble. I wasn't aware of this feature until then.The problem is that the development team of my client is sitting behind a corporate proxy. Any attempt make HTTP calls without using the proxy will result in a timeout and I guess that is what's happening here. The version check should not slow down the application, which is probably why the response of the version check is cached. But since there is no response after a timeout, nothing is cached, so we're running into this timeout on every request. If I comment out the
file_get_contents()call, the application is running smooth again.Please reconsider this feature or at least its implementation. The idea of notifying developers about outdated dependencies is not bad in general, but here it causes more harm than it actually helps.
Side note: Maybe it's a German thing, but I personally don't like software that secretly calls home.
The text was updated successfully, but these errors were encountered: