[bm-chat] Status

4 views
Skip to first unread message

Timothy Collett ~ Anaris Family

unread,
May 10, 2010, 4:53:11 PM5/10/10
to BattleMaster Social Discussion
Though the temporary server is holding up OK, the main server is still
down. Tom is planning to look into hosting plans once he's gathered
enough data on bandwidth usage to know what he'll need.

I'm checking with Tom to see what he thinks of promoting this group as
at least a temporary alternative to the discussion list, since it was
hosted on the main server, and is thus, of course, down too. If he
agrees, we should see a surge in membership and volume.

Finally, I've added Ethan Lee Vita, the Community Manager, as a second
Manager of this group, in anticipation of this potential jump in
subscriptions, and he may be able to help bring some of the more
important Wiki pages back up in the Pages section of this group.

Timothy Collett

--
You received this message because you are subscribed to the Google Groups "BattleMaster Social Discussion" group.
To post to this group, send email to battlem...@googlegroups.com.
To unsubscribe from this group, send email to battlemaster-...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/battlemaster-sd?hl=en.

Peter

unread,
May 10, 2010, 10:41:49 PM5/10/10
to BattleMaster Social Discussion
On May 10, 1:53 pm, "Timothy Collett ~ Anaris Family"
<delvin.ana...@gmail.com> wrote:
> Though the temporary server is holding up OK, the main server is still
> down.  Tom is planning to look into hosting plans once he's gathered
> enough data on bandwidth usage to know what he'll need.
>
> I'm checking with Tom to see what he thinks of promoting this group as
> at least a temporary alternative to the discussion list, since it was
> hosted on the main server, and is thus, of course, down too.  If he
> agrees, we should see a surge in membership and volume.
>
> Finally, I've added Ethan Lee Vita, the Community Manager, as a second
> Manager of this group, in anticipation of this potential jump in
> subscriptions, and he may be able to help bring some of the more
> important Wiki pages back up in the Pages section of this group.
>
> Timothy Collett

Yay, this is better than the discussion group (in my opinion). :D

Peter

Timothy Collett ~ Anaris Family

unread,
May 18, 2010, 12:03:34 PM5/18/10
to BattleMaster Social Discussion
Update on status:

Tom has gathered enough statistics on usage and bandwidth to have
concluded that a cloud service (such as Amazon S3) will not be cost-
effective for hosting BM in. He's now looking at virtual hosting
plans.

He hopes to have a new server set up and going before he goes on
holiday at the end of this month, but he's not yet sure.

Timothy Collett

--
BattleMaster Social Discussion group:
To unsubscribe from this group, send email to
battlemaster-...@googlegroups.com

JimVT

unread,
May 18, 2010, 1:18:57 PM5/18/10
to BattleMaster Social Discussion
Things such as Rich text editor and the statistics were only on main
server, or are they just bugged?

On 18 mei, 18:03, "Timothy Collett ~ Anaris Family"

TGC

unread,
May 18, 2010, 1:56:47 PM5/18/10
to battlem...@googlegroups.com
On May 18, 2010, at 1:18 PM, JimVT wrote:
>
> Things such as Rich text editor and the statistics were only on main
> server, or are they just bugged?

The Rich Text Editor is bugged.

The Statistics don't work on the temporary server.

Timothy Collett

--

"Logic is a wonderful thing, but it doesn't always beat actual thought."
~ Terry Pratchett

Eric-Gellander Family

unread,
May 18, 2010, 1:59:45 PM5/18/10
to BattleMaster Social Discussion
is bandwidth the primary concern, or is the hardware itself? What are
the hardware requirements for BM, anyway?

On May 18, 11:03 am, "Timothy Collett ~ Anaris Family"

TGC

unread,
May 18, 2010, 2:20:21 PM5/18/10
to battlem...@googlegroups.com
On May 18, 2010, at 1:59 PM, Eric-Gellander Family wrote:
>
> is bandwidth the primary concern, or is the hardware itself? What are
> the hardware requirements for BM, anyway?

I don't know specifically, but I would guess it needs a decent amount of memory and a decent CPU, for the activity spikes at turn changes. It shouldn't need too much hard drive space.

But yeah, bandwidth would almost certainly be the primary concern.

Timothy Collett

--

"...that which we are, we are;
One equal temper of heroic hearts
Made weak by time and fate, but strong in will
To strive, to seek, to find, and not to yield."
~ Alfred Lord Tennyson

Andrew Buczkowski

unread,
May 18, 2010, 3:31:18 PM5/18/10
to battlem...@googlegroups.com
On Tue, May 18, 2010 at 11:20 AM, TGC <tcol...@topazgryphon.org> wrote:
> On May 18, 2010, at 1:59 PM, Eric-Gellander Family wrote:
>>
>> is bandwidth the primary concern, or is the hardware itself? What are
>> the hardware requirements for BM, anyway?
>
> I don't know specifically, but I would guess it needs a decent amount of memory and a decent CPU, for the activity spikes at turn changes.  It shouldn't need too much hard drive space.
>
> But yeah, bandwidth would almost certainly be the primary concern.
>
> Timothy Collett
>

Sure it's bursty, but most web applications are. There are interesting
solutions to manage bandwidth in these scenarios. Perhaps this is an
architecture problem? Is the server that runs the turn calculations
the same server that is serving the web pages? Does it need to be?
What does the technical architecture look like?

I have a sinking feeling that it's a single box in Tom's basement,
blowing obscene amounts of smoke twice daily. :)

Cheers,
Andrew

TGC

unread,
May 18, 2010, 4:38:04 PM5/18/10
to battlem...@googlegroups.com
On May 18, 2010, at 3:31 PM, Andrew Buczkowski wrote:
>
> Sure it's bursty, but most web applications are. There are interesting
> solutions to manage bandwidth in these scenarios. Perhaps this is an
> architecture problem? Is the server that runs the turn calculations
> the same server that is serving the web pages? Does it need to be?
> What does the technical architecture look like?
>
> I have a sinking feeling that it's a single box in Tom's basement,
> blowing obscene amounts of smoke twice daily. :)

The old server was, indeed, a single box, though I think it was at his office rather than in his basement (and it's currently on his desk, in pieces ;-) ).

I don't think he's had any *problems* with the load for several years now. The issue now is with finding a virtual server that will support the load properly, as he doesn't want to have the hassle of managing the physical box himself anymore.

Timothy Collett

--

Certainly there are things in life that money can't buy, But it's very funny—did you ever try buying them without money?
- Ogden Nash

Andrew Buczkowski

unread,
May 18, 2010, 5:12:06 PM5/18/10
to battlem...@googlegroups.com
On Tue, May 18, 2010 at 1:38 PM, TGC <tcol...@topazgryphon.org> wrote:
> On May 18, 2010, at 3:31 PM, Andrew Buczkowski wrote:
>>
>> Sure it's bursty, but most web applications are. There are interesting
>> solutions to manage bandwidth in these scenarios. Perhaps this is an
>> architecture problem? Is the server that runs the turn calculations
>> the same server that is serving the web pages? Does it need to be?
>> What does the technical architecture look like?
>>
>> I have a sinking feeling that it's a single box in Tom's basement,
>> blowing obscene amounts of smoke twice daily. :)
>
> The old server was, indeed, a single box, though I think it was at his office rather than in his basement (and it's currently on his desk, in pieces ;-) ).
>
> I don't think he's had any *problems* with the load for several years now.  The issue now is with finding a virtual server that will support the load properly, as he doesn't want to have the hassle of managing the physical box himself anymore.
>
> Timothy Collett

I know you're speaking for a third party, so it is difficult to
answer. But has he spec'd out the unique requirements for the turn
calculations versus the regular page serving? If Tom was to decouple
the two perhaps he would find more cost effective solutions.

This would require a bit of Dev work to modularize the functionality,
but it would lead to a much more robust design.

-Andrew

Andrew Buczkowski

unread,
May 18, 2010, 5:09:57 PM5/18/10
to battlem...@googlegroups.com
On Tue, May 18, 2010 at 1:38 PM, TGC <tcol...@topazgryphon.org> wrote:
> On May 18, 2010, at 3:31 PM, Andrew Buczkowski wrote:
>>
>> Sure it's bursty, but most web applications are. There are interesting
>> solutions to manage bandwidth in these scenarios. Perhaps this is an
>> architecture problem? Is the server that runs the turn calculations
>> the same server that is serving the web pages? Does it need to be?
>> What does the technical architecture look like?
>>
>> I have a sinking feeling that it's a single box in Tom's basement,
>> blowing obscene amounts of smoke twice daily. :)
>
> The old server was, indeed, a single box, though I think it was at his office rather than in his basement (and it's currently on his desk, in pieces ;-) ).
>
> I don't think he's had any *problems* with the load for several years now.  The issue now is with finding a virtual server that will support the load properly, as he doesn't want to have the hassle of managing the physical box himself anymore.
>
> Timothy Collett

I know you're speaking for a third party, so it is difficult to
answer. But has he spec'd out the unique requirements for the turn
calculations versus the regular page serving? If Tom was to decouple
the two perhaps he would find more cost effective solutions.

This would require a bit of Dev work to modularize the functionality,
but it would lead to a much more robust design.

-Andrew

Reply all
Reply to author
Forward
0 new messages