@mattab opened this Issue on December 21st 2012 Member

This is a performance improvement ticket.

  • It is possible to disable piwik.php from tracking (ie. not select/update/insert) from the DB. See the Faq to enable the maintenance mode: http://piwik.org/faq/how-to/#faq_111
  • When this is enabled, the webserver will return very quickly the transparent GIF. It will also log the piwik.php request in the apache server logs. It turns out this request contains (by design) the full set of information required by Tracking.
  • We should provide a new CRON script that will, replay the piwik.php server logs every 1 minute for example. We could make use of Piwik Bulk Tracking features to import ie. 500 lines at once from the log.

Summary:
Power users will be able to setup Piwik where the Mysql is not required for tracking.
A script will run that will import, every N minutes (for example N=1 or N=60) the Webserver access logs into Piwik.
This script will use our log analytics tool to import the piwik.php requests.
It won't be as "real time" as before since loading logs is asynchronous, but could be set every 1 minute for near real time.

This will make Piwik tracking decoupled from Mysql, more resilient, faster, easier to scale.

@mattab commented on December 21st 2012 Member
@anonymous-matomo-user commented on December 21st 2012

Attachment: Anonymized logfile with german data + umlauts
mysnip-stats.log-22-00.anon.gz

@mattab commented on December 21st 2012 Member

Thanks to Thomas Seifert who provides Piwik hosted, for this patch!

@mattab commented on December 21st 2012 Member

Thanks for the patch!

Code review/ TO Dos

  • if 'cdt' parameter is found in the piwik.php request, do not overwrite it with the access log date, but forward the original 'cdt'
  • same for 'cip': if found in the piwik.php? request, forward it and don't use log IP
  • idem for 'ua' which should overwrite the log user agent
@cbay commented on December 21st 2012 Contributor

Rather than doing the job in the Recorder class, I'd rather have it in the Parser class, as it's really a parsing thing. Basically, the parser creates a Hit object that has all required properties for the Recorder to use. I'll make changes so that the Hit object has an 'args' property where you can override anything you want.

query_arguments = urlparse.parse_qs(hit.query_string)
for k in query_arguments:
    query_arguments[k]=query_arguments[k].pop()
    query_arguments[k]=query_arguments[k].encode('raw_unicode_escape').decode('utf-8')

This is not very Pythonesque. Don't modify the dictionary as you iterate over it; instead, create a new one:

query_args = dict(
    (key, value.pop().encode('raw_unicode_escape').decode('utf-8') for key, value in query_arguments.iteritems())
)

Why is it required to do the encode/decode? What format has the string initially?

@anonymous-matomo-user commented on December 21st 2012

This is not very Pythonesque. Don't modify the dictionary as you iterate over it; instead, create a new one

I know. As I already told to matt, my language of choice is PHP and for Python I'm just a beginner - you should really have a deep look into it :). I'd love to see what you make out of it.

Why is it required to do the encode/decode? What format has the string initially?

Well, the string is directly from the logfile and without that encode/decode I got garbled characters for page titles with umlauts in german.

Also you really should remove the return True in the beginning of check_http_error - I added it to get rid of some missing imported lines but from the code around it it can only be wrong.

One additional enhancement in my mind would be to skip requests being not piwik.php requests when the replay is enabled.

@cbay commented on December 21st 2012 Contributor

Could attach a log file with those umlauts?

@cbay commented on December 23rd 2012 Contributor

I've just commited a small change that will let you put your code in the Parser, as I suggested: you now have a 'args' attribute in the Hit object that you can use to override your args.

Regarding the Unicode thing, I'm not 100% sure this is the best way to handle it but this is really not an easy one, as there are so many parameters to think about: the log file encoding, the HTTP encoding, etc. Are we sure we always have UTF8 at this point? Does it depend on Piwik? Anyway, if it works that way, go for it ;)

Send me your next diff when it's ready so I can make a proper review before it gets committed.

@anonymous-matomo-user commented on February 13th 2013

I wasn't aware ot that request / proposal, and I've already opened a topic on the forum.
http://forum.piwik.org/read.php?2,100735

@anonymous-matomo-user commented on February 15th 2013

Any update since 2 months ? I am also looking into this and it would be great to have the latest status of this ticket. Thanks !

@mattab commented on February 15th 2013 Member
@mattab commented on February 26th 2013 Member

Reopening, pending:

  • See pull request: https://github.com/piwik/piwik/pull/34
    needs to be merged + tested + reviewed to ensure code is 100% correct
  • add integration test similar to importlogstest but only with piwik.php? logs
@diosmosis commented on February 27th 2013 Member

Changeset [changeset:7e93e75012153e5f79d3bac98d9662e43b9df21d] refs this ticket.

@diosmosis commented on February 27th 2013 Member

In 5dca1a29bd36a17911406b9348cf9982484dbde9: Refs #3632, add integration test for import script replay tracking.

@diosmosis commented on February 27th 2013 Member

In 4b54ac17d0023323ab381062538b3bf584fe7ae8: Refs #3632, Remove stray debugging code.

@diosmosis commented on February 27th 2013 Member

In a06d9613178efe0d4deeb4e8862eca06006c42c1: Fixes #3632, refactor/tweak pull request #34 merge.

@mattab commented on March 1st 2013 Member

In 4d7f93bec0bedd29ee74e003a0bff66b63587928: Refs #3632 More Code coverage for log importer using multiple site IDs

@mattab commented on February 4th 2014 Member
@mattab commented on March 13th 2014 Member

In 73f33463b1bbf8e7e547edc4f80c0bc7d3198c19: Refs #3632 Adding more tests cases for log replay functionnality
Forcing all recorders and recorders max payload to 1, to prevent random behavior (eg. in Live.getLastVisitsDetails, the pageIdAction may be random order if recorders import data in random thread order)

@mattab commented on March 13th 2014 Member

In b6dfdc06e084f46668c679f0110e5a67146cef43: Refs #3632 test case that _idvc > 1 will set visitor returning status

@mattab commented on March 13th 2014 Member

In fd13666a79962545ac878e4a18d5909ac3923eb8: Refs #3632 Creating a test case: same visitor (same IP + idvisitor) visits the website on two different days.
Visitors on second day is marked as "new" because window_look_back_for_visitor is not set.

@mattab commented on March 13th 2014 Member

In 029bb8794fe24eeb08d52c1aa39d04c64a6496fd: Refs #3632 New test case: replaying logs and forcing a window look back (forceLargeWindowLookBackForVisitor=1)
=> The visitor is now marked as "returning" as expected

@mattab commented on March 13th 2014 Member

In 4328fd817349f70a2210f5e4a7fcd233c4e29387: Refs #3632 Small refactor and support parameter forceLargeWindowLookBackForVisitor=1 in tests when replaying tracking logs

@mattab commented on March 14th 2014 Member

In aae4433b390f4e5d1dee4a02ab63011b1f0d333c: Refs #3632 Check Engagement reports are properly set when replaying logs

This Issue was closed on March 14th 2014
Powered by GitHub Issue Mirror