Identity/PersonaProfileServer: Difference between revisions
< Identity
Jump to navigation
Jump to search
Stomlinson (talk | contribs) (→TODO) |
(→Description: link to my blog post about optimizing pngs) |
||
(4 intermediate revisions by the same user not shown) | |||
Line 6: | Line 6: | ||
* some kind of data storage (MySQL, but with generic key/value schema) | * some kind of data storage (MySQL, but with generic key/value schema) | ||
* profile data will be key-wrapped | * profile data will be key-wrapped | ||
* from an ops point of view, it's better to spend lots of CPU optimizing images at upload time then to serve | * from an ops point of view, it's better to spend lots of CPU [http://feeding.cloud.geek.nz/2011/12/optimising-png-files.html optimizing images] at upload time then to serve unoptimized images | ||
= Things to avoid = | = Things to avoid = | ||
Line 17: | Line 17: | ||
* What is the maximum amount of data that can be stored per user? | * What is the maximum amount of data that can be stored per user? | ||
** TBC: depends on number of emails and max size for pictures | |||
* Are we storing arbitrary keys or are only well defined keys going to be allowed? | * Are we storing arbitrary keys or are only well defined keys going to be allowed? | ||
** No | |||
* How often is this data accessed? What is the write pattern? What is the read pattern? (only accessed at registration? not written often?) | * How often is this data accessed? What is the write pattern? What is the read pattern? (only accessed at registration? not written often?) | ||
* How are we handing back the data? | * How are we handing back the data? | ||
* What does the API look like? | * What does the API look like? | ||
* If we launch as an alpha service, how do we handle migration from alpha to beta to release? | * If we launch as an alpha service, how do we handle migration from alpha to beta to release? | ||
** Not a problem as long as we consult with ops while designing the labs prototype. | |||
* Can other services be attached to this DB? | * Can other services be attached to this DB? | ||
** Not for now (even though it looks like the schema might be similar to contacts) | |||
* What is our timeline? What is the data that we are going to use to decide when this is going to come out of labs and into production? | * What is our timeline? What is the data that we are going to use to decide when this is going to come out of labs and into production? | ||
** 2012Q1 ;) | |||
* What is the data SLA? Where does data need to be backed up? | * What is the data SLA? Where does data need to be backed up? | ||
* What happens when the profile server is down? Does BrowserID sign-in depend on it? | * What happens when the profile server is down? Does BrowserID sign-in depend on it? | ||
** You can still login but there's some kind fallback design/graphics for the "moocards". | |||
* Can we push image resizing / optimizing to the client? | * Can we push image resizing / optimizing to the client? | ||
** Not all of it (we'll probably be runing optipng/advpng/jpegoptim/pngcrush), but hopefully some of it. | |||
= TODO = | = TODO = | ||
* Look at lloyd's [https://github.com/mozilla/browserid/wiki/Scaling-to-1M scaling to 1M] page and do something similar (assume everybody is uploading huge pictures we have to resize) | |||
* Look at lloyd's scaling to 1M | |||
* Talk to security folks, what needs to happen in what order? | * Talk to security folks, what needs to happen in what order? | ||
* Talk to David Ascher and user data group to find out about data collection implications. | * Talk to David Ascher and user data group to find out about data collection implications. | ||
** We need to discuss our plans on dev-identity to sollicit differing opinions | |||
** Write up a document similar to https://da.etherpad.mozilla.org/kpi-backend | |||
* Find out max and average number of emails per user [petef] | |||
* Decide on a maximum image size [skinny] | |||
* Run the moocard idea past skinny [shane] |
Latest revision as of 20:28, 4 May 2012
Warning: These are just rough notes. We are in the early stages of our discussions with ops, so this will definitely change.
Description
- different domain for profile server to scale it out differently
- some kind of data storage (MySQL, but with generic key/value schema)
- profile data will be key-wrapped
- from an ops point of view, it's better to spend lots of CPU optimizing images at upload time then to serve unoptimized images
Things to avoid
- don't want to be a CDN for images (to prevent abuse -- "persona profile filesystem")
- we probably don't want to store arbitrary key-value store for users
- planning on moving very quickly from labs to prod: it will take about a quarter to move once we say we're ready
Questions
- What is the maximum amount of data that can be stored per user?
- TBC: depends on number of emails and max size for pictures
- Are we storing arbitrary keys or are only well defined keys going to be allowed?
- No
- How often is this data accessed? What is the write pattern? What is the read pattern? (only accessed at registration? not written often?)
- How are we handing back the data?
- What does the API look like?
- If we launch as an alpha service, how do we handle migration from alpha to beta to release?
- Not a problem as long as we consult with ops while designing the labs prototype.
- Can other services be attached to this DB?
- Not for now (even though it looks like the schema might be similar to contacts)
- What is our timeline? What is the data that we are going to use to decide when this is going to come out of labs and into production?
- 2012Q1 ;)
- What is the data SLA? Where does data need to be backed up?
- What happens when the profile server is down? Does BrowserID sign-in depend on it?
- You can still login but there's some kind fallback design/graphics for the "moocards".
- Can we push image resizing / optimizing to the client?
- Not all of it (we'll probably be runing optipng/advpng/jpegoptim/pngcrush), but hopefully some of it.
TODO
- Look at lloyd's scaling to 1M page and do something similar (assume everybody is uploading huge pictures we have to resize)
- Talk to security folks, what needs to happen in what order?
- Talk to David Ascher and user data group to find out about data collection implications.
- We need to discuss our plans on dev-identity to sollicit differing opinions
- Write up a document similar to https://da.etherpad.mozilla.org/kpi-backend
- Find out max and average number of emails per user [petef]
- Decide on a maximum image size [skinny]
- Run the moocard idea past skinny [shane]