Programar en Linux

[Julio Pacheco]

Horst H. von Brand escribió:
> Germán Poó Caamaño <gpoo en ubiobio.cl> wrote:
> 
>>On Mon, 2006-10-23 at 14:00 -0300, Horst H. von Brand wrote:
>>
>>>Juan Martínez <jeugenio en umcervantes.cl> wrote:
>>>[...]
>>>
>>>>Un lenguaje compilado, en general, siempre (o casi siempre) sera la
>>>>mejor alternativa a usar.
>>>
>>>[...]
>>>
>>>>                          Sobre todo si es para un sistema complejo
>>>>(un SIA por ejemplo), dado que será mas rapido que un lenguaje
>>>>interpretado.
>>>
>>>Lo cual es totalmente irrelevante. Que el SIA se demore 0,5s o 0,01s en
>>>responder, si el perejil en la pagina web al otro lado de Chile luego pasa
>>>5s pensando que hacer a continuacion no hace particular diferencia. Si, si
>>>tienes decenas de miles de usuarios simultaneos es vital, pero eso se da
>>>solo cuando muestran los resultados de las elecciones ;-)
> 
> 
>>>[Si, /hay/ casos en los cuales el rendimiento realmente es crucial, pero
>>> son muchisisimos menos de lo que uno cree. Ve y mira la carga en tu
>>> "servidor" vecino, rara vez pasa del 40% en mi experiencia, tipicamente
>>> mucho menos...]
> 
> 
>>Esa postura, que si bien comparto en parte, es peligrosa.  Sobre todo en
>>manos inexpertas que pueden creerte a ojos cerrado todo lo que dices.
> 
> 
> Tienes razon con eso tambien...
> 
> 
>>Bajo esa lógica, hay muchos /ingenieros de software/ que los problemas
>>de rendimiento se lo achacan a la máquina, al sistema operativo, al
>>motor de base de datos o a lo "complejo del sistema".  Jamás al mal
>>diseño de sus algoritmos o de la lógica retorcida de sus propios
>>programas.
> 
> 
> Si, /vivamente/ recuerdo un caso de una generacion de listados que se
> demoraba horas (literalmente!), y eso /despues/ de multiplicar por 4 la
> maquina seguia en las mismas; una reestructuracion de las consultas a la BD
> bajo eso a cosa de un minuto. Tiempo invertido: Una media tarde...
> 
> [...]
[...]

Yo vi un caso similar: Servidor(*) con 8 CPU, harta RAM (32GB, si no me equivoco) y SAP.
Entrando en producción, empezó a quedarse chico, con tiempos de respuesta _Laaaargos_, 
etc,etc.
Según los desarrolladores: "es que las aplicaciones son complejas", "que a la máquina no 
le da", ... y todas las variantes del caso. Al final, querían ponerle la tercera system 
board (otras 4 CPU) y más memoria.

Fast forward unos cuantos días: llega el informe SAP Early Watch. Aparece que los 
programas Y y Z (aplicaciones desarrolladas localmente) se estaban comiendo casi el 80% de 
   la máquina. Revisando posteriormente, aparecen linduras como búsquedas en tablas 
_GRANDES_ de la base de datos ... sin índices, y dentro de loops... *ARGH*. Así no hay 
máquina que aguante.

(*) Sun Fire V1280