CoreCommunity ExtensionsIncubatorDistributionsTYPO3 4.5 ProjectsTYPO3 4.7 ProjectsTYPO3 6.0 ProjectsTYPO3 6.1 ProjectsTYPO3 6.2 Projects (+)

Feature #2662

Database Optimization

Added by Fedir RYKHTIK over 4 years ago. Updated over 2 years ago.

Status:New Start date:2009-02-19
Priority:Must have Due date:
Assignee:- % Done:

0%

Category:- Spent time: 0.50 hour
Target version:- Estimated time:2.00 hours
Votes: 0

Description

Statistic takes to much place, we could find more optimal model to store the data.

Associated revisions

Revision 16484
Added by Oliver Klee over 4 years ago

[Bug 2662] Include of the FE class fails if tslib is not defined, r=niels

Revision 16485
Added by Oliver Klee over 4 years ago

[Bug 2662] Include of the FE class fails if tslib is not defined, r=niels

History

Updated by Sven Wappler over 4 years ago

  • Status changed from New to Rejected

I don't see any possibilities to optimize the datas. This tool is not a statistic tool like the webalizer awstats. So this tool have to save each request for displaying the "path" through the website.

Updated by Fedir RYKHTIK over 4 years ago

  • Tracker changed from Bug to Feature

Updated by Fedir RYKHTIK over 4 years ago

  • Status changed from Rejected to New
  • Estimated time set to 2.00

Before to reject need to understand the problem.

At this moment, the database has not well organized structure. Whatever how we would like to use the extension, there is TOO MUCH DATA. It's possible to make several tables from 'tx_wsstats_tracking' table.

If not, the extension is not possible to use on hostings with small database limits.

2500 visits = 1 Mo, 25000 visits = 10 Mo ...

Proposition to make at least 2 tables: 1-st is for recording visitors's stat(ip, referrer, agent, language), and 2-nd for theirs visits(timestamp, url) - with relation between the tables by wsstats_id.

What are You thinking about it ?

Updated by Sven Wappler over 4 years ago

I can comprehend the problem. This tool is primary made for search engine optimization over a short period of time (one month, maximal three I think). So statistics over browser types, popular requested urls and so on can be stored in an extra table and could be removed of the main table. this 'processed-data' table could disencumber the main table.
I think splitting the data on 2 tables has two problems:
  • performance worsening at inserting data. You have first to make a select query to check if ip, referrer and so on is already in database. At this moment just a inserting is required.
  • At this moment the unique ID of a visitor is generated by ip + agent + time. I see no way to split these data.

Updated by Fedir RYKHTIK over 4 years ago

Thank You for understanding, Sven.

I think we could find a more optimal solution : there are at least two simple possibilities.

First possibility - it's to use sessions to identify returning user. It's quite common solution.

Second - is to make "short MySQL querry", which will look only records 1 hour old with the same unique ID. It will take minimum of system ressources, esspeccially, because 'wsstats_id' column is already indexed.

Even if the extension is made for 1 month only, the volume of data could grow very fast. And it will add more performance to the process of data presentation in BE.

Updated by Sven Wappler over 4 years ago

The problem in using sessions is, that sessions only are possible if the client uses cookies. If the client doesn't accept cookies, it could cause problems?

The unique ID is valid for 1 day. So you have to search in the current day. Is it an advantages to have more records in two tables or a few more data in one table?
I would prefer cleaning old data and using a processed data table to reduce data. The displaying of the results can take time. The inserting process should be as fast as it can be.

Also available in: Atom PDF