"""
In case the number of tomcat threads and acceptCount values are set to be too high, a sudden increase in traffic will fill up the OS queues and make all the worker threads busy. When more requests than that can be handled by the system are sent to the machines, this "queuing" of requests is inevitable and will lead to increased busy threads, causing cpu starvation eventually. Hence, the crux of the solution is to avoid too much queuing of requests at multiple points (OS and tomcat threads) and fail fast (return http status 503) as soon the application's maximum capacity is reached. Here is a recommendation for doing this in practice:

Fail fast in case the system capacity for a machine is hit.
"""

Comme on a aucune idée de connaitre les perfs disque et réseau des instances ec2 (sauf en testant par soi-même), certains on fait des benchs.
Les résultats de ces benchs, qui testent les perfs réseau, montrent qu'on a intérêt à faire attention dans les choix d'instance....
"""
In our experiment we saw that the network performance of m1.large was lower than that of m1.medium. As per AWS documentation, the network performance of both m1.medium and m1.large is ‘moderate’ so we expected it to be similar. We also see that the network bandwidth of m3.medium is less than that of m1.small even though AWS documentation says that the network performance m3.medium is ‘moderate’ while that of m1.small is ‘low’. Network performance often depends on various scenarios like the network load on the actual hardware on which the VM is running. This might be a possible reason for this anomaly.
"""

voir aussi https://jeekajoo.eu/links/?GblCKw pour des comparaisons perf cpu/mem/disk

"""
By using this tool you can easily spot disk bottlenecks, measure the IO subsystem and identify how much IOPS your drive can handle (i.e. disk capacity).
"""
encore un bon outil signé percona.
cet outil fait parti de percona-toolkit: http://www.percona.com/software/percona-toolkit
license: GNU GPL v2