Server Performance

1,143 Views

Morgan has asked me to do some testing on our servers performance to show to our clients. This blog post will contain the results. All test were performed from a Rackspace Cloud Server in the Chicago datacenter to give a bit of distance from our DFW servers.

Network Latency

The first thing we need to know, is how long does it take internet traffic to get to our servers and back. This is greatly variable on the end users geographic location. To connect to our web servers your web browser must make at least two round trips to the server to start getting the page. One to set up the connection, and one to get the page.

Using the standard network tool ping I ran a test from my test server to one of our web servers.

# ping -c 100 rewhosting.com
--- rewhosting.com ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 99188ms
rtt min/avg/max/mdev = 22.791/23.353/26.211/0.475 ms

So from this we can see all future test will be at least 23ms long. ms is milisecond, there are 1000 in a second.

DNS Timing

The next thing to test is our DNS server speed. DNS is normally cached by your local ISP for you and makes for very quick lookups if they already know the answer. But in a worst case, they will need to hit one of our DNS servers.

I wrote a little script to do a DNS lookup 100 times at each of our nameservers and report the results. NS2 is a little closer to my Chicago test server, and so is a bit faster than the base ping time above,

NS1.REWHOSTING.COM
Min: 22ms
Avg: 26.8ms
Max: 32ms

NS2.REWHOSTING.COM
Min: 18ms
Avg: 19.3ms
Max: 25ms

Apache Speed

Now lets test the speed of Apache serving a basic HTML page. Each of our servers has a page available at its IP address. EG: http://67.192.180.100/

For this I will use a tool called ab, the Apache HTTP server benchmarking tool. I set ab to make 10 requests at a time, and make 1000 requests total per server.

pic2.rewhosting.com Time per request:       54.472 [ms] (mean)
pic3.rewhosting.com Time per request: 55.465 [ms] (mean)
pic4.rewhosting.com Time per request: 62.660 [ms] (mean)
web6.rewhosting.com Time per request: 54.575 [ms] (mean)
web9.rewhosting.com Time per request: 54.516 [ms] (mean)
web11.rewhosting.com Time per request: 54.958 [ms] (mean)
web12.rewhosting.com Time per request: 66.611 [ms] (mean)
web14.rewhosting.com Time per request: 54.632 [ms] (mean)
web15.rewhosting.com Time per request: 57.359 [ms] (mean)
web16.rewhosting.com Time per request: 54.773 [ms] (mean)
web17.rewhosting.com Time per request: 55.056 [ms] (mean)
web18.rewhosting.com Time per request: 54.678 [ms] (mean)
web19.rewhosting.com Time per request: 55.496 [ms] (mean)
web20.rewhosting.com Time per request: 54.605 [ms] (mean)
web21.rewhosting.com Time per request: 55.066 [ms] (mean)
web23.rewhosting.com Time per request: 56.577 [ms] (mean)
web24.rewhosting.com Time per request: 54.674 [ms] (mean)
web25.rewhosting.com Time per request: 54.792 [ms] (mean)
web-42-01.rewhosting.com Time per request: 56.531 [ms] (mean)
web-42-02.rewhosting.com Time per request: 54.931 [ms] (mean)
web-42-03.rewhosting.com Time per request: 55.378 [ms] (mean)
web-42-04.rewhosting.com Time per request: 55.128 [ms] (mean)
web-42-05.rewhosting.com Time per request: 56.488 [ms] (mean)
web-42-06.rewhosting.com Time per request: 55.442 [ms] (mean)
web-42-07.rewhosting.com Time per request: 60.630 [ms] (mean)
web-42-08.rewhosting.com Time per request: 55.098 [ms] (mean)
web-42-09.rewhosting.com Time per request: 56.310 [ms] (mean)
web-42-10.rewhosting.com Time per request: 54.790 [ms] (mean)
web-42-11.rewhosting.com Time per request: 54.379 [ms] (mean)
web-42-12.rewhosting.com Time per request: 54.211 [ms] (mean)
web-42-13.rewhosting.com Time per request: 54.264 [ms] (mean)

IDX Images CDN

I'll again use ab to test the speed of the CDN used for IDX Photos. This is powered by Akamai and Rackspace.

The image used in this test is from a Calgary condo. https://9b00cf3e94b1da815385-784ad96279f01dfaf51af989e8f8f0cf.ssl.cf1.rackcdn.com/c3644659-condo-townhouse-1cnzw34-o.jpg

Akamai has edge locations for its CDN all over the place, so there is likely one very close to you. Again, I'm testing from a Cloud Server in Chicago.

Time per request:       26.621 [ms] (mean)

Comments

Enjoy this post? Why not share with friends or add a comment of your own?

Marc Rasmussen

Great topic. Thank you.

I am on an old backend but updating to 4.3 shortly. I have a large database of leads that not only slows down the backend but also the frontend. I hear those that have large databases on 4.3 are experiencing same slow speed.

I have agents using the backend all day. When they make a query it can take several minutes before we get results. The problem is that during the backend query the front end is also unresponsive. The front end won't show the site until the backend is done with the query. Follow? Fixable?

I'm thinking this might be a better question for the forum vs this blog post. ;-)

Morgan Carey

Marc, that is a completely separate issue from server speed - however this post is part of a larger test / improvement program going on whereby we are attempting to test (and where necessary) improve speed / performance of all facets. This topic is "servers" - so that we can get a baseline with the goal to be able to say "yup, our servers are plenty fast, let's move onto the next thing" (of course, if they are not, we will make changes until they are, I have asked Steven to be fully transparent). Then once servers is removed as any potential "culprit" for speed issues, we can move onto other parts such as "front end" and "backend" (which again are two separate tests)

Is 4.3 (though you should be moving to 4.5) faster than previous versions? Yes I believe so - huge queries on the backend will still take a lot of time no matter what you do (it even takes google a long time to search years worth of data at 500 results per page and they have the best code around) - so there are code improvements (some have been made, there are likely lots more we can and will do) but you also need to adopt some best practices such as.

Limit your searches on leads to "just" what it really makes sense to target
Keep results to 10 per page
Run reports at non peak traffic times (during peak times you should be calling leads! ;)

Things like that - again, this one is about servers, but we will be covering backend and front end as well - thanks for your feedback.


Morgan Carey

Steven this begs the question - "what is acceptable" - I mean sure, we can report our speeds - but can we do some studies of response times of other servers out there in the world? - but perhaps a list vendors out there? (I'll give you a list, please request via PM on Monday)

REW Steven

@Marc Our code uses sessions to keep track of your logged in state and some other info about you. Sessions however need to be serialized (only one page at a time) to ensure they stay consistent. We can't have two pages loading at the same time doing different things to the session data. This is just built in to PHP.

So when you are doing a slow page in the backend, your browser can't load another page until that one finishes. This only affects you and your one session. If you open up your site in another browser or just incognito mode, you'll have a separate session and can load pages again.

Marc Rasmussen

Thank you Steven. That makes me feel better. ;-)

Share your thoughts…