Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Threadsafe, fast and clean fork - What to do? #9

Open
viblo opened this issue Nov 17, 2017 · 4 comments
Open

Threadsafe, fast and clean fork - What to do? #9

viblo opened this issue Nov 17, 2017 · 4 comments

Comments

@viblo
Copy link

viblo commented Nov 17, 2017

I have rewritten large parts of the UdgerParser from the dev_v3 branch to make it threadsafe, faster and cleanup the code. It passes all the tests, and from my own testing is much faster than the previous version.

Compared to the previous implementation it caches most of the database in memory, except IP locations and IPv6 data center mainly because the IP location lookup table is huge. It adds a flag to do Data Center parsing (DataCenterParserEnabled) so that you enable data center parsing at the same time as IP location can be disabled (so you can run it fully in memory without disk reads and still parse IPv4 data centers).

We have been running it in production for a while, and it seems to be working well.

Currently its a fork available here: https://github.com/nordicfactory/udger-dotnet
I would be happy to make a PR if you think its appropriate.

@markatosi
Copy link

I'm very much looking forward to this. Thanks for your efforts I'll be happy to test.

@flo8
Copy link

flo8 commented Aug 15, 2018

Is this still alive?

@viblo
Copy link
Author

viblo commented Aug 15, 2018

We are still running this in production, processing many millions of user agents and IPs per day. But we haven't really made much changes since I created this issue, only fixed a couple of bugs that we encountered. Otherwise it has been stable.

@markatosi
Copy link

I have been using it briefly but with my data sets the full list scan being done is a performance bottle neck for us relative to the java version. I don't remember the exact name of the method but it has fullscan in it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants