Take for instance my service is an content service provider and client hooks in via api keys to deliver such content to their site visitor, and i have 1000 clients using the api and they have 1000 visitors daily, if am to log i will have 1000x1000 = 1,000,000 logs.
If am to store in a database thats 1million rows Every day.
If am to store in a file, the file will be heavy to read using fopen to check for abuse and run termination functions.
Imagine this scenerio for 10days, that’s huge.
I meant the generic log, not necessarily write to a log, but “keep track of”. You could also summarize this if you’re affraid of too many logs, something like
| day | ApiKey | IP | # of requests |
|---|---|---|---|
| 2020-09-16 | 123 | 1.2.3.4 | 2 |
and then increase # of requests every time someone from a certain IP makes a request using a certain API key. That still allows for some intelligent queries to check if the same API key is being used from multiple IPs, how many requests certain IPs do, if some IPs use multiple API keys etc.
What you’re giving up is request rate, that data is lost.
I wouldn’t store the APIKEY itself there, a reference to it is fine.
1,000,000 isn’t that much BTW, and storage is really cheap these days.
Great idea, thanks a million times
Will you recommend a database approach to it or a file approach like fwrite though am not too good with writing on files, getting each lines and adjusting its value
If you want to retrieve the logs (whether for update or just review), I would imagine it will be much easier to do that in a database. Sticking it in a text file in sequence probably takes less space.
1 Like
I don’t know about this sequence, i will go with database at least i understand that part better than using files
Yeah, definitely go with a database here. Doing in this in files with get real hairy real fast.
1 Like
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.