Page 1 of 2 12 LastLast
Results 1 to 40 of 53
  1. #1
    Join Date
    Dec 2009
    Posts
    60

    StyleXnetworks review - Terrible.

    Hello,

    I rarely post negative reviews because with the amount of competition I can just cancel and go elsewhere. But StyleXNetwork is so terrible I just had to speak up.

    I don't just run benchmarks all day looking for problems. I use this VPS for a few things and I notice problems with performance which makes me investigate.

    I have been a customer since June of 2012 (I paid for 6 months and renewed it once that is why I have not cancelled yet)

    ------
    Invoice 201206XXX
    Date of Invoice 21/06/2012
    Due Date 21/06/2012
    -------

    The Plan:
    Single Core
    256MB of memory
    10GB Disk (1GB of which is forced as swap which is fine though would be nice to use a bit less for swap)

    The problems:
    -Poor Disk IO. This is the biggest problem. 10-20 IOPS and 5-50MB/s disk write (50 is fine if it was consistent)
    -Server randomly gets shutdown and does not come back up unless you boot it up from within the panel.
    -Support (see below)
    -Network unstable. Month by Month this VPS sits at 95%-96% uptime according to both pingdom and StatusCake.

    Support:

    Useless. You open a ticket and they blame you right away.

    For the VPS being shut down all the time they claimed I hit reboot using the control panel and that it got "locked" I have never rebooted this VPS since I got it except from within the vps itself using the reboot command. I tried explaining that to them and they come right back saying the exact same thing. It is like a robot is answering your tickets using a keyword search in your ticket.

    As for the performance problems with IO I have been told various stories. From the fact the SAN is junk and they are replacing it to the fact that it is a problem with my VPS. Sometimes they will provide the same test from the node showing decent results and I try it and it is fine for a while. So obviously they fixed it but instead of just saying it they pretend like nothing happened.

    Some Example tests done at random times:

    ./ioping -c 10 .
    4096 bytes from . (ext3 /dev/xvda1): request=1 time=0.3 ms
    4096 bytes from . (ext3 /dev/xvda1): request=2 time=32.5 ms
    4096 bytes from . (ext3 /dev/xvda1): request=3 time=50.5 ms
    4096 bytes from . (ext3 /dev/xvda1): request=4 time=0.5 ms
    4096 bytes from . (ext3 /dev/xvda1): request=5 time=0.0 ms
    4096 bytes from . (ext3 /dev/xvda1): request=6 time=0.5 ms
    4096 bytes from . (ext3 /dev/xvda1): request=7 time=0.4 ms
    4096 bytes from . (ext3 /dev/xvda1): request=8 time=610.7 ms
    4096 bytes from . (ext3 /dev/xvda1): request=9 time=50.7 ms
    4096 bytes from . (ext3 /dev/xvda1): request=10 time=0.7 ms

    --- . (ext3 /dev/xvda1) ioping statistics ---
    10 requests completed in 9748.7 ms, 13 iops, 0.1 mb/s
    min/avg/max/mdev = 0.0/74.7/610.7/179.8 ms

    ./ioping -c 10 .
    4096 bytes from . (ext3 /dev/xvda1): request=1 time=0.3 ms
    4096 bytes from . (ext3 /dev/xvda1): request=2 time=0.5 ms
    4096 bytes from . (ext3 /dev/xvda1): request=3 time=2.8 ms
    4096 bytes from . (ext3 /dev/xvda1): request=4 time=433.6 ms
    4096 bytes from . (ext3 /dev/xvda1): request=5 time=0.5 ms
    4096 bytes from . (ext3 /dev/xvda1): request=6 time=0.4 ms
    4096 bytes from . (ext3 /dev/xvda1): request=7 time=1.1 ms
    4096 bytes from . (ext3 /dev/xvda1): request=8 time=0.4 ms
    4096 bytes from . (ext3 /dev/xvda1): request=9 time=0.4 ms
    4096 bytes from . (ext3 /dev/xvda1): request=10 time=0.9 ms

    --- . (ext3 /dev/xvda1) ioping statistics ---
    10 requests completed in 9442.7 ms, 23 iops, 0.1 mb/s
    min/avg/max/mdev = 0.3/44.1/433.6/129.8 ms


    Conclusion: Poorly managed, Poor support, VERY slow nodes and SAN. I will never use them again, I would suggest you go with a 1 month test run before putting anything into production.

    I provided my root password to them and they said they would escalate to an engineer. They closed the ticket. When I reopened the ticket here is the response I received:

    -------------------
    The ticket get closed automatically we are sorry for that ,
    however regarding your IO problem your package is limited resources and if there is a load you automatically get throttled on CPU which cause the IO problem , We highly recommend that you upgrade to one of our normal packages,
    -------------------

    My cpu usage is 0.00 to 0.07 so I can't see this being a factor.


    I am cancelling and moving on. I just wanted to post this here in the hopes no one else falls for this junk.

  2. #2
    Quote Originally Posted by luma View Post
    Hello,

    I rarely post negative reviews because with the amount of competition I can just cancel and go elsewhere. But StyleXNetwork is so terrible I just had to speak up.

    I don't just run benchmarks all day looking for problems. I use this VPS for a few things and I notice problems with performance which makes me investigate.

    I have been a customer since June of 2012 (I paid for 6 months and renewed it once that is why I have not cancelled yet)

    ------
    Invoice 201206XXX
    Date of Invoice 21/06/2012
    Due Date 21/06/2012
    -------

    The Plan:
    Single Core
    256MB of memory
    10GB Disk (1GB of which is forced as swap which is fine though would be nice to use a bit less for swap)

    The problems:
    -Poor Disk IO. This is the biggest problem. 10-20 IOPS and 5-50MB/s disk write (50 is fine if it was consistent)
    -Server randomly gets shutdown and does not come back up unless you boot it up from within the panel.
    -Support (see below)
    -Network unstable. Month by Month this VPS sits at 95%-96% uptime according to both pingdom and StatusCake.

    Support:

    Useless. You open a ticket and they blame you right away.

    For the VPS being shut down all the time they claimed I hit reboot using the control panel and that it got "locked" I have never rebooted this VPS since I got it except from within the vps itself using the reboot command. I tried explaining that to them and they come right back saying the exact same thing. It is like a robot is answering your tickets using a keyword search in your ticket.

    As for the performance problems with IO I have been told various stories. From the fact the SAN is junk and they are replacing it to the fact that it is a problem with my VPS. Sometimes they will provide the same test from the node showing decent results and I try it and it is fine for a while. So obviously they fixed it but instead of just saying it they pretend like nothing happened.

    Some Example tests done at random times:

    ./ioping -c 10 .
    4096 bytes from . (ext3 /dev/xvda1): request=1 time=0.3 ms
    4096 bytes from . (ext3 /dev/xvda1): request=2 time=32.5 ms
    4096 bytes from . (ext3 /dev/xvda1): request=3 time=50.5 ms
    4096 bytes from . (ext3 /dev/xvda1): request=4 time=0.5 ms
    4096 bytes from . (ext3 /dev/xvda1): request=5 time=0.0 ms
    4096 bytes from . (ext3 /dev/xvda1): request=6 time=0.5 ms
    4096 bytes from . (ext3 /dev/xvda1): request=7 time=0.4 ms
    4096 bytes from . (ext3 /dev/xvda1): request=8 time=610.7 ms
    4096 bytes from . (ext3 /dev/xvda1): request=9 time=50.7 ms
    4096 bytes from . (ext3 /dev/xvda1): request=10 time=0.7 ms

    --- . (ext3 /dev/xvda1) ioping statistics ---
    10 requests completed in 9748.7 ms, 13 iops, 0.1 mb/s
    min/avg/max/mdev = 0.0/74.7/610.7/179.8 ms

    ./ioping -c 10 .
    4096 bytes from . (ext3 /dev/xvda1): request=1 time=0.3 ms
    4096 bytes from . (ext3 /dev/xvda1): request=2 time=0.5 ms
    4096 bytes from . (ext3 /dev/xvda1): request=3 time=2.8 ms
    4096 bytes from . (ext3 /dev/xvda1): request=4 time=433.6 ms
    4096 bytes from . (ext3 /dev/xvda1): request=5 time=0.5 ms
    4096 bytes from . (ext3 /dev/xvda1): request=6 time=0.4 ms
    4096 bytes from . (ext3 /dev/xvda1): request=7 time=1.1 ms
    4096 bytes from . (ext3 /dev/xvda1): request=8 time=0.4 ms
    4096 bytes from . (ext3 /dev/xvda1): request=9 time=0.4 ms
    4096 bytes from . (ext3 /dev/xvda1): request=10 time=0.9 ms

    --- . (ext3 /dev/xvda1) ioping statistics ---
    10 requests completed in 9442.7 ms, 23 iops, 0.1 mb/s
    min/avg/max/mdev = 0.3/44.1/433.6/129.8 ms


    Conclusion: Poorly managed, Poor support, VERY slow nodes and SAN. I will never use them again, I would suggest you go with a 1 month test run before putting anything into production.

    I provided my root password to them and they said they would escalate to an engineer. They closed the ticket. When I reopened the ticket here is the response I received:

    -------------------
    The ticket get closed automatically we are sorry for that ,
    however regarding your IO problem your package is limited resources and if there is a load you automatically get throttled on CPU which cause the IO problem , We highly recommend that you upgrade to one of our normal packages,
    -------------------

    My cpu usage is 0.00 to 0.07 so I can't see this being a factor.


    I am cancelling and moving on. I just wanted to post this here in the hopes no one else falls for this junk.
    I apologize for the inconvenience, do you have a ticket # I can refer to?

  3. #3
    I went ahead and reviewed as many tickets as I could within the past 24 hours and I came across your ticket.

    To begin with your machine has limited resources with extremely low CPU priority. This is the main cause of your machine's performance issues in addition to other factors such as your machine's configuration, etc that could be causing this. I have attached 2 graphs showing your CPU usage. Currently your plan has only 1 core and 2% priority. Given the CPU specs of your plan your CPU usage is way too high, therefore effecting your performance.

    A test done on the same Hypervisor you are on, even though it does not matter which Hypervisor as they are all connected to a SAN storage:

    dd if=/dev/zero of=test bs=1M count=512 conv=fdatasync;rm -rf test
    512+0 records in
    512+0 records out
    536870912 bytes (537 MB) copied, 3.93224 seconds, 137 MB/s

    /root/ioping-0.6/ioping -c 10 .
    4096 bytes from . (ext3 /dev/root): request=1 time=0.3 ms
    4096 bytes from . (ext3 /dev/root): request=2 time=0.5 ms
    4096 bytes from . (ext3 /dev/root): request=3 time=0.6 ms
    4096 bytes from . (ext3 /dev/root): request=4 time=1.0 ms
    4096 bytes from . (ext3 /dev/root): request=5 time=0.5 ms
    4096 bytes from . (ext3 /dev/root): request=6 time=0.5 ms
    4096 bytes from . (ext3 /dev/root): request=7 time=0.5 ms
    4096 bytes from . (ext3 /dev/root): request=8 time=0.4 ms
    4096 bytes from . (ext3 /dev/root): request=9 time=0.5 ms
    4096 bytes from . (ext3 /dev/root): request=10 time=1.0 ms

    --- . (ext3 /dev/root) ioping statistics ---
    10 requests completed in 9037.9 ms, 1756 iops, 6.9 mb/s
    min/avg/max/mdev = 0.3/0.6/1.0/0.2 ms


    Whenever there is an issue reported, our engineers always check everything on a global level. They check the Hypervisors, SAN storage, network, etc. If they do find something on a global level that is effecting performance, they have no issue admitting it. The next step would be to check the machine it self that is having performance issues.

    Let me say that the above results that you are getting are terrible, if this was a global issue we would have had more than one customer contact us and complain. In this case you are the only one.

    At this point you were not cooperating with the engineer and constantly arguing back and forth and would not give him access to your machine.

    When you did grant us access to your machine, you were being rude and sarcastic towards our staff.

    In regards to the ticket closing, the second engineer that took over had left the ticket's status as answered which caused the ticket to close automatically when the cron ran. I fully take responsibility for this and I apologize.

    However if you are contacting us for assistance, arguing with the engineer will only delay the troubleshooting process and make things much more complicated.
    Attached Thumbnails Attached Thumbnails Screen Shot 2013-04-25 at 1.39.49 PM.png  

  4. #4
    Join Date
    Dec 2009
    Posts
    60
    So to update this thread.

    The CEO replied to my ticket (and to this post) indicating that I am using too much cpu.

    The funny thing is my VPS is Idle. It is no longer running ANYTHING. No services are running on it. It is a clean install of Debian 6.0 32bit.

    14:24:37 up 5 days, 16:12, 1 user, load average: 0.00, 0.00, 0.00


    Yet according to the CEO this is too much. And I am abusing the service.

    So there you have it. StyleXNetwork. Great for letting a VPS idle all day but that is it.
    Last edited by luma; 04-25-2013 at 03:30 PM.

  5. #5
    Quote Originally Posted by luma View Post
    So to update this ticket.

    The CEO replied to my ticket (and to this post) indicating that I am using too much cpu.

    The funny thing is my VPS is Idle. It is no longer running ANYTHING. No services are running on it. It is a clean install of Debian 6.0 32bit.

    14:24:37 up 5 days, 16:12, 1 user, load average: 0.00, 0.00, 0.00


    Yet according to the CEO this is too much. And I am abusing the service.

    So there you have it. StyleXNetwork. Great for letting a VPS idle all day but that is it.
    The graph that was attached earlier was not made up. It was directly taken from OnApp. Based on your usage and current CPU priority limits you are using too much. Whether your machine is idle or not, I am simply calculating your usage based on the graph that was directly pulled from OnApp.

    We also never stated anything in regards to "abusing resources", we simply stated that you are exhausting your resources which is directly effecting your performance.

    I cannot change the fact that your machine is having performance issues due to limited resources.

  6. #6
    Join Date
    Dec 2009
    Posts
    60
    If an idle vps is using too many resources why don't you provide a refund?

    It is fraud. I can't use the service. Hence I am not getting what I am paying for.

  7. #7
    Quote Originally Posted by luma View Post
    If an idle vps is using too many resources why don't you provide a refund?

    It is fraud. I can't use the service. Hence I am not getting what I am paying for.
    An idle machine is using too much resources because the resource allocation is very small to begin with.

    Again back to CPU usage, I cannot vouch for the fact that your machine is at idle or not. I can only go by facts, based on your graph your CPU is too high for your cpu allocation.

    Everything we say you consider us "blaming" you. We are simply stating the root cause of your issue.

    I have looked at your history and you have been with us for more than 1 year. Our environment has been consistent, nothing has changed. However all of a sudden you are experiencing performance issues which is directly in result of high cpu usage based on the graph pulled from OnApp.

    Please clarify how this is "fraud".
    Last edited by Stylex Networks; 04-25-2013 at 03:43 PM.

  8. #8
    Join Date
    Dec 2009
    Posts
    60
    Quote Originally Posted by Stylex Networks View Post
    An idle machine is using too much resources because the resource allocation is very small to begin with.

    Please clarify how this is "fraud".
    It is fraud because you have limited the resources to the point that an idle vps is using too many resources in turn making it 100% useless.

  9. #9
    Quote Originally Posted by luma View Post
    It is fraud because you have limited the resources to the point that an idle vps is using too many resources in turn making it 100% useless.
    I am not sure if I understand you correctly. Your plan comes with 256MB of RAM, 11GB disk space, 1 core and 2% guaranteed.

    Your machine has 256MB of RAM, 1 core - only 2% usage guaranteed, and 11GB disk space. How are we limiting your resources?

    We use Xen for our virtualization, RAM is dedicated not guaranteed. CPU, % is guaranteed. Burst is also allowed, however fair usage. Since your % guaranteed is very low, you will be throttled at times when your CPU usage is too high.

    I can understand if you experienced these issues a week or two after singing up with us, however you have been with us for more than a year. Our environment has stayed consistent and so has our virtualization and our CPU allocation logic.
    Last edited by Stylex Networks; 04-25-2013 at 03:53 PM.

  10. #10
    Join Date
    Dec 2009
    Posts
    60
    Right back to the reason for this thread:

    --- . (ext3 /dev/xvda1) ioping statistics ---
    10 requests completed in 9406.0 ms, 25 iops, 0.1 mb/s
    min/avg/max/mdev = 0.3/40.4/169.4/61.1 ms


    How is that not limiting my resources? 25 iops? a floppy drive is around that.

  11. #11
    Quote Originally Posted by luma View Post
    Right back to the reason for this thread:

    --- . (ext3 /dev/xvda1) ioping statistics ---
    10 requests completed in 9406.0 ms, 25 iops, 0.1 mb/s
    min/avg/max/mdev = 0.3/40.4/169.4/61.1 ms


    How is that not limiting my resources? 25 iops? a floppy drive is around that.
    That is not the case, your CPU usage is too high due to limited CPU allocation which is directly effecting your performance.

    The graph above clearly shows that based on your current CPU allocation your usage is too high, therefore you are throttled constantly based on your limits.

    Again you mention that your machine is at idle, however the graph above states otherwise.

  12. #12
    Join Date
    Dec 2009
    Posts
    60
    Again, My vps is Idle. So if by being Idle it is being limited down to 25 iops that is fraud because it means I can't use it for anything at all.

    What is the point of a VPS that is over using resources when Idle?

    What can I run on this?

  13. #13
    Quote Originally Posted by luma View Post
    Again, My vps is Idle. So if by being Idle it is being limited down to 25 iops that is fraud because it means I can't use it for anything at all.

    What is the point of a VPS that is over using resources when Idle?

    What can I run on this?
    I think you are missing the point. Based on your usage on the first part of the graph, your machine isn't at idle.

  14. #14
    Join Date
    Dec 2009
    Posts
    60
    Last time I checked It was not possible for load average to go into the Negative so I am not sure how this is not Idle:

    14:58:32 up 5 days, 16:46, 1 user, load average: 0.00, 0.00, 0.00

  15. #15
    Quote Originally Posted by luma View Post
    Last time I checked It was not possible for load average to go into the Negative so I am not sure how this is not Idle:

    14:58:32 up 5 days, 16:46, 1 user, load average: 0.00, 0.00, 0.00
    The graph clearly say otherwise, that your machine is not at idle.

    I apologize however we can't perform any miracles. Based on your usage, your resources are too little and are directly effecting your performance. At this point the only solution is to upgrade your resources.
    Attached Thumbnails Attached Thumbnails Screen Shot 2013-04-25 at 4.00.35 PM.png  
    Last edited by Stylex Networks; 04-25-2013 at 04:04 PM.

  16. #16
    Join Date
    Sep 2003
    Location
    India
    Posts
    127

    Re: StyleXnetworks review - Terrible.

    I have 8 cores.. 4gb ram check if my result is good or what

    [email protected] [~]# ioping -c 10 /

    4096 bytes from / (ext3 /dev/xvda1): request=1 time=1.1 ms
    4096 bytes from / (ext3 /dev/xvda1): request=2 time=57.8 ms
    4096 bytes from / (ext3 /dev/xvda1): request=3 time=1.2 ms
    4096 bytes from / (ext3 /dev/xvda1): request=4 time=1.3 ms
    4096 bytes from / (ext3 /dev/xvda1): request=5 time=0.7 ms
    4096 bytes from / (ext3 /dev/xvda1): request=6 time=0.8 ms
    4096 bytes from / (ext3 /dev/xvda1): request=7 time=1.3 ms
    4096 bytes from / (ext3 /dev/xvda1): request=8 time=0.6 ms
    4096 bytes from / (ext3 /dev/xvda1): request=9 time=2.4 ms
    4096 bytes from / (ext3 /dev/xvda1): request=10 time=2.5 ms

    --- / (ext3 /dev/xvda1) ioping statistics ---
    10 requests completed in 9072.0 ms, 144 iops, 0.6 mb/s
    min/avg/max/mdev = 0.6/7.0/57.8/17.0 ms
    [email protected] [~]#
    Freelance Web Designer & Web Host
    Dotcommakers- Animated banners, Website Templates, WordPress Themes - me [at] rakesh.in
    The Reliable Host - Shared & Reseller hosting
    End user support | CloudFlare | SEO Tools | Daily backups on 2 locations

  17. #17
    Join Date
    Sep 2003
    Location
    India
    Posts
    127
    And this

    [email protected] [~]# dd if=/dev/zero of=test bs=1M count=512 conv=fdatasync;rm -rf test
    512+0 records in
    512+0 records out
    536870912 bytes (537 MB) copied, 8.32108 s, 64.5 MB/s
    [email protected] [~]#

  18. #18
    Join Date
    Dec 2009
    Posts
    60
    144 iops is around what a single modern spinny drive will get (7200rpm)

    So is it bad? no, good for a server? not really.

    My other VPS (low end to high end) with various providers found on these forums give me 500 to 3000 iops.



    Quote Originally Posted by rakeshraja View Post
    I have 8 cores.. 4gb ram check if my result is good or what

    --- / (ext3 /dev/xvda1) ioping statistics ---
    10 requests completed in 9072.0 ms, 144 iops, 0.6 mb/s
    min/avg/max/mdev = 0.6/7.0/57.8/17.0 ms
    [email protected] [~]#

  19. #19
    Quote Originally Posted by rakeshraja View Post
    I have 8 cores.. 4gb ram check if my result is good or what

    [email protected] [~]# ioping -c 10 /

    4096 bytes from / (ext3 /dev/xvda1): request=1 time=1.1 ms
    4096 bytes from / (ext3 /dev/xvda1): request=2 time=57.8 ms
    4096 bytes from / (ext3 /dev/xvda1): request=3 time=1.2 ms
    4096 bytes from / (ext3 /dev/xvda1): request=4 time=1.3 ms
    4096 bytes from / (ext3 /dev/xvda1): request=5 time=0.7 ms
    4096 bytes from / (ext3 /dev/xvda1): request=6 time=0.8 ms
    4096 bytes from / (ext3 /dev/xvda1): request=7 time=1.3 ms
    4096 bytes from / (ext3 /dev/xvda1): request=8 time=0.6 ms
    4096 bytes from / (ext3 /dev/xvda1): request=9 time=2.4 ms
    4096 bytes from / (ext3 /dev/xvda1): request=10 time=2.5 ms

    --- / (ext3 /dev/xvda1) ioping statistics ---
    10 requests completed in 9072.0 ms, 144 iops, 0.6 mb/s
    min/avg/max/mdev = 0.6/7.0/57.8/17.0 ms
    [email protected] [~]#
    Open a support ticket and I will have an engineer take a look this. However there can be many factors at a local level effecting this. We don't know what is running on your machine and what configurations it has, very difficult to judge.

    Tests were ran on a global level on our Hypervisors:

    /root/ioping-0.6/ioping -c10 .
    4096 bytes from . (ext3 /dev/root): request=1 time=0.5 ms
    4096 bytes from . (ext3 /dev/root): request=2 time=0.6 ms
    4096 bytes from . (ext3 /dev/root): request=3 time=0.7 ms
    4096 bytes from . (ext3 /dev/root): request=4 time=0.3 ms
    4096 bytes from . (ext3 /dev/root): request=5 time=0.4 ms
    4096 bytes from . (ext3 /dev/root): request=6 time=0.3 ms
    4096 bytes from . (ext3 /dev/root): request=7 time=0.5 ms
    4096 bytes from . (ext3 /dev/root): request=8 time=0.8 ms
    4096 bytes from . (ext3 /dev/root): request=9 time=0.6 ms
    4096 bytes from . (ext3 /dev/root): request=10 time=0.7 ms

    --- . (ext3 /dev/root) ioping statistics ---
    10 requests completed in 9034.9 ms, 1852 iops, 7.2 mb/s
    min/avg/max/mdev = 0.3/0.5/0.8/0.2 ms

  20. #20
    Join Date
    Sep 2003
    Location
    India
    Posts
    127

    Re: StyleXnetworks review - Terrible.

    Tried again and it give me

    [email protected] [~]# ioping -c 10 /4096 bytes from / (ext3 /dev/xvda1): request=1 time=0.4 ms
    4096 bytes from / (ext3 /dev/xvda1): request=2 time=0.6 ms
    4096 bytes from / (ext3 /dev/xvda1): request=3 time=0.6 ms
    4096 bytes from / (ext3 /dev/xvda1): request=4 time=0.5 ms
    4096 bytes from / (ext3 /dev/xvda1): request=5 time=0.6 ms
    4096 bytes from / (ext3 /dev/xvda1): request=6 time=0.6 ms
    4096 bytes from / (ext3 /dev/xvda1): request=7 time=0.9 ms
    4096 bytes from / (ext3 /dev/xvda1): request=8 time=0.7 ms
    4096 bytes from / (ext3 /dev/xvda1): request=9 time=0.6 ms
    4096 bytes from / (ext3 /dev/xvda1): request=10 time=0.9 ms

    --- / (ext3 /dev/xvda1) ioping statistics ---
    10 requests completed in 9008.7 ms, 1581 iops, 6.2 mb/s
    min/avg/max/mdev = 0.4/0.6/0.9/0.1 ms
    [email protected] [~]#
    Freelance Web Designer & Web Host
    Dotcommakers- Animated banners, Website Templates, WordPress Themes - me [at] rakesh.in
    The Reliable Host - Shared & Reseller hosting
    End user support | CloudFlare | SEO Tools | Daily backups on 2 locations

  21. #21
    Join Date
    Sep 2003
    Location
    India
    Posts
    127

    Re: StyleXnetworks review - Terrible.

    To StyleXNetworks, try may be couple times. It always give different results.
    Freelance Web Designer & Web Host
    Dotcommakers- Animated banners, Website Templates, WordPress Themes - me [at] rakesh.in
    The Reliable Host - Shared & Reseller hosting
    End user support | CloudFlare | SEO Tools | Daily backups on 2 locations

  22. #22
    Quote Originally Posted by rakeshraja View Post
    To StyleXNetworks, try may be couple times. It always give different results.
    I will follow up here once the engineer checking this issue gets back to me. As of now I cannot say anything, we don't know what is on your machine or what configurations it has, therefore it would be very difficult to judge.

    Please follow up on the ticket for further assistance.

  23. #23
    Join Date
    Jul 2011
    Posts
    496
    Sounds like their servers are inconsistent.
    The 47 Ronin Gaming: www.47r-squad.com
    Counter-Strike: Source, Counter-Strike: Global Offensive

  24. #24
    Quote Originally Posted by IcEWoLF View Post
    Sounds like their servers are inconsistent.
    Again, since we do not know what is running on the machine or what configurations it has I cannot say anything.

    The inconsistency could very well be at a local level.

    Will follow up on this shortly.

  25. #25

  26. #26
    Join Date
    Sep 2003
    Location
    India
    Posts
    127
    You can post it StylexNetworks.
    Freelance Web Designer & Web Host
    Dotcommakers- Animated banners, Website Templates, WordPress Themes - me [at] rakesh.in
    The Reliable Host - Shared & Reseller hosting
    End user support | CloudFlare | SEO Tools | Daily backups on 2 locations

  27. #27
    Your machine required some tuning in the operating system's parameters.

    Results:

    4096 bytes from . (ext3 /dev/xvda1): request=1 time=0.3 ms
    4096 bytes from . (ext3 /dev/xvda1): request=2 time=0.6 ms
    4096 bytes from . (ext3 /dev/xvda1): request=3 time=0.6 ms
    4096 bytes from . (ext3 /dev/xvda1): request=4 time=0.6 ms
    4096 bytes from . (ext3 /dev/xvda1): request=5 time=0.4 ms
    4096 bytes from . (ext3 /dev/xvda1): request=6 time=0.5 ms
    4096 bytes from . (ext3 /dev/xvda1): request=7 time=0.6 ms
    4096 bytes from . (ext3 /dev/xvda1): request=8 time=0.5 ms
    4096 bytes from . (ext3 /dev/xvda1): request=9 time=0.6 ms
    4096 bytes from . (ext3 /dev/xvda1): request=10 time=1.1 ms

    --- . (ext3 /dev/xvda1) ioping statistics ---
    10 requests completed in 9007.3 ms, 1744 iops, 6.8 mb/s
    min/avg/max/mdev = 0.3/0.6/1.1/0.2 ms
    4096 bytes from . (ext3 /dev/xvda1): request=1 time=0.3 ms
    4096 bytes from . (ext3 /dev/xvda1): request=2 time=0.6 ms
    4096 bytes from . (ext3 /dev/xvda1): request=3 time=0.5 ms
    4096 bytes from . (ext3 /dev/xvda1): request=4 time=0.6 ms
    4096 bytes from . (ext3 /dev/xvda1): request=5 time=0.5 ms
    4096 bytes from . (ext3 /dev/xvda1): request=6 time=0.5 ms
    4096 bytes from . (ext3 /dev/xvda1): request=7 time=0.4 ms
    4096 bytes from . (ext3 /dev/xvda1): request=8 time=0.4 ms
    4096 bytes from . (ext3 /dev/xvda1): request=9 time=1.2 ms
    4096 bytes from . (ext3 /dev/xvda1): request=10 time=0.6 ms

    --- . (ext3 /dev/xvda1) ioping statistics ---
    10 requests completed in 9009.2 ms, 1778 iops, 6.9 mb/s
    min/avg/max/mdev = 0.3/0.6/1.2/0.2 ms
    4096 bytes from . (ext3 /dev/xvda1): request=1 time=0.3 ms
    4096 bytes from . (ext3 /dev/xvda1): request=2 time=0.9 ms
    4096 bytes from . (ext3 /dev/xvda1): request=3 time=0.7 ms
    4096 bytes from . (ext3 /dev/xvda1): request=4 time=0.6 ms
    4096 bytes from . (ext3 /dev/xvda1): request=5 time=0.6 ms
    4096 bytes from . (ext3 /dev/xvda1): request=6 time=1.0 ms
    4096 bytes from . (ext3 /dev/xvda1): request=7 time=0.5 ms
    4096 bytes from . (ext3 /dev/xvda1): request=8 time=0.5 ms
    4096 bytes from . (ext3 /dev/xvda1): request=9 time=0.5 ms
    4096 bytes from . (ext3 /dev/xvda1): request=10 time=0.6 ms

    --- . (ext3 /dev/xvda1) ioping statistics ---
    10 requests completed in 9007.8 ms, 1628 iops, 6.4 mb/s
    min/avg/max/mdev = 0.3/0.6/1.0/0.2 ms
    4096 bytes from . (ext3 /dev/xvda1): request=1 time=0.3 ms
    4096 bytes from . (ext3 /dev/xvda1): request=2 time=0.6 ms
    4096 bytes from . (ext3 /dev/xvda1): request=3 time=1.0 ms
    4096 bytes from . (ext3 /dev/xvda1): request=4 time=0.5 ms
    4096 bytes from . (ext3 /dev/xvda1): request=5 time=1.0 ms
    4096 bytes from . (ext3 /dev/xvda1): request=6 time=0.5 ms
    4096 bytes from . (ext3 /dev/xvda1): request=7 time=0.5 ms
    4096 bytes from . (ext3 /dev/xvda1): request=8 time=0.4 ms
    4096 bytes from . (ext3 /dev/xvda1): request=9 time=1.1 ms
    4096 bytes from . (ext3 /dev/xvda1): request=10 time=0.6 ms

    --- . (ext3 /dev/xvda1) ioping statistics ---
    10 requests completed in 9008.3 ms, 1516 iops, 5.9 mb/s
    min/avg/max/mdev = 0.3/0.7/1.1/0.3 ms
    date;dd if=/dev/zero of=test bs=1M count=512 conv=fdatasync;rm -
    Fri Apr 26 10:49:48 IST 2013
    512+0 records in
    512+0 records out
    536870912 bytes (537 MB) copied, 3.04974 s, 176 MB/s

    date;dd if=/dev/zero of=test bs=1M count=512 conv=fdatasync;rm *
    Fri Apr 26 10:49:25 IST 2013
    512+0 records in
    512+0 records out
    536870912 bytes (537 MB) copied, 4.11358 s, 131 MB/s

    date;dd if=/dev/zero of=test bs=1M count=512 conv=fdatasync;rm -
    Fri Apr 26 10:50:03 IST 2013
    512+0 records in
    512+0 records out
    536870912 bytes (537 MB) copied, 4.13331 s, 130 MB/s

    date;dd if=/dev/zero of=test bs=1M count=512 conv=fdatasync;rm -
    Fri Apr 26 10:50:17 IST 2013
    512+0 records in
    512+0 records out
    536870912 bytes (537 MB) copied, 3.98494 s, 135 MB/
    After tweaking the machine results had significantly improved. However, after a few hours performance was effected by an abuser which was taken care of immediately.
    Last edited by Stylex Networks; 04-26-2013 at 01:37 AM.

  28. #28
    Join Date
    Sep 2003
    Location
    India
    Posts
    127
    After some tweak by them ioping is improved

    [email protected] [~]# ioping -c10 .
    4096 bytes from . (ext3 /dev/xvda1): request=1 time=0.4 ms
    4096 bytes from . (ext3 /dev/xvda1): request=2 time=0.5 ms
    4096 bytes from . (ext3 /dev/xvda1): request=3 time=0.6 ms
    4096 bytes from . (ext3 /dev/xvda1): request=4 time=1.1 ms
    4096 bytes from . (ext3 /dev/xvda1): request=5 time=0.5 ms
    4096 bytes from . (ext3 /dev/xvda1): request=6 time=0.5 ms
    4096 bytes from . (ext3 /dev/xvda1): request=7 time=0.5 ms
    4096 bytes from . (ext3 /dev/xvda1): request=8 time=1.0 ms
    4096 bytes from . (ext3 /dev/xvda1): request=9 time=0.5 ms
    4096 bytes from . (ext3 /dev/xvda1): request=10 time=0.5 ms

    --- . (ext3 /dev/xvda1) ioping statistics ---
    10 requests completed in 9008.2 ms, 1623 iops, 6.3 mb/s
    min/avg/max/mdev = 0.4/0.6/1.1/0.2 ms
    Last edited by rakeshraja; 04-26-2013 at 01:37 AM.
    Freelance Web Designer & Web Host
    Dotcommakers- Animated banners, Website Templates, WordPress Themes - me [at] rakesh.in
    The Reliable Host - Shared & Reseller hosting
    End user support | CloudFlare | SEO Tools | Daily backups on 2 locations

  29. #29
    Join Date
    Aug 2007
    Posts
    56
    Quote Originally Posted by Stylex Networks View Post
    The graph clearly say otherwise, that your machine is not at idle.

    I apologize however we can't perform any miracles. Based on your usage, your resources are too little and are directly effecting your performance. At this point the only solution is to upgrade your resources.
    Stylex - could you create a new test VM with the same specs as the OP and run the ioping tests in that? That would show that the issue is likely to be down to something within his VM, rather than the limits on the VM being unreasonably low?

  30. #30
    Join Date
    Oct 2005
    Location
    Summerville, SC
    Posts
    999
    Quote Originally Posted by rscott101 View Post
    Stylex - could you create a new test VM with the same specs as the OP and run the ioping tests in that? That would show that the issue is likely to be down to something within his VM, rather than the limits on the VM being unreasonably low?
    I would love to see the results of this as well. Have been thinking about getting some services with StyleX but this thread does have me a little concerned.

    While I do realize it's a very small VPS...offering services that are using max CPU while running idle would just be a bad practice. So seeing proof that it is indeed the clients VPS and not all VPS's of this package size would be nice.

  31. #31
    Quote Originally Posted by Daniel B View Post
    I would love to see the results of this as well. Have been thinking about getting some services with StyleX but this thread does have me a little concerned.

    While I do realize it's a very small VPS...offering services that are using max CPU while running idle would just be a bad practice. So seeing proof that it is indeed the clients VPS and not all VPS's of this package size would be nice.
    There is no way for us to artificially raise the CPU usage while a machine is idle with out having direct access to the machine. even if we could it really doesn't benefit us. SImply going by the graph and the cpu priority limitations (which are very little), the usage is too high. While the machine is idle, that does not mean there are not processes running in the background. I also want to mention that due to this specific reason (performance issues, high usage, etc) we no longer offer plans with low amounts of resources. This plan was discontinued a long time ago.

    Such specs are not an ideal environment for running everything. We offer a 7 day money back guarantee and I would not have any problem extending your refund policy if this is what concerns you.
    Last edited by Stylex Networks; 04-26-2013 at 11:58 AM.

  32. #32
    Join Date
    Oct 2005
    Location
    Summerville, SC
    Posts
    999
    Quote Originally Posted by Stylex Networks View Post
    I also want to mention that due to this specific reason (performance issues, high usage, etc) we no longer offer plans with low amounts of resources. This plan was discontinued a long time ago.
    That's all I needed to hear...this was my main concern. Offering a plan like this just didn't seem like a very moral thing to do, so seeing that you no longer offer it for that reason satisfies me. Thank you!

  33. #33
    Join Date
    Aug 2007
    Posts
    56
    The OP did say he was running a clean install of Debian 5 (presumably from your template ?) .

    Your site doesn't appear to mention any CPU limits with the current Cloud VPS plans? I've checked the TOS & AUP - no mention anywhere.

  34. #34
    Quote Originally Posted by rscott101 View Post
    The OP did say he was running a clean install of Debian 5 (presumably from your template ?) .

    Your site doesn't appear to mention any CPU limits with the current Cloud VPS plans? I've checked the TOS & AUP - no mention anywhere.
    I can only go by facts. CPU graphs do not lie, the machine is clearly not idling based on the graph. As stated previously a machine with such low amounts of resources isn't an ideal environment for running everything. The OS template it self has to be tuned and optimized, hence we no longer offer such plans with low amounts of resources.

    Unless specifically stated, in a virtualization environment no one allocates 100% of a core. We do offer plans with dedicated cores, however those are private nodes and are a completely different setup.

    This the logic we use for CPU allocation (Cloud VPS plans):

    We use the following in every Hypervisor: CPU: Dual Intel(R) Xeon(R) CPU E5620

    We assign 2 cores, 14% priority per 1GB of RAM. For example within our Super plan, you are allocated 12 cores, 84% priority. This really isn't a low amount, you are also able to burst within each core (fair usage), also having more than 1 core will always maximize your bursting capability. We have clients running exchange servers to resource intensive applications on a daily basis, none have any issues.

  35. #35
    Join Date
    Aug 2007
    Posts
    56
    They seem reasonable limits, but wouldn't it make sense to publish them somewhere on your site?

  36. #36
    Quote Originally Posted by rscott101 View Post
    They seem reasonable limits, but wouldn't it make sense to publish them somewhere on your site?
    In your client panel, it will clearly state that you have x amount of cores and x amount of CPU priority.

    When you are creating the machine you have to scale your RAM, HDD, CORES, and CPU priority. We really aren't hiding anything.

    You are under the impression that we allocate the cores and then adjust the % per core as we please. This isn't the case, the client knows exactly how much CPU priority they have and exactly how much they are allocating when they are creating each machine.
    Last edited by Stylex Networks; 04-26-2013 at 12:40 PM.

  37. #37
    Join Date
    Aug 2007
    Posts
    56
    Quote Originally Posted by Stylex Networks View Post
    In your client panel, it will clearly state that you have x amount of cores and x amount of CPU priority.

    When you are creating the machine you have to scale your RAM, HDD, CORES, and CPU priority. We really aren't hiding anything.

    You are under the impression that we allocate the cores and then adjust the % per core as we please. This isn't the case, the client knows exactly how much CPU priority they have and exactly how much they are allocating when they are creating each machine.
    No - I'm not under that impression at all. Please do not invent statements on my behalf.
    My point is that a potential client has no access to this information.

    On the ordering page, you specify number of cores, RAM and storage. No hint of information about cpu priority.

  38. #38
    Quote Originally Posted by rscott101 View Post
    No - I'm not under that impression at all. Please do not invent statements on my behalf.
    My point is that a potential client has no access to this information.

    On the ordering page, you specify number of cores, RAM and storage. No hint of information about cpu priority.
    This is something we can definitely do, I see no problem with that.

  39. #39
    Join Date
    Apr 2003
    Posts
    303

    Exclamation

    Quote Originally Posted by Stylex Networks View Post
    This is something we can definitely do, I see no problem with that.
    And this is what makes me stick with stylex even after recent major downtime.

    Are they one of the best hosts ? Not yet !
    Would they be one soon ? Seems so !
    Why ? They take feedback in a positive way.

    In my starting days with them, it was annoying how their staff needed root password each time and this delayed things. Now i posted a ticket about it and how other providers i am with do not ask for it. They considered it and in Interests of customers, gave up on that policy.

    Their staff has always been non-temperamental and I know one when i spot one .
    If you're hunting with 1 Bullet, wait for a clean shot !

  40. #40
    Join Date
    Dec 2009
    Posts
    60
    How many months free did you get to post this?

    This company is horrible.

    The CEO is a blatant liar.

    They don't provide what they advertise.

    They provided a product that was not useable. I could not idle the VPS (Clean Debian install, NO running service, no apache, no email, no databases, nothing!) and I was told I was using too many resources.

    This is Fraud. If you offer a service it should be useable.

    Now they don't offer it anymore, After I complained.

    did I get a refund? nope, Nothing.

    I had to call my credit card company and do a charge back. Which I hate to do but come on, if I don't get what is advertised what am I supposed to do?

    They have VERY frequent downtime.
    Poor support.
    Poor network.

    Stay away from these guys, even for a play ground. A provider such as Digital Ocean would be way better or any one of the established providers found on low end talk.


    I found the advertisement that I used to sign up. No where does it say I can't do anything but Idle:

    With plenty of other providers I have ran plenty of stuff within 256 megs of ram. Munble servers, even Nginx/mysql (tweaked) and php for basic wordpress sites.

    Again I say, this VPS had NONE of the above on it. It was a basic install. When I noticed performance problems doing things like updates I started investigating the problem and found the IO was the same speed as a floppy disk! When I opened a ticket I was told I was abusing the plan.
    Small Plan
    256 MB RAM
    10 GB HDD
    300 GB Bandwidth per month
    1 IPv4 Address
    Free /64 block of IPv6 (On request)
    OnApp Cloud platform
    Features: Xen Hypervisor, Automatic Fail over, Instant Scalability, RAID-10 storage, KVM console access, Load balancing and Auto-Scaling (Additional charges apply)


    Quote Originally Posted by chatbox View Post
    And this is what makes me stick with stylex even after recent major downtime.

    Are they one of the best hosts ? Not yet !
    Would they be one soon ? Seems so !
    Why ? They take feedback in a positive way.

    In my starting days with them, it was annoying how their staff needed root password each time and this delayed things. Now i posted a ticket about it and how other providers i am with do not ask for it. They considered it and in Interests of customers, gave up on that policy.

    Their staff has always been non-temperamental and I know one when i spot one .
    Last edited by luma; 04-30-2013 at 06:26 PM.

Page 1 of 2 12 LastLast

Similar Threads

  1. stylexnetworks 1 Month Review
    By chatbox in forum Web Hosting
    Replies: 2
    Last Post: 03-04-2013, 01:56 PM
  2. StyleXnetworks.com review - AVOID
    By KeithThomson in forum Web Hosting
    Replies: 5
    Last Post: 02-07-2013, 03:55 PM
  3. VPSLatch (Terrible Review)
    By Grumps in forum VPS Hosting
    Replies: 41
    Last Post: 01-24-2011, 08:23 PM
  4. Just Edge NY (REVIEW :: Terrible)
    By PrimeTimeHosting in forum Dedicated Server
    Replies: 10
    Last Post: 09-03-2008, 11:59 AM
  5. dot5hosting review - TERRIBLE
    By mikexx2020 in forum Web Hosting
    Replies: 7
    Last Post: 03-17-2007, 07:56 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •