Hi Kant,
You'll find more information about ixgbevf here
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sriov-networking.htmlI
repeat myself but don't underestimate VMs placement: same AZ? same placement
group? etc.Note that LWT are not discouraged but as the doc says: "[...]
reserve lightweight transactions for those situations where they are absolutely
necessary;"I hope you'll be able to achieve what you want with more powerful
VMs. Let us know!
Best,Romain
Le Lundi 6 mars 2017 10h49, Kant Kodali <k...@peernova.com> a écrit :
Hi Romain,
We may be able to achieve what we need without LWT but that would require bunch
of changes from the application side and possibly introducing caching layers
and designing solution around that. But for now, we are constrained to use
LWT's for another month or so. All said, I still would like to see the
discouraged features such as LWT's, secondary indexes, triggers get better over
time so it would really benefit users.
Agreed High park/unpark is a sign of excessive context switching but any ideas
why this is happening? yes today we will be experimenting with c3.2Xlarge and
see what the numbers look like and slowly scale up from there.
How do I make sure I install ixgbevf driver? Do M4.xlarge or C3.2Xlarge don't
already have it? when I googled " ixgbevf driver" it tells me it is ethernet
driver...I thought all instances by default run on ethernet on AWS. can you
please give more context on this?
Thanks,kant
On Fri, Mar 3, 2017 at 4:42 AM, Romain Hardouin <romainh...@yahoo.fr> wrote:
Also, I should have mentioned that it would be a good idea to spawn your three
benchmark instances in the same AZ, then try with one instance on each AZ to
see how network latency affects your LWT rate. The lower latency is achievable
with three instances on the same placement group of course but it's kinda
dangerous for production.
