Changes between Initial Version and Version 15 of Ticket #1


Ignore:
Timestamp:
2008-01-22T16:53:22+01:00 (6 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