You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
MaxMindBinaryProvider is not lazy and adds overhead to every request #301
The GeoIP composer library (maxmind/geoip-api-php), which is required when using the MaxMindBinaryProvider, includes several files for every request (NOT lazy):
This adds between 2 and 4ms in production to every request (with APC enabled). The only way to avoid that is to remove the dependency to the GeoIP composer package, which forces the loading in its composer.json:
I think Geocoder should not rely on geoip/geoip, but ask the user to download manually GeoIP data to a certain location. Then the user could configure that location in Geocoder, so that the GeoIP provider can (lazy-)load the data.
Mmmmh, so you are talking about the MaxMindBinaryProvider, right? I do agree that such provider is far from good, especially because of the third-party dependency it uses under the hood...
What about using the GeoipProvider? It relies on the geoip PHP ext, and it seems to be what you are looking for.
Right, we're using the MaxMindBinaryProvider. I'll look at the GeoipProvider, but since it implies some work on the ops side, I'm not sure it's a very good alternative. Besides, does it perform better when profiling? I want to be sure that the time invested to switch providers will produce results.
Even if the GeoIPProvider solves our problem, I suggest that you add a warning about the MaxMindBinaryProvider, since it should not be used in production IMO.
changed the title [-]GeoIP provider is not lazy and adds overhead to every request[/-][+]MaxMindBinaryProvider is not lazy and adds overhead to every request[/+]on Apr 2, 2014
Activity
willdurand commentedon Apr 1, 2014
I don't get your point. What should we do? Explaining in the doc that the GeoIP provider is not that good, because of the issue you mention here?
fzaninotto commentedon Apr 1, 2014
I think Geocoder should not rely on
geoip/geoip, but ask the user to download manually GeoIP data to a certain location. Then the user could configure that location in Geocoder, so that the GeoIP provider can (lazy-)load the data.oschwald commentedon Apr 2, 2014
Maybe it could be replaced with GeoIP2. With the legacy database design, a lot of data ended up in the API, which is a primary factor here.
willdurand commentedon Apr 2, 2014
Mmmmh, so you are talking about the MaxMindBinaryProvider, right? I do agree that such provider is far from good, especially because of the third-party dependency it uses under the hood...
What about using the GeoipProvider? It relies on the
geoipPHP ext, and it seems to be what you are looking for.fzaninotto commentedon Apr 2, 2014
Right, we're using the MaxMindBinaryProvider. I'll look at the GeoipProvider, but since it implies some work on the ops side, I'm not sure it's a very good alternative. Besides, does it perform better when profiling? I want to be sure that the time invested to switch providers will produce results.
Even if the GeoIPProvider solves our problem, I suggest that you add a warning about the MaxMindBinaryProvider, since it should not be used in production IMO.
[-]GeoIP provider is not lazy and adds overhead to every request[/-][+]MaxMindBinaryProvider is not lazy and adds overhead to every request[/+]fzaninotto commentedon Apr 2, 2014
updated issue title and description to lift the misunderstanding
willdurand commentedon Apr 2, 2014
I don't have any benchmarks, I never used these providers myself honestly...
I'm going to update the doc first, and open an issue to introduce a new provider, wrapping the GeoIP2 lib.
Add a note about MaxMindBinaryProvider