New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Server and/or VPS burn in
pubcrawler
Banned
Generally tired of underperforming providers. So much time burnt doing quick inadequate testing, then the installs and moving data and configing things.
So in addition to the VPS test scripts like the one from freevps, what are other folks using to burn / test their new dedicated servers and VPS packages?
Looking for ideas or solutions others use that can be ran for a day or three all depending to eyeball various problem points (disk throughput, IOWAIT, CPU, bandwidth and routing).
Anyone have such a solution?
Comments
Um, testing disk and CPU for three days is a sure fire way to get yourself thrown out of most VPS providers unless you are specifically talking about dedicated?
Not sure what's with everyone doing tests, if the Server/VPS is fine for your real needs then no need to get horny/moan over high/low numbers.
How much were you paying and what sort of performance were you expecting?
Well price is the slightest concern truly. This applies to all offerings, although providers will see obvious problems with it (i.e. abuse concerns).
The concern is stability, predictability and performance ranges [min, max and average].
A number of providers are "fine" day one. Often it's until a node is filled or a promo is ran. Then things go apesh!t nuts.
Concept is pre-move-in burn in of sorts. But not 100% of the time, tiered, random, multiple times over period.
Long term it's a weekly thing to repeat process and stash the numbers for comparatives and see what is out of expected ranges.
It's part testing and part monitoring in essence. Disk IO, CPU, bandwidth and latency of those three.
This would be a case where a provider offering public graphs would be a good idea. I've considered it, it's just that most people don't know what they're looking at. Contributing to server load doesn't tell you what you really want to know.
True to that @jarland.
Most providers won't public post graphs because it shows snafus they like to hide.
Unknowing customers, well, ideally what they don't know won't hurt them. Come first outage they'll be moaning.
I am often reminded of the stability of the lowly landline phone even when it cost next to nothing. Proper engineering and redundancy go a super long way.
Nothing to hide here
jarland.me/munin
Pretty graphs there
@jarland. Lots of monitoring on those. Head spin amount.
Ever have any known issues with having the node hostnames 'on display'? I've considered making our Munin install public, but I get freaked out about having all of the host names just listed.
I'd consider scouring the hostnames out. A simple internal server ID or name will suffice.
Haven't much thought about it. Truthfully I've never linked that to anyone before
Paranoia from the malicious hacktards and the legions of desktop researchers.
There we go
easy: don't subscribe to no name ridiculously cheap bs hosts. if you're concerned about performance, go with the big names and don't fk around
Big names don't guarantee performance @fly. General concept painted with that brush might end up with less of a Picasso and more a finger painting.
2 of the 4 top big names had big outages in 2013
Anyone, regardless of size can have an outage and almost all providers will have some sort of outage. It happens.
In my eyes its more about how they handle problems than having a spotless record. Of course if a provider has multiple outages in the span of a few months, then that indicates a much bigger issue that's not being addressed.
It's not so much about outage as determining their selling practices. Day one is almost always good with a new provider. What you want to know is how performance will continue to run. I think public graphs are the answer to that. If everyone is testing the hardware it's just not going to provide a realistic example of how elastic your vps is when you get a big spike in traffic. What you really want to know is just how much wiggle room you have. Graphs answer that question.
I propose public graphs, and I toss my hat in that ring.
@jarland I think that's pretty commendable. I've looked at the link you posted and its quite extensive. How much load does that put on the systems to collect?
@jbxl Honestly not much. Munin may, at most, cap a single CPU core for 2 seconds every time it runs. My opinion is that if this causes a problem I've missed my mark.
Thanks. This thread is a good topic for me right now as I'm looking at options for monitoring. Munin is one solution I was looking at.
What I like about munin is that it's simple. I had some trouble understanding it in the beginning, because I went straight to the munin website and I think they overcomplicate the documtation.
Here's what made sense of it for me:
http://articles.slicehost.com/2010/3/12/installing-munin-on-centos
I run threshold alerts on the values that matter the most to me and I set it to e-mail and text me (email #@mobile.att.net I think) when a value goes over the threshold. I set them kind of low so it happens a lot, but I'd rather wake up and look at things than risk bad performance.
I think good monitoring and alerts are absolutely key, and your clients will be thrilled to know that they can sleep at night.
Plan to offer a public statistics chart soon, decided to develop it In house so it may take some time.
I'm a sucker for a good UI
I think it's a great solution to the frequent benchmarks.
I use siege to test for 1 minute or 2
@jarland I really like the detailed status information. I've always been a sucker for good graphs.
You are not concerned about giving away information about the nodes/loading?
It's definitely giving me some food for thought as maybe its not as much a concern as I thought it was. I mean, if I was a customer I'd definitely appreciate the information.
@jcaleb That tests HTTP connections/loading correct?
Yes, correct. I test both with caching and no caching. To get a feel of it
@jbxl I'm not too worried. Honestly if anything my standards are too high for performance, so I don't expect people to be questioning if there's enough left to work with. Capacity isn't given away very well as the openvz plugin is flawed. Probably going to disable it.
I like the bold move @jarland made with this. I doubt the mass oversell companies would ever do such a thing for many obvious reasons.
It certainly is a way to differentiate value providers from plain old lowend providers.
If I were @jarland, I'd start making these available upside the offers --- in the offer body. Show people beyond goofy tech-nerd node specs what they are buying into. Plenty of resources available. Truly nowhere near oversold.