The official AWS S3 docs on Request Rate and Performance Considerations for S3 clearly state, Amazon S3 scales to support very high request rates.
Sometimes this doesn’t appear to be the case in practise given you start pushing your request rates to the bucket and around the 700 requests per second mark you suddenly get hit with these slow down responses.
This is actually a good thing!
Now although many sites rarely sees 2billion hits a month or 1000 hits per second, why should they not be capable of this, although the direct correlation is loose, with concurrency can come speed.
Speed in this sense is possibly even serving a page to a single user at a time but why not do it in a decent timeframe.
Throwing hardware at it is one way to achieve this goal but why not do the same off a tiny VPS just with a little bit of caching. Continue reading
Another short one but to get to grips with Tornado (the asynchronous web server) there is a great explaination at:
Understanding the code inside Tornado, the asynchronous web server
You can find Tornado on github, here
An extract straight from ISC2’s CSSLP Overview but always useful to consider. The rest of the CSSLP brochure can be found here (pdf).
| Characteristic | What is it? | Insecure Code Examples | How to Fix It | |
|---|---|---|---|---|
| I | Injectable Code | Code that makes injection attacks possible by allowing user supplied input to be executed as code. | No input validation, Dynamic construction of queries |
Input validation, Parameterized queries |
| N | Non-Repudiation Mechanisms not Present | Authenticity of code origin and actions are disputable. | Unsigned executables, Auditing not present |
Code Signing |
| S | Spoofable Code | Code that makes spoofing attacks possible. | Predictable session identifiers, hard-coded passwords, caching credentials and allowing identify impersonation | Session, Cache and Password Management, Managing identify impersonation |
| E | Exceptions and Errors not Properly Handled | Code that reveals verbose error messages and exception details, or fails-open in the event of a failure. | Verbose errors, Unhandled exceptions, Fails open |
Non-verbose error messages, Explicit exception handling (Try-Catch-Finally blocks), Fail-secure |
| C | Cryptographically Weak Code | Code that uses non-standard, weak or custom cryptographic algorithms and manages keys insecurely. | Key not derived and managed securely | Do no use weak, non-standard, algorithms, custom cryptography, Use RNG/PRNG for key derivation |
| U | Unsafe/Unused Functions and Routines in Code | Code that increases attach surface by using unsafe routines or containing unused routines. | Banned API functions, Easter Eggs |
Do no use banned APIs, unsafe functions, Input validation, remove unused routines and Easter Eggs |
| R | Reversible Code | Code that allows for determination of internal architecture or design. | Unobfuscated code, Unsigned Executables |
Code obfuscation (shrouding), Digitally signing code |
| E | Elevated Privileges Required to Run | Code that violates the principle of least privilege. | Administrative accounts | Environment configuration, Code set explicitly to run with least privilege |
A short and simple update that if you’re looking to get to grips with Fuse development using C++ a great starting point is:
http://code.google.com/p/fuse-examplefs/