Mono, gcj, java, c++, what?

[Mark Woodward]

On 08/29/2010 02:42 PM, Dan Ritter wrote:
> On Sun, Aug 29, 2010 at 08:34:44AM -0400, Mark Woodward wrote:
>    
>>> You must be able to run this on many machines with a load balancer.
>>>
>>>        
>> These days? You'd be surprised at the capacity of $600 worth of computer
>> supplies. Its enough to run all but the very big sites.
>>      
> I wouldn't be surprised at all. Now, after you've got it up and
> running... what do you do for maintenance? Both software and
> hardware. What do you do when you get slashdotted, or the moral
> equivalent of same? What do you when the power supply fails? OK,
> you spent the money for dual power supplies. What do you do when
> the motherboard fails?
>    
Seriously, think about a solution I just deployed. Its kind of kool. Two 
cheap computers, both well able to keep up with being "slash-dotted." A 
direct wire between the two of them for replication and synchronization. 
Full fail-over with a load balancer. (assuming the load balancer doesn't 
fail).

In almost 20 years of doing this stuff, I've never seen a reasonable 
quality computer that wasn't over clocked fail after a 30 day burn in 
under two years. I've seen hard disks go, but they usually give you a 
sector error here and there in the dmesg log well before real failure. 
Infant mortality is the killer, after that, the systems usually run 
until obsolete.

I have a site currently in service with vintage 1999 dual SMP 
motherboards and power supplies. I've only replaced the disks and blown 
out the fans every two or three years.

There is a serious value discussion that should take place that a lot of 
companies never consider. Full redundancy is expensive, it can be 
difficult to maintain, and like a fire extinguisher, its hard to know if 
it will work when you need it.

If you will lose value (based on a worst case failure/repair time cycle) 
that exceeds the cost of a redundant system, then you have to deal with 
that. Otherwise, it isn't even a real problem in a business sense.

Then you have to look at the probability of failure, what the likely 
failures will be and what steps you can take to mitigate the problems. A 
"hot spare" and a rolling backup, will probably keep your down time to 
less than an hour if you or your IT guys keep near an internet connection.
>    
>> Funny, but "stored procedures" are probably the best way to implement a
>> lot of functionality. They are "pre-compiled" by the databases, are
>> faster than raw queries, and can be modified without touching the web
>> code. My advice is to avoid databases that don't have such features. I
>> could start my "don't even think about using MySQL rant."
>>      
> Some sites can't support the license fees for Oracle or DB2.
>    
I would say most, but I basically agree.
> That leaves MySQL and Postgres, for SQL databases, and a whole
> host of non-SQL systems of various sorts. No matter what you
> start with, you may want to change it later on. Stored
> procedures will make that a nasty pain.
>    
Only if you want to switch databases mid-stream, and no database will be 
without problems. It is virtually impossible to go from MySQL to a real 
database without re-writing tables and writing a data reformatter to 
take MySQL database extracts and load them into something else. Some 
NoSQL to SQL or some other system, isn't going to be pretty.

I usually go postgresql. If you need Oracle clustering, then that's what 
you need, but postgres does just fine.
> Oh, and "modify the stored procedures without touching the web
> code" is completely backwards. Your web code is going to be
> changing all the time, because that's what people see and touch
> and is where they make change requests. If you've got stored
> procedures, you're going to have to change them to support the
> new web code, all the time. If you must use them, minimize them.
>    
See, I think this approach is somewhat backwards. Where possible, the 
DBA and the database should provide as much "service" to the web code. 
For instance:


select shopping_cart_contents($cart);

The function will return the contents of a cutomers shopping cart. Now, 
the whole implementation of shopping cart can change without affecting 
the web design.  I have actually done this and changed the whole 
shopping cart system out from under the app and had it work without any 
problems.

It is a well understood practice to isolate "knowledge of data 
structure" from the use of the data. Its just another API.
> -dsr-
>
>