Hi Willy > Overall we could say that you have 2ms RTT in HTTP if we use foo.html as a > reference. That's equivalent to a 200km WAN link. The positive point is that > you would not lose anything more by making it geographically redundant :-)
:) I will have our network people look at that…. >>> Also you can try with ab -k in a second test (keep-alive) which will save >>> you from connection setup times. It will save two round trips per request, >>> one of which appears in the measure. On a sane local server, you should >>> almost not notice the difference. Here I already expect a difference. >> >> again: from a physical host: >> >> ab -c 8 -n 500 "https:/example.com/foo.php" >> Time per request: 36.914 [ms] (mean) > > I seem to remember that ab renegociates SSL for every connection. I may be > wrong but that's what I had in mind, so possibly you're benchmarking the > worst case (new client for each connection) which is always important to > determine. > >> ab -kc 8 -n 500 "https:/example.com/foo.php" >> Time per request: 36.833 [ms] (mean) > > Seems strange that these are the same numbers, because once the connection > is established, it should remain fast. Did ab report that it used keep-alive ? > It's also possible that for any reason the connection was closed after each > response. My colleague Simon found the "option httpclose" in the configuration. Removing that changes things for html but not for php: ab -c 8 -n 5000 "https://example.com/foo.html"; Requests per second: 238.83 [#/sec] (mean) Time per request: 33.497 [ms] (mean) ab -kc 8 -n 5000 "https://example.com/foo.html"; Requests per second: 2035.50 [#/sec] (mean) Time per request: 3.930 [ms] (mean) Progress! ab -c 8 -n 5000 "https://example.com/foo.php"; Requests per second: 223.16 [#/sec] (mean) Time per request: 35.849 [ms] (mean) ab -kc 8 -n 5000 "https://example.com/foo.php"; Requests per second: 223.52 [#/sec] (mean) Time per request: 35.791 [ms] (mean) No progress :( >> this is infrastructure we are building and providing ourselves: The load >> balancing VM is on a host that has 9 VMs running (33 virtual CPUs) on a >> system with 24 real cores. > > OK if you're building it yourself, at least you won't be victim of your > provider's choices nor of noisy neighbours. That said, as you can see, > making 33 virtual CPUs out of 24 real ones necessarily means you add a > lot of latency because you need to schedule between them and you can't > offer less than a timeslice (generally 1ms, but could even be 10). of course - we are aware of that. However, most (all) of the VMs have very very light loads > > >> The VM of the load balancer currently is configured with 8 vCPUs and 16GB of >> RAM. > > You can safely remove 6 CPUs that you will probably never use. If you could > dedicate 2 real cores instead (one for the interrupts, one for haproxy), it > would be much more efficient because there would be only full time slices. changed the VM type. Will see if I can pin it to 2 real CPUs > HAProxy does not use *any* I/O once started. It does not even have this > possibility. It will only use network, CPU and memory. I figured as much >> Ah - we are not selling this - does that make us less dishonest? :) > > :-) > You can tune whatever you want if you have control over everything, which > is good. Most cloud users do not have this chance and only have the option > to leave and try another one which is less overloaded. But with todays > dedicated hosting prices, it makes no sense to be hosted outside on VMs, > it's only seeking trouble. Well - we are building a cloud service, and the application we are putting on this Cloud now is a test case to see how things work and scale. (That's one of the reasons I came here asking for advice - I still need to establish base line performance for a lot of components and applications in order to tune the system). Right now I feel like I'm playing "Whack a Mole" but blindfolded. Of course it doesn't help that the application we putting into production in a few months time seems to be written by people that thought that 3 users on their system already was a lot. We are looking to scale it to 50'000 users… The WTF rate / minute is quite high as I try to scale it (the 60ms for the status.php is just the beginning… I have seen requests that took 390'000 ms - because the app goes out and updates several thousand files and corresponding database entries on the main thread…. sigh) Back to whacking, it is - and thanks for your inputs. Highly appreciated! cheers Jens-Christian
signature.asc
Description: Message signed with OpenPGP using GPGMail
