Non-Cached Benchmark about browser-detect HOT 4 CLOSED

Yep, I would not advise parsing / query the browser settings without cache for every request, it should not even make sense, since the package is designed to provide the best result not the fastest, and it's perfectly fine. My original intention was to identify the visitor's browser on login and store a humanly identifiable browser description to show the user what kind of devices they have logged in, so the invocation only parsed the UA on login.

I have added the cache because the package users started to use the package to identify mobile browsers and redirect based on the result, even tho I still advise to store the important results associated to the visitor for example ins session, or cookies so the system does not even have to invoke the cache since the redirection only happen once.

If you have cache problems my best advice would be to use it in standalone mode (without laravel) and inject your custom solution, but it surely depends on your use case.

Hope this helps, have a good one ^.^

from browser-detect.

Aye there,

Found the statistics, I should have removed it years ago... it was around 1-1,5ms on the hardware which produced the 0.02ms.

I abandoned the benchmarking years ago, since the parsing is below or close to a millisecond nowadays, the cache had a meaningful change when the servers ran HDD but with modern SSD even the uncached results are insignificant. But still, I recommend the memcached/redis options since from personal statistics, I can tell the visitors use the same 50-100 browser with very small variety, so the cache would not use more then 50kb of memory.

from browser-detect.

I have found that doing more than 3-4 queries checking different things ends up in very slow load times so I ditched using this and just queried the UA myself. It does work well although is not comprehensive.

Thanks!

from browser-detect.

@hisorange thanks and good to know. I'm struggling w/ a Laravel redis master/replica bug so I was wondering how worthwhile it is to use the cache. If it is 1-1.5ms then I think it's probably on par w/ cache/no cache anyways and not a big deal.

from browser-detect.