in reply to Re^2: Can your site handle this?
in thread Can your site handle this?

Oh come on stress testing against Localhost is entirely unrealistic. For a start you've removed all network I/O limitations,

You are quite right for the most part. First of all, my DSL modem would go up in flames before even a cheap rent-a-server service would notice any relevant increase in traffic. So, for real-life testing you need a decent internet connection for a start. But then, yes, testing makes a lot more sense.

But testing against localhost is also a good idea. You might notice race conditions and things like that a lot easier. At least, i did.

and for seconds unless your renting a beefy server your likely to have far more available RAM on a home system, especially these days.

When doing production critical services, i usually put my own servers in a colocation. While it's certainly more work, it usually pays (for me) in the long run. Especially when upgrade time comes around. But since i do (mostly) in-house stuff, your situation is probably completly different from mine...

Don't use '#ff0000':
use Acme::AutoColor; my $redcolor = RED();
All colors subject to change without notice.

Replies are listed 'Best First'.
Re^4: Can your site handle this?
by Anonymous Monk on Nov 06, 2011 at 01:53 UTC
    your situation is probably completly different from mine...

    Yeh, sounds like it... I'm unemployed and I can only afford a basic server on a budget of about $20 a month. I am therefore forced to make the absolute most out of very limited hardware, at least until one of my sites becomes financially productive when I will be able to scale my hosting plan up.

    The practical upshot of being so highly restricted is that the code which runs fast on such a tiny box is going to kick arse when it gets run on a decent size box.

    I once had access to some IBM Big Iron, I have no idea how much ram it had or how much processing power as the service was provided on the basis of price per megabyte of storage. That was a few years ago now and at the time I couldn't see any problem with the efficiency of my system.

    It wasn't until quite recently when contemplating what would be needed to run a massive-multiplayer online game that I realised the software I had was not going to be anywhere near fast enough for the task given the size of server I can afford, so the quest to speed it up began and that's why aXML got optimised and married to Plack, with the result being that now it's several orders of magnitude faster and even a poxy little $20 a month server is a sufficient basis for several hundred concurrent users... and my path is clear to develop the game I have in mind and have wanted to get stuck into writing for a long time now.

    You know what aXML is a stupid unimaginative name... I really need to find a better one. I have been toying with "Diamond", or maybe "Sapphire". Either would be better and given that we already have "Perl" and "Ruby", the precious gem moniker seems to fit quite nicely with current trends.

[reply]

      I'm unemployed and I can only afford a basic server on a budget of about $20 a month. I am therefore forced to make the absolute most out of very limited hardware, at least until one of my sites becomes financially productive when I will be able to scale my hosting plan up.

      I don't want to crush your hopes, but even if you had the best product on the whole internet, it would still take a fair bit of luck and most likely quite some investment to get the site financially productive. Since margins today are very low for most use cases, you'll probably need a huge user base.

      And to get that, you will need to have adequate hardware and bandwidth from the start - since a single link on a major new outlet or community website may send you a huge number of potential users. This is known as the Slashdot effect. If your site slows to a crawl, most of those user may never come back...

      The practical upshot of being so highly restricted is that the code which runs fast on such a tiny box is going to kick arse when it gets run on a decent size box.

      Maybe, maybe not. When you go to a large scale, more caching in RAM may become cheaper than more CPU power (often reversed in small scale systems).

      Also, when doing large site with many write operations, referential integrity of the data may or may not become much more important. It does especially when doing something financial (starting with serving ads). So you'll need an ACID compliant database, which, when configured correctly for performance, will most of the time also be more RAM bound than CPU bound.

      It wasn't until quite recently when contemplating what would be needed to run a massive-multiplayer online game

      This needs much more than just a fast server. For a successful service, you'll need redundant systems all over the world, a huge amount of low-lag bandwidth, 24/7 admin support, developers who constantly fix bugs and improve content and so on. Thats why there are not that much companies who have a success on the long run, a working community and actually make money through their service.

      and my path is clear to develop the game I have in mind and have wanted to get stuck into writing for a long time now.

      I wrote a (relatively simple) Jump'n'Run game myself called BlinkenSisters. Something like that is a shitload of work for a single person.

      I don't say it's impossible for a single person to write a working, modern, successful MMOG, but it would - in my opinion - take literally a decade or two to pull it off.

      Don't use '#ff0000':
      use Acme::AutoColor; my $redcolor = RED();
      All colors subject to change without notice.
[reply]

        Slashdot, yeh I remember a friend of mine mentioning that, way back like 1997 I think when I was at college... scary stuff ^^

        I think currently the biggest problem I'm going to face is the database rather than any code problems. I'm currently using MySQL but I've heard that it doesn't scale particularly well, hence the reason for the existence of NoSQL and the like.

        Oddly enough until I wrote version 4 of aXML about 3 years ago, it didn't even have a database access system in it, it was pure flat files. I abandoned that route when I got to grips with MySQL because it seemed to be faster at the time, however I have this sneaky feeling that at some point I'm going to end up going back to flat files albeit using them in a more advanced way than I used to.

        As for the MMORPG, it's not going to take me that long to build as I have various tricks up my sleeve... for instance being the only person in the world using aXML to develop with; which gives me a huge advantage in terms of development time and debugging time compared with writing lower level code.

        Perl Nights there was pretty much fully functional after just a few days work, and that included stopping to have big arguments here with the monks and fixing a few subtle bugs in the new plack based re-write of my core engine and plugin set.

        The other thing which will work in my favour is that the MMORPG is going to be set in space like the massively popular "ogame", and thus won't require too much in terms of graphic design work to get going.

        Now that I have a server capable of serving a decent amount of traffic, and I've race tested localhost on an AMD Quad Core Phenom II with 4GB ram, I'm pretty confident I will be able to scale up faster than new users arrive unless the game proves to be phenomenally popular, in which case I'll be getting in touch with my mate at IBM to get some big iron behind it.

        In the meantime my server provider supports instant scaling by adding extra nodes and node balancers so hopefully I have all the ingredients for the cake lined up now.

[reply]

In Section Meditations