I've worked on several projects with massive numbers of simultaneous
users and hits against data. Did this for Nortel, a broadband wireless
company and another small telecom.
The trick is to know where to scale the hardware and where to put the
data and where to put the logic.
Look at it in four tiers:
1. Client machine/software (rev client, let's say)
2. Web server (apache, of course)
3. Web application server (assume revServer CGIs)
4. Data (whatever you like...i prefer to roll my own, but to each his/
her own)
The cheapest, most scalable and fastest performing are all the same
solution:
1. Client: thin
2. Web server: thin, but round-robin'd the IP addresses to 1 of the 13
app servers
3. Web app server: hefty, almost fat
4. Data: thin and agnostic (NO stored procedures)
At Nortel, we had 13 app servers. Cheap high-performance Dells. $2000
each. We had ONE database server (SQL server). Most of the code
(logic) was on the app server. We had 30 thousand users logging their
hours against 50 thousand projects. We had 5000 simultaneous users
ever Friday afternoon.
We did have a chron job that ran each night to populate the app server
with highly indexed data for project look up.
The whole thing ran on a browser. Today I would have used a Rev client
app, but I would have kept it very thin.
Best,
Jerry Daniels
Use tRev's buy link during your 7 day free trial to get 20% off:
http://reveditor.com/tag/shouldiswitch
On May 20, 2010, at 10:38 AM, David Bovill wrote:
On 20 May 2010 14:27, Jerry Daniels <[email protected]> wrote:
Of course it's still early days, but we are very serious about
having a
scaleable backend service.
Since one of us is in Australia, we also want geographic coverage.
Every
day this sector of our industry gets better.
Massively shared servers? No. Deals for dedicated servers? Yes.
We want this to be a premium service focused on performance. It
will not be
free. We are not taking on VC for this. There are no ads to support
it. It
will be fee supported.
Thanks for the info Jerry - very clear. Please keep us posted with
details
on your plans for backend scaleability using On-Rev. I'll keep
investigating
using cloud databases for this as i project I am working on needs it
- and I
can;t see how I would use On-Rev to deliver easy and affordable
scalability.
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
