amuck-landowner

DrServer XEN 128MB (TX)

wlanboy

Content Contributer
Provider: DrServer - Ninja branch
Plan: XEN 128 MB VPS
Price: 1.85€ per month
Location: Dallas, US

Purchased: 10/2014

This is one of the reviews that are sponsored by vpsboard.

I will update each review every two months and will add notes on what happend during this time.

MannDude is funding the reviews and we are randomly selecting providers and test their service, their panels and their support.

If you want to discuss about this topic -> start here.

So back to the review of DrServer.

Hardware information:

  • cat /proc/cpuinfo

    processor : 0
    vendor_id : GenuineIntel
    cpu family : 6
    model : 45
    model name : Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz
    stepping : 7
    microcode : 0x70b
    cpu MHz : 2000.038
    cache size : 15360 KB
    physical id : 1
    siblings : 1
    core id : 2
    cpu cores : 1
    apicid : 37
    initial apicid : 37
    fdiv_bug : no
    f00f_bug : no
    coma_bug : no
    fpu : yes
    fpu_exception : yes
    cpuid level : 13
    wp : yes
    flags : fpu de tsc msr pae cx8 apic sep cmov pat clflush mmx fxsr sse sse2 ss ht nx constant_tsc eagerfpu pni pclmulqdq ssse3 sse4_1 sse4_2 popcnt tsc_deadline_timer aes xsave avx hypervisor arat epb xsaveopt pln pts dtherm
    bogomips : 4000.07
    clflush size : 64
    cache_alignment : 64
    address sizes : 46 bits physical, 48 bits virtual
    power management:

  • cat /proc/meminfo
    Code:
    MemTotal:         117676 kB
    MemFree:           12156 kB
    Buffers:            6760 kB
    Cached:            51896 kB
    SwapCached:         7176 kB
    Active:            36272 kB
    Inactive:          44208 kB
    Active(anon):       3236 kB
    Inactive(anon):    18620 kB
    Active(file):      33036 kB
    Inactive(file):    25588 kB
    Unevictable:           0 kB
    Mlocked:               0 kB
    HighTotal:             0 kB
    HighFree:              0 kB
    LowTotal:         117676 kB
    LowFree:           12156 kB
    SwapTotal:        131068 kB
    SwapFree:         118728 kB
    Dirty:                 0 kB
    Writeback:             0 kB
    AnonPages:         19276 kB
    Mapped:             5384 kB
    Shmem:                32 kB
    Slab:              14640 kB
    SReclaimable:       8728 kB
    SUnreclaim:         5912 kB
    KernelStack:        1088 kB
    PageTables:          752 kB
    NFS_Unstable:          0 kB
    Bounce:                0 kB
    WritebackTmp:          0 kB
    CommitLimit:      189904 kB
    Committed_AS:      96768 kB
    VmallocTotal:     724984 kB
    VmallocUsed:        2752 kB
    VmallocChunk:     713580 kB
    HardwareCorrupted:     0 kB
    AnonHugePages:         0 kB
    HugePages_Total:       0
    HugePages_Free:        0
    HugePages_Rsvd:        0
    HugePages_Surp:        0
    Hugepagesize:       2048 kB
    DirectMap4k:      139264 kB
    DirectMap2M:           0 kB
  • dd
    Code:
    dd if=/dev/zero of=test bs=16k count=8k conv=fdatasync && rm -rf test
    8192+0 records in
    8192+0 records out
    134217728 bytes (134 MB) copied, 7.5916 s, 17.7 MB/s
  • wget
    Code:
    wget cachefly.cachefly.net/100mb.test -O /dev/null
    --2014-10-24 19:40:02--  http://cachefly.cachefly.net/100mb.test
    Resolving cachefly.cachefly.net (cachefly.cachefly.net)... 205.234.175.175
    Connecting to cachefly.cachefly.net (cachefly.cachefly.net)|205.234.175.175|:80... connected.
    HTTP request sent, awaiting response... 200 OK
    Length: 104857600 (100M) [application/octet-stream]
    Saving to: â/dev/nullâ
    
    100%[===================================================================================>] 104,857,600 49.9MB/s   in 2.0s
    
    2014-10-24 19:40:04 (49.9 MB/s) - â/dev/nullâ saved [104857600/104857600]
Network:

traceroute dvhn.nl


2 109.208.68.208.static.ipv4.dnsptr.net (208.68.208.109) 0.242 ms 0.231 ms 0.223 ms
3 78.152.59.25 (78.152.59.25) 0.384 ms 0.854 ms 0.840 ms
4 eth1-4.core1.nyc1.us.as5580.net (78.152.34.149) 26.452 ms 26.980 ms 26.962 ms
5 eth1-5.core1.lon1.uk.as5580.net (78.152.44.134) 110.572 ms 111.308 ms 110.812 ms
6 eth1-1.r1.lon2.uk.as5580.net (78.152.44.163) 111.283 ms 123.083 ms 123.081 ms
7 linx-2602.ge-0-0-0.jun1.thn.network.bit.nl (195.66.237.51) 125.319 ms 125.303 ms 126.004 ms
8 805.xe-0-0-0.jun1.bit-1.network.bit.nl (213.136.1.105) 125.603 ms 125.940 ms 126.419 ms

traceroute theguardian.co.uk


2 109.208.68.208.static.ipv4.dnsptr.net (208.68.208.109) 0.653 ms 0.644 ms 0.654 ms
3 78.152.59.25 (78.152.59.25) 4.173 ms 4.520 ms 5.048 ms
4 te0-2-0-28.ccr21.ord03.atlas.cogentco.com (38.122.180.237) 1.259 ms 1.649 ms 1.640 ms
5 be2003.ccr42.ord01.atlas.cogentco.com (154.54.29.21) 1.953 ms 3.138 ms 1.915 ms
6 be2138.ccr22.bos01.atlas.cogentco.com (154.54.43.202) 32.327 ms be2137.ccr21.bos01.atlas.cogentco.com (154.54.43.194) 32.264 ms be2114.ccr41.jfk02.atlas.cogentco.com (66.28.4.201) 27.383 ms
7 be2394.ccr42.lon13.atlas.cogentco.com (154.54.30.170) 102.506 ms be2275.ccr41.lon13.atlas.cogentco.com (154.54.46.122) 101.528 ms be2394.ccr42.lon13.atlas.cogentco.com (154.54.30.170) 101.498 ms
8 be2494.ccr22.lon01.atlas.cogentco.com (154.54.39.129) 104.381 ms 102.368 ms be2350.ccr21.lon01.atlas.cogentco.com (154.54.39.186) 102.705 ms
9 te2-1.mag02.lon01.atlas.cogentco.com (154.54.74.114) 100.816 ms 102.289 ms 101.431 ms
10 149.11.142.74 (149.11.142.74) 104.682 ms 104.585 ms 101.390 ms

traceroute washingtonpost.com


2 109.208.68.208.static.ipv4.dnsptr.net (208.68.208.109) 0.673 ms 0.689 ms 0.671 ms
3 78.152.59.25 (78.152.59.25) 0.946 ms 1.446 ms 1.432 ms
4 te0-2-0-28.ccr21.ord03.atlas.cogentco.com (38.122.180.237) 3.011 ms 2.965 ms 2.943 ms
5 be2003.ccr42.ord01.atlas.cogentco.com (154.54.29.21) 2.026 ms be2005.ccr41.ord01.atlas.cogentco.com (66.28.4.73) 2.369 ms 2.033 ms
6 be2152.ccr21.dca01.atlas.cogentco.com (154.54.30.121) 31.468 ms be2153.ccr22.dca01.atlas.cogentco.com (154.54.30.125) 30.641 ms be2154.mpd21.dca01.atlas.cogentco.com (154.54.30.197) 30.483 ms
7 be2176.ccr41.iad02.atlas.cogentco.com (154.54.41.53) 31.716 ms 32.010 ms te0-5-0-1.rcr21.iad02.atlas.cogentco.com (154.54.31.182) 31.328 ms
8 te0-0-0-0.agr12.iad02.atlas.cogentco.com (154.54.44.202) 31.529 ms te0-0-0-0.agr11.iad02.atlas.cogentco.com (154.54.44.198) 31.737 ms 31.669 ms
9 te0-0-2-0.nr11.b037327-0.iad02.atlas.cogentco.com (154.24.15.62) 31.625 ms 31.607 ms 31.780 ms
10 38.88.158.2 (38.88.158.2) 31.042 ms 31.123 ms 31.098 ms
11 198.72.14.34 (198.72.14.34) 31.321 ms 31.278 ms 31.225 ms

What services are running?

  • Lighttpd + some static sites
  • Openvpn server

Support:

Needed some tickets because their system lost my paypal payment.

After that my vps was unusable for hours.

First time ever that starting nano took over one minute.

Logging into the vps took about 40 seconds.

First update of packages (apt-get update) took 7 minutes - more than 5 minutes for "Reading package lists... Done"

Their response was only "reinstall your vps".

Won't quote their responses on so called "simple questions".

If the node does have a good day the performance is still far away from snappy.

Overall experience:

  • Paypal issues
  • Slow provision
  • Bad performance
  • Bad I/O
  • Slow response times
  • Impolite support
I canceled the service after the first month.
 
Last edited by a moderator:

DomainBop

Dormant VPSB Pathogen
dd if=/dev/zero of=test bs=16k count=8k conv=fdatasync && rm -rf test8192+0 records in

8192+0 records out

134217728 bytes (134 MB) copied, 7.5916 s, 17.7 MB/s
Normally I'd ask if you tried changing the scheduler from cfq to noop because it can sometimes make a big difference in I/O performance, but if it was taking 40 seconds to SSH in and 1 minute to open nano I doubt if changing the scheduler would have helped much.
 

drmike

100% Tier-1 Gogent
Real bad numbers.  Especially the real world performance (i.e. apt-get 7 minutes, 40 seconds to log in via SSH, etc.).

They seem to be using big enough and recent CPU Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz....  probably a Dual E5.

So reasons for this subpar performance?  Misconfiguration of server?  or OverSold?

Not the first time I've seen slow stuff and random from drServer brands.  For some reason customers aren't posting such experiences on the other forum and the quarterly voting for them has me head scratching.

At 1.85 euros we are talking about $2.34 USD a month = $28.08 a year.

$28 a year is kind of hefty in the market for a 128MB VPS.

Guess I expect more, for less and with better general numbers and certainly on real world VPS experience.
 

wlanboy

Content Contributer
Their abilities to create brands are really good.

Nice theme, fresh name, all about Ninjas and XEN as a plattform ;)

But they do not look at the node if a customer states (with examples) that the node is overloaded.

Not even talking about page load times for plain html files (beyond 20 seconds).

I did not even tried redis - just lighttpd some html files and a openvpn server.

Compile times were the worst.

Even on overloaded vps compiling Ruby only lasted 8 to 10 minutes. On this vps it took 17 minutes.

At least I got a refund to test another provider,
 

wcypierre

New Member
To be honest, I also faced the same issues. I posted a comment about it at LET and got bombarded, connecting to SSH was slow, and doing things at SSH was slow as well. After having a server at GVH, I understand that it is a waste to put a support ticket so apparently I'm just using it to host something not important while waiting for time to pass(1 year)
 

k0nsl

Bad Goy
Yes, I've faced them all too - but the support has not been rude, or impolite. The PayPal issue happened several times.

I only use my 64MB "Ninja" for IRCd purposes, however, even for this purpose it has and is a "bumpy ride". Network connectivity is not good between the "Ninja node" and my BuyVM main IRC node, it constantly ping timeouts.

At any rate, it feels a little weird to complain about something that doesn't even cost me one dollar.
 

switsys

Active Member
I find it very difficult to believe that support would be 'impolite', at least if tickets were handled by the founder himself.
He's such an amazingly nice guy. But of course, anyone could have a bad day.
 
Last edited by a moderator:

drserver

Member
Verified Provider
Hi guys.

Thank you for review in any way.

Let me try to answer your questions.

Our servers are priced in USD, so 128 MB ninja is priced 1.85 USD

You are using storage njinja which is pure storage server. 

Ninja server range have best effort support and it uses community forum for support.

If you are unhappy in any way with service, you can get 100% refund with no questions asked.

About impolite support, please post ticket here, i would gladly handle my staff if anyone was impolite to you in any way.

@wcypierre Please take my deepest apologizes for any problems that you had with us. Also please point me where problem was. I am always looking to improve service in any way.

@k0nsl same thing, if we did something that is impolite rude or anything bad, please take my apologies.

Now about ninja range. That range is pure low end service with limited or no support. Dont mix it with our abusivecores, sugarvps or byteshack platform. 

ninja range have separate billing and support system.

Once again if you are unhappy with anything, you can get your refund with no questions asked or you can PM me if you have any problems with my staff i am always here if anyone needs anything. @k0nsl can witness that.

And last line, guys if anyone is offended take my deep apologies.
 

drserver

Member
Verified Provider
@swiftsys ninja tickets are handled by brad and radi, booth are great guys and this is strange situation.
 

drserver

Member
Verified Provider
Their abilities to create brands are really good.

Nice theme, fresh name, all about Ninjas and XEN as a plattform ;)

But they do not look at the node if a customer states (with examples) that the node is overloaded.

Not even talking about page load times for plain html files (beyond 20 seconds).

I did not even tried redis - just lighttpd some html files and a openvpn server.

Compile times were the worst.

Even on overloaded vps compiling Ruby only lasted 8 to 10 minutes. On this vps it took 17 minutes.

At least I got a refund to test another provider,
Hi,

Node is not overloaded in any way. I am not saying that we are not having abuse problems but CPU is capped fairly and CPU weight is distributed on fair scale. Bigger plans have bigger CPU time lower plans have lower CPU time. Once again as i said, if you are unhappy with any of our products, you can get refund with no questions asked. Storage VPS, very low end storage VPS... as i said once again i am sorry if this results / treatment / level of service is offending you in any way.
 

drserver

Member
Verified Provider
Real bad numbers.  Especially the real world performance (i.e. apt-get 7 minutes, 40 seconds to log in via SSH, etc.).

They seem to be using big enough and recent CPU Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz....  probably a Dual E5.

So reasons for this subpar performance?  Misconfiguration of server?  or OverSold?

Not the first time I've seen slow stuff and random from drServer brands.  For some reason customers aren't posting such experiences on the other forum and the quarterly voting for them has me head scratching.

At 1.85 euros we are talking about $2.34 USD a month = $28.08 a year.

$28 a year is kind of hefty in the market for a 128MB VPS.

Guess I expect more, for less and with better general numbers and certainly on real world VPS experience.
Hi please try to undersand, that is pure lowend brand, dirt cheap. server price is little less, and it is addition to other ninjas for storage (backup option) CPU cap is around 15% per core. I/O have lowest priority. You are free to test every server for 30 days and ask refund, nothing will happen, and you will get refunded. There are 0 of our clients who asked for refund and got denied.

super lowend brand, super capped core, storage only server, best effort support.
 

drmike

100% Tier-1 Gogent
Hi please try to undersand, that is pure lowend brand, dirt cheap. server price is little less, and it is addition to other ninjas for storage (backup option) CPU cap is around 15% per core. I/O have lowest priority. You are free to test every server for 30 days and ask refund, nothing will happen, and you will get refunded. There are 0 of our clients who asked for refund and got denied.

super lowend brand, super capped core, storage only server, best effort support.
Thanks for the clarification.

It's good to know what is expected performance regardless of price point. 

It puts a new spin on the whole review process in general.

Concerning the CPU cap, albeit 15% is low.  Why would @wlanboy have those massive delays?  Namely these:

First time ever that starting nano took over one minute.

Logging into the vps took about 40 seconds.

First update of packages (apt-get update) took 7 minutes - more than 5 minutes for "Reading package lists... Done"
It's my assumption that his container was idle when say logging into the VPS....

Nano is rather light and near instant loading even on a lowly ARM devices with slaggy SD card storage.

The delays to me don't indicate his use competing, but perhaps other contention the larger server.  (i.e. overloaded).
 

drserver

Member
Verified Provider
well there is only one way to clarify that, 

Node is consisted of 2xe5-2620, 128 GB RAM, 8x4 TB Drives + 2x120GB SSD in RAID6 configuration with SSD cache.

Node is not even on 50% capacity.

Now you will have to believe me what i am saying but i can also provide screens for everything that i am saying here:

In that particular time of the test i cannot say if there was any problems on the node. At this moment, with few customers more:

node is running 103 guests, around 45% ram is used, cpu usage globally didn't pass 35% and there is 0% of iowait.

There is nothing to hide here really, we are keeping everything transparent from day one.

What really surprises me is unpolite staff, i will check every ninja ticket personally to identify the problem. As you can see i really care about my clients and my services and especially my staff responses.
 

drserver

Member
Verified Provider
also one thing to add,

First time ever that starting nano took over one minute.

Logging into the vps took about 40 seconds.

First update of packages (apt-get update) took 7 minutes - more than 5 minutes for "Reading package lists... Done"

That is really bad i agree.
 

k0nsl

Bad Goy
@drserver you and your staff have been very good to me and always very polite 
thumbs-up-smiley01_k0nsl.gif


@k0nsl same thing, if we did something that is impolite rude or anything bad, please take my apologies.
 

wlanboy

Content Contributer
Want to add one note about "impolite".

There were no offensive words but a harsh short statement.

I always start my tickets with "hello" and end them with "thank you for your support".

I wanted to inform the provider that something is totally wrong and asked that they should have a look at their node.

Answer was just a "reinstall your vps!".

No "Hi", no "we will look into it", no "sorry for the trouble".
 

drserver

Member
Verified Provider
Want to add one note about "impolite".

There were no offensive words but a harsh short statement.

I always start my tickets with "hello" and end them with "thank you for your support".

I wanted to inform the provider that something is totally wrong and asked that they should have a look at their node.

Answer was just a "reinstall your vps!".

No "Hi", no "we will look into it", no "sorry for the trouble".
Thank you for clarification. After reviewing ticket i would say, not very helpfull, there is only one ticket with reinstall your vps content. So i am aware of situation now.

@wlanboy please take my apology for unprofessional ticket handling. I can assure you that it will not happen again. Also i can offer you free credit in compensation on any of our platforms. 

Thank you for understanding
 

drmike

100% Tier-1 Gogent
Node is consisted of 2xe5-2620, 128 GB RAM, 8x4 TB Drives + 2x120GB SSD in RAID6 configuration with SSD cache.

Node is not even on 50% capacity.

Now you will have to believe me what i am saying but i can also provide screens for everything that i am saying here:
Perhaps you folks are under SSH attempt attacks on the server and or containers in mass.  That's one cause of such login time performance issues, especially where waiting for the prompt to input credentials (if not running keyless setup).

Machine is beefy enough and underloaded from your specs.
 

drserver

Member
Verified Provider
Perhaps you folks are under SSH attempt attacks on the server and or containers in mass.  That's one cause of such login time performance issues, especially where waiting for the prompt to input credentials (if not running keyless setup).

Machine is beefy enough and underloaded from your specs.
we are monitoring that all the time for example live monitoring where lots of providers are participating http://honeypot.drserver.net:3000/ stay on page a minute and you will see what i am saying, we are filtering most of attacks from the beginning. When anyone gets on any of our subnets it will hit honeytrap and then we are able to filter attacker. Also i am inviting other providers who whish to join, we are always open to all possible ways of cooperation.

What is the issue in this case is following: CPU Weight. For some reason storage ninjas was provisioned with weight of 128, Other servers was with 512. That was problem. It is fixed now.
 
Top
amuck-landowner