-
Notifications
You must be signed in to change notification settings - Fork 0
Home
Jan Vilhuber edited this page Apr 16, 2015
·
15 revisions
Possible Performance Improvements
split off the StopToken from the DeviceInfo entry, and let the web-server directly manage it, so we can avoid the RPC call. Possibly even keep it in memory, but then we have to make sure any changes are properly sync'd with the DB. This would also allow us to respond to the client quicker, i.e. generate a stop token, respond and make a go-routine throw the request over to the RPC server.
TODO:
- items needed before deployment
- HA DB
- define schema: deviceContact schema plus push-service, push-token, pinger
- also need the pinger table
- provisioning
- config items (keys, certs, pinger config) in s3. s3 keys in ec2-user-data
- add script to pull user-data and then fetch the items from s3
- per process roles and users
- SELinux
- monitoring
- tripwire
- logs
- do some log rotation and log compression/deletion for pinger and webserver logs
- need something to email on crash or panic in logs. Perhaps that's what telemetry will be for.
- supervisord events might be able to do this, if I log recoverCrash to stderr as well as the logfile.
- or logwatch? or AWS logwatch?
- CRL check frequency
- HA DB
- Rate limit incoming requests. Use some negroni middleware, preferably (see Utils/middleware.go)
Cleanup the structure cleanup, so that structures aren't cleaned up out from under a running goroutine.- inspect code for resource leakage
- inspect code for concurrent-access issues to data struct (related to the cleanup item above)
investigate telemetry for pinger