Changes between Initial Version and Version 15 of Ticket #1


Ignore:
Timestamp:
2008-01-22T15:53:22Z (8 years ago)
Author:
moo
Comment:

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

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #1

    • Property SAPI changed from to Irrelevant
    • Property Component changed from component1 to website
    • Property Version changed from 1.0 to 1.2-dev
    • Property Milestone changed from 1.1 to 2.0.0
    • Property Owner changed from somebody to moo
    • Property Pending changed from to 0
  • Ticket #1 – Description

    initial v15  
    11There should be a XCache uptime statistics collector, showing you how stable each XCache version is on each php version.
    22
     3functionalities:
    34 * collect informations/statistics from servers those using XCache
    45 * it isn't enabled by default. the server admin have to configure it as an cron job
    56 * 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).
    67 * normal user can see the statistics and choose what php/XCache version to use. or abandon XCache with ea/apc/etc..
     8
     9design rules:
     10 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
     11 1. keep it simple
     12 1. 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
     13 1. high performance client: take as little resource (cpu/memory/diskio) as possible
     14 1. users' profile and servers' profile should be designed for easy assignment.
     15
     16possible implemention of some details:
     17
     18 * data relation
     19  a. each real user has user_profile
     20  a. user_profile has many server_profile (server_profile belongs to user_profile)
     21  a. server_profile has many history_state (history_state belongs to server_profile)
     22 * user profile data detail
     23  * userid (auto_inc, generated by database, mysql)
     24  * nickname
     25  * password (secret)
     26  * email
     27  * showemail (true=public email to all users. false=show email to XCache admin only)
     28 * server profile data detail
     29  * serverid (auto_inc, generated by database, mysql)
     30  * GUID (secret, generated by user)
     31  * CPU class, frequence, count
     32  * memory size
     33  * xcache.size, xcache.count.
     34  * xcache.var_size, xcache.var_count. % xcache.var_size used
     35  * xcache.shm_scheme
     36  * other xcache settings..
     37 * history state
     38  * serverid
     39  * phprequestsrate
     40  * phpbandwidth
     41  * bytes of xcace.size that used
     42  * bytes of xcace.var_size that used
     43  * ...
     44 * profile registration
     45  a. cli tools and/or webpage for generating GUID
     46  a. 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.
     47  a. most of the server info is created and updated by collector client automatically along with some performance/statistics data
     48  a. user can create user profile with password set.
     49  a. 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.
     50 * any evil user can spam the collector server, there should be a easy way to delete spam data
     51 * a page for full user/server profile list
     52 * a page for displaying summary statistics