[Proposel] Improving the speed and core functionality [v2]

[cyrildewit]

Overview

This issue is reserved for optimizing the speed of retrieving and storing page views.

I think that caching everything could improve the speed very much. This would be a nice addition, but the next thing to discuss is how should the page views be stored. Using a simple counter or storing every page view as a record (it currently works like this). But instead of counting all these page views on every request, the total page views could be stored in dedicated attribute on the model (or different table) as a JSON object.

Draft ideas

• Caching all the page views and use them to count (can by quite slow if there are 2 million views)
• Caching the page view count only
• Storing the page view count for various periods (configured in the config file or per model) in a table collumn that will be updated every with an artisan command.

Draft one [branch: v2-testing]

There are two tables needed:

1. page-views This table is only needed for users who wants to keep track of the history
2. page-views-counter

The page views table consists of every maked page view.
The page views counter table contains the same data as the main page-views table, but is counted every day, week etc.

If page views are requested for a time range that's not available in the counters table, it will be counted and stored. This happens only the first time (unless these values are resetted or recounted).

Caching the values in the page-views-counter table could improve the speed for a few milliseconds.

Ideas are very welcome!

[usman22]

but for how much time we can store in cache if views are increasing in seconds?

[cyrildewit]

That is the problem we are facing.

[usman22]

so i think cache cannot be best option for this, because views are always increasing in seconds so we should not update cache again and again in seconds

[cyrildewit]

Maybe adding an extra counter in the JSON object that's done by incrementing. This could be retrieved in a few miliseconds.

Then scheduling a command that recounts this number every hour or day.

Edit: Check my draft under draft ideas.

[usman22]

yes it is a good idea to store the counting of views separately instead of storing a new record on every request that will take a huge space in database as well, and will also be slower while fetching

[cyrildewit]

But by doing that, we can't ask for the total page views that are maked in the past 30 minutes, 2 days or 2 montsh. I can also make this optional for the users who wants this. functionality.

This sounds to me as a nice solution

[usman22]

yeah this will be not possible to tell views for particular days, what if we make a separate table where we'll have one record for each page with a counter attribute, and using it in simple scenario to fetch just total views of a page but if someone asks for views of last month or last hour etc then use original table like we are using right now
Edit: Please use just unique views in other table

[cyrildewit]

That's a pretty nice solution.

I will also store these time ranges in the seperated table.

[usman22]

give it a try and check if it works fine and faster, check my edit in above comment as well

[cyrildewit]

Little update!

I have been working on v2 in the past few days and changed the workflow a little bit.

I think that I found a sweet solution. When the user try to retrieve the page visits of a specific time range, the returned value will be stored in the cache with a time limit.
It is actually a pretty simple solution xD. My first idea was to store these returned values in a different database table, until I released that I could use the cache for this.

I wil also work on a new documentation with more info about the workflow and requirements.