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 }}
This repository has been archived by the owner on Nov 6, 2021. It is now read-only.
Test if uaparser leverages opcache when loading the source JSON file. I'm not sure how opcaches work - will they cache such file? If not, then moving the source file to PHP will be a huuuuge performance boost for non bulk + opcache situation. Which is the most common scenarion on high traffic production servers.
If such switch should be made - create a commit to uaparser project.
The text was updated successfully, but these errors were encountered:
JSON files are not cached, so I've changed the ua-parser source file to PHP file and tested the speed, and it seem that the performance boost is, indeed, very significant. Although I'm getting some weird results when comparing bulk parsing to one-per-script parsing...
There, we go, I messed up the time measuring :) but when I fixed it the results are as follows: 0.5 ms per user agent in bulk mode, no matter what the source format is or if the opcache is of or on 1.3 ms per user agent in single-call mode when using json file and no opcache 1.1 ms per user agent in single-call mode when using json file with opcache 1.3 ms per user agent in single-call mode when using php file and no opcache 0.6 ms per user agent in single-call mode when using php file with opcache
Test if uaparser leverages opcache when loading the source JSON file. I'm not sure how opcaches work - will they cache such file? If not, then moving the source file to PHP will be a huuuuge performance boost for
non bulk + opcache
situation. Which is the most common scenarion on high traffic production servers.If such switch should be made - create a commit to uaparser project.
The text was updated successfully, but these errors were encountered: