Opened 14 years ago

Last modified 12 years ago

#1 new enhancement

[TODO] A Uptime statistics collector

Reported by: moo Owned by: moo
Priority: major Milestone: 5.0.0
Component: website Version: 1.2-dev
Keywords: Cc:
Application: PHP Version:
Other Exts: SAPI: Irrelevant
Probability: Blocked By:

Description (last modified by moo)

There should be a XCache uptime statistics collector, showing you how stable each XCache version is on each php version.


  • collect informations/statistics from servers those using XCache
  • it isn't enabled by default. the server admin have to configure it as an cron job
  • the server admin choose what to be collected, while not leaking other information. e.g.: collect network traffic, php hits/s, loadavg, but don't leak its ip address, hide email address from normal user except XCache admin (for contact).
  • normal user can see the statistics and choose what php/XCache version to use. or abandon XCache with ea/apc/etc..

design rules:

  1. back compatibility. because newer collector client might have more info than the old one that submit to collector server, the server and display page should compatible with old clients
  2. keep it simple
  3. easy to setup on collector client side (not collector server, aka. XCache users' production server), don't pull out many package dependency. e.g.: use bash/sh or php for programming language
  4. high performance client: take as little resource (cpu/memory/diskio) as possible
  5. users' profile and servers' profile should be designed for easy assignment.

possible implemention of some details:

  • data relation
    1. each real user has user_profile
    2. user_profile has many server_profile (server_profile belongs to user_profile)
    3. server_profile has many history_state (history_state belongs to server_profile)
  • user profile data detail
    • userid (auto_inc, generated by database, mysql)
    • nickname
    • password (secret)
    • email
    • showemail (true=public email to all users. false=show email to XCache admin only)
  • server profile data detail
    • serverid (auto_inc, generated by database, mysql)
    • GUID (secret, generated by user)
    • CPU class, frequence, count
    • memory size
    • xcache.size, xcache.count.
    • xcache.var_size, xcache.var_count. % xcache.var_size used
    • xcache.shm_scheme
    • other xcache settings..
  • history state
    • serverid
    • phprequestsrate
    • phpbandwidth
    • bytes of xcace.size that used
    • bytes of xcace.var_size that used
    • ...
  • profile registration
    1. cli tools and/or webpage for generating GUID
    2. it is suggested that the user should generate the GUID and let the collector always use the same GUID for the same server. but we can let the collector generate a GUID and save it in /var/tmp/xcache.server.guid or whereever for easy of use.
    3. most of the server info is created and updated by collector client automatically along with some performance/statistics data
    4. user can create user profile with password set.
    5. logined user and can assign any server profile that's not assigned yet AND if he knows the secret GUID, or delete the profile. or assign the server profile (which belongs to current logined user profile) to other user profile.
  • any evil user can spam the collector server, there should be a easy way to delete spam data
  • a page for full user/server profile list
  • a page for displaying summary statistics

Change History (8)

comment:1 Changed 14 years ago by moo

  • Owner changed from somebody to moo

comment:10 Changed 14 years ago by moo

  • Milestone changed from 1.1 to 1.2
  • Version changed from 1.0 to 1.2-dev

comment:11 Changed 13 years ago by moo

  • Milestone changed from 1.2 to 2.0.0

comment:12 Changed 13 years ago by Nneel

so in version 2.0.0 we are going to get this feature?
attractive feature.

comment:13 Changed 12 years ago by moo

  • Component changed from component1 to website
  • pending set to 0
  • SAPI set to Irrelevant

comment:14 Changed 12 years ago by axel


i already wrote you an email because i was interested in this task, can you specify what information should be collected?

And how will the data transferd to the server ( XML, Rest ) ?

best regards,


comment:15 Changed 12 years ago by moo

  • Description modified (diff)

sorry, i may missed some email

this mission is not even designed yet. i just have the idea to make users' statistics public to all other users while keeping it anonymous. it doesn't matter what technology is used, but i'd keep it simple and easy for use at first, and we can always improve it later after users' feedback.

i've updated the ticket description

comment:16 Changed 12 years ago by moo

we should implement the collector client/server and database struct first and decide "what information should be collected" later. i'm sure the info can be normal-form-ized, and is simply historical or non-historical data.

Note: See TracTickets for help on using tickets.