Invision Community 4: SEO, prepare for v5 and dormant account notifications By Matt Monday at 02:04 PM
Jred Posted August 17, 2012 Posted August 17, 2012 I should this weekend move site into new dedi, so I would appreciate guidance here. I have been fine-tuning a lot, and lot more past few weeks and I'm bit lost on what should I expect performance to be. Now it's flying when compared to old server, but can't help wondering that is this all, or could it be more faster. Dedi: Dual-Core Intel 2,9Ghz 8 gig ram 2 x 250GB disks (sata2, but not sure), www-root is in second drive. Software: Debian 6 Nginx 1.2.3 php-fpm php 5.3.15 Apc 3.1.9 MySql 5.5.27 I have Varnish in front of the Nginx, but it's not configured properly yet, look into it later on, probably after server change. Now running ab -n 1000 -c 8 http:/localhost/index.php I get following results:Concurrency Level: 8Time taken for tests: 69.325 secondsComplete requests: 1000Failed requests: 497 (Connect: 0, Receive: 0, Length: 497, Exceptions: 0)Write errors: 0Total transferred: 134025497 bytesHTML transferred: 133710497 bytesRequests per second: 14.42 [#/sec] (mean)Time per request: 554.600 [ms] (mean)Time per request: 69.325 [ms] (mean, across all concurrent requests)Transfer rate: 1887.98 [Kbytes/sec] receivedConnection Times (ms) min mean[+/-sd] median maxConnect: 0 0 0.0 0 0Processing: 332 553 106.0 540 1499Waiting: 317 530 105.4 516 1490Total: 332 553 106.0 540 1499 Is this ok performance?
Grumpy Posted August 18, 2012 Posted August 18, 2012 Is this ok performance? Can't say. :P All forms of benchmark only have a meaning if the same benchmark is used elsewhere to compare. And I frankly never ran that test before and don't want to on a live site... Although things like ram and HD are of fairly predictable performance (feel like someone else is gonna scream), CPU isn't with the given information. A dual core of today's architecture at 2.9ghz will out perform an earliest dual core with 2.9ghz possibly as much as 10x in something complex like php. If it was an endless calculation of +1s... they'd do about the same. So, you actually need to say the name of the cpu, not just core count and speed.I have Varnish in front of the Nginx, but it's not configured properly yet, look into it later on, probably after server change. I would heavily heavily heavily discourage this. This is no different than doing nginx in front of nginx or varnish in front of varnish. It's a waste of processes, internal tcp connections, ram and source of many potential problems. Nginx has pretty much all the features varnish has and vice versa, just not with default settings. There is zero reason to use both at the same time.
Jred Posted August 18, 2012 Author Posted August 18, 2012 Is this ok performance? Can't say. :tongue: All forms of benchmark only have a meaning if the same benchmark is used elsewhere to compare. And I frankly never ran that test before and don't want to on a live site... Although things like ram and HD are of fairly predictable performance (feel like someone else is gonna scream), CPU isn't with the given information. A dual core of today's architecture at 2.9ghz will out perform an earliest dual core with 2.9ghz possibly as much as 10x in something complex like php. If it was an endless calculation of +1s... they'd do about the same. So, you actually need to say the name of the cpu, not just core count and speed. Yes, that's hard to tell and without all data even more so :) so processor is: Intel Pentium G850 I would heavily heavily heavily discourage this. This is no different than doing nginx in front of nginx or varnish in front of varnish. It's a waste of processes, internal tcp connections, ram and source of many potential problems. Nginx has pretty much all the features varnish has and vice versa, just not with default settings. There is zero reason to use both at the same time. I have thought about that too, and only reason why varnigh is front is that it support purge from url out of the box (well with proper config). But yes you're absolutely right about being able to do all that with nginx too (using headers for example), I actually have tried that already. Good with nginx is that you can do that per site config. Probably wiser to do it only with nginx. Thanks for your input.
Grumpy Posted August 18, 2012 Posted August 18, 2012 Given G850 isn't hyperthreaded, I think it might be more meaningful to a concurrency of something like 1, 2 and 3. I think giving it an 8 is a too much for the processor. 500ms in general is too slow imo. But, at the same time, it was a big load for the cpu. 1 concurrency should give you a great speed like 100ms avg. 2 is on max, but should still fair upto 150ms (still ideally 100ms). Beyond 2, you should start hitting slow speeds like 300ms+. If Which I personally find to be unacceptable. Though, again with disclaimer, using general knowledge on php render times instead of using IPB render times as I never really ran that bench before (and I don't really know what you have on index. :P) although I do have a lot of measures of IPB runtimes through different means. I think you should try concurrency 2 the most. Then get the req per sec number. That in combination of your user req per person per second of your site, should give a fair idea of how many people reading your current setup can hold. Anyway, with 1~2 conc. getting < 150ms is something I would deem "okay". Which translates to: what we should be able to run is running well. Basically my point is that I think you should control the variables so that you aren't at a problematic state, but at a maximum of an ideal state and then conclude if that request per second is of reasonable value to you. I think without comparable benches, that's really the only meaningful conclusive result we can gather. Though... some others may contribute their benches.
Recommended Posts
Archived
This topic is now archived and is closed to further replies.