Cuando hablais de rendimiento inaceptable, supongo que estamos hablando de aplicaciones Java que corren en la JVM del AS/400?
en este caso una soluci�n muy performante es tener la aplicaci�n en el PC
(que controla la versi�n y descarga automaticamente desde el AS las nuevas
versiones) atacando DB2/400, el acceso a los datos es muy.muy rapido..
pero.....
....si os hab�is fijado IBM nunca habla de aplicaciones Java corriendo el
JVM de AS, m�s bien de "front-end" ligero (ventana y validaciones de campo)
corriendo en local y atacando EJB (enterprise Java Beans) a trav�s de IIOP
que se est�n ejecutando en un servidor de aplicaciones Java (WebSphere)
a parte del hecho que esta arquitectura permite vender m�s licencias de
WAS, hay varias razones que la justifican:
- escalabilidad y disponibilidad, en grandes instalaciones puedo tener
aplicaciones clonadas por temas de rendimiento y disponibilidad
- logica de negocio unica, tanto la aplicaci�n corporativa cuanto las
intranets / extranets / internet / etc.. utilizan los mismos EJB que
contienen la logica de negocio
- estandardizaci�n, puedo utilizar componentes estandar (J2EE) y "web
services" (componentes disponibles en internet, por ejemplo para recuperar
las cotizaciones de bolsa o contenido, atacables directamente desde mi
servidor WAS) dentro de mi aplicaci�n corporativa sin necesidad de
adaptaci�n
en definitiva, es probable que todo esto suene a ciencia-ficci�n... per�
antes o despues tendremos que entrar en estos temas y personalmente no creo
que un proyecto de migraci�n progresiva de las aplicaciones corporativas
hacia Java sea absoltamente incompatible con el d�a a d�a.
mi opinion personal acerca de los "maquilladores" "migradores" u otros
"ameniculos" es que traen el "riesgo implicito" de depender del fabricante,
de la versi�n de windows, de la DLL "tal", de la versi�n de OS, etc... y
que al final lo que ayer funcionaba hoy ya no "tira"
un saludo,
Marco
(Embedded image moved to file: pic00491.gif)
Fernando P�rez
<[EMAIL PROTECTED]> To:
"'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
Sent by: cc:
forum.help400-request Subject: RE: Alguna reflexion
sobre rendimiento interactivo
@combios.es
08/11/02 12.07
Please respond to
forum.help400
Coincido plenamente contigo en que el rendimiento y tiempo de respuesta de
las aplicaciones java es inaceptable en la mayor�a de aplicaciones con gran
cantidad de interactividad (��Solo 0,2 segundos de diferencia java/pantalla
verde?? ��Donde hay que firmar?? :) ).
Realmente, el d�a que saquen algo que realmente 'adorne bien' las pantallas
verdes, y que con una descarga de un plugin o programa no muy grande
cualquiera pueda acceder a esas pantallas 'adornadas' desde la web, que se
quite lo dem�s.
Es curioso como cambian los criterios con el tiempo. Cuando yo estudiaba la
prioridad era 1:Correcto, 2:Eficiente, 3:'Bonito'. Ahora parece ser
1:Bonito (los dem�s dan igual al principio. Luego, cuando se implanta y va
lento hay quejas, y cuando 'misteriosamente' no funciona, asesinatos).
Respecto a la cuota de interactivo, lanzo una idea (totalmente filos�fica):
que los programas interactivos lancen sus tareas 'pesadas' como procesos
sometidos, esperando a que terminen dichos procesos para continuar cuando
sea necesario (habr�a que implementar una forma alternativa de paso de
par�metros y la sincronizaci�n de procesos). De esta manera se podr�a
evitar
sustancialmente la carga del interactivo. El �nico problemilla ser�a
cambiar
las X*10^N aplicaciones que tenemos por ah�, pero como a todos nos sobra
tiempo ... ;)
Saludos.
Fernando P�rez.
Cer�mica Saloni. Dpto. Sistemas
* : 964343434
<mailto:FPEREZ@;SALONI.COM>
-----Mensaje original-----
De: [EMAIL PROTECTED] [mailto:jbusquets@;grespania.com]
Enviado el: viernes, 08 de noviembre de 2002 11:16
Para: [EMAIL PROTECTED]
Asunto: Alguna reflexion sobre rendimiento interactivo
Como es viernes, y siguiendo la costumbre �del foro, ah� va un temilla de
fondo:
Est� de moda estos �ltmos meses el tema del rendimiento de los i-series,
especialmente en lo que respecta al entorno interactivo.
Me he animado a poner el tema encima de nuestra virtual mesa, para abrir ,
si quer�is un debate al respecto.
Propongo algunos puntos, sobre los que arrancar:
Desde la aparici�n de la penalizaci�n por carga interactiva, los clientes
hemos ido mostrando nuestro disgusto al respecto, y desde hace �poco
tiempo, parece que se nos est� oyendo..
Por un lado, tenemos en famoso Go Faster, del que ya se ha hablado largo y
tendido en este foro.
Hace bastantes a�os que ya v�, por otro lado, opciones alternativas, del
estilo de algunos maquilladores de pantalla que, al pasar a un formato
propietario la parte de presentaci�n, trabajaban en batch y no consum�an
recursos interactivos. Lo curioso es que, tras ver algunos anuncios, la
cosa cay� en el olvido... ni siquiera puedo recordar de que productos se
trata.
En Italia se present� alg�n producto, que no vi pasar de una fase
experimental, que, a trav�s de un cambio de la arquitectura de los
programas obten�a un resultado parecido. Pero creo que se ofertaba no como
un producto en venta, sino m�s bien como un servicio de reingenier�a de los
programas ya existentes.
Por otro lado , IBM , que se est� viendo el fregado, ha sacado algunos
equipos con bastante potencia interactiva con un descuento del 50%, como ya
sab�is. Como ya sabr�is tambi�n, la oferta tiene cierta "trampa", pues en
una gran cantidad de casos esto te obliga a cambiar de grupo de cargo del
SW, con el consiguiente incremento exponencial de costes de mantenimiento.
El otro d�a hab�an mensajes en el foro en que solicitaba "la carta a los
reyes", es decir, una herramienta que permitiera que las aplicaciones ya
existentes se ejecutasen sin carga de interactivo, y con pantalla bonita a
ser posible. (quiz�s muchos hemos so�ado con esta posibilidad, y , para
acabar de redondearla, que fuese barata, o la desarrollada por nosotros
mismos...en realidad lo complicado de esto es conseguir un "compilador de
DDS" , que permitiera que una aplicaci�n cliente hablase con los programas
RPG , que casi no habr�a que tocar.)
Hoy he visto el anuncio de un producto de este tipo, de Seagull, por lo que
promete, tiene muy buena pinta, pienso que habr�a que estar atentos a esto
(las caracter�sticas anunciadas se aproximan bastante a la "carta a los
reyes")... faltar�a saber su precio.
Por cierto, le� en News AS/400 que hace a�os que la acostumbrada mejora en
las relaciones precio/rendimiento de los as/400 se hab�a detenido en seco
hace dos o tres a�os. �Y el resto de los sistemas siguen a pleno
rendimiento la ley de moore! ��Nos estamos quedando atr�s?
Se puede hablar de tecnolog�as alternativas, a las que IBM nos quiere
llevar a la fuerza.. nosotros ya estamos probando alguna aplicaci�n con
Java, pero , la verdad, es que de momento lo veo mal en cuando a las
posiblilidades de migrar las aplicaciones de uso masivo a este entorno. Los
tiempos de respuesta me parecen inaceptables (m�s de 0.2 segundos ya
afentan fuertemente al rendimiento de los usuarios, aunque otro punto de
discusi�n ser�a esta m�trica)
Y una �ltima reflexi�n sobre el significado del l�mite interactivo. Tal
como se plantea por IBM, como una tabla de rendimiento de los trabajos en
interactivo y en batch, creo que lleva a enga�o: pongamos una m�quina
hipot�tica que tenga un rendimento de 1000 en batch y 40 en interactivo, la
pregunta es... �cu�n r�pidos van los trabajos interactivos?, o , de otra
forma, �que diferencia notar�an los usuarios con respecto a una m�quina con
1000 en batch y 1000 en interactivo?
Mi respuesta es que los usuarios no notar�an practicamente ninguna
diferencia: los trabajos interactivos se ejecutan a la plena potencia de la
m�quina, �y los tiempos de respuesta son acordes a la plena velocidad del
sistema... hasta que entra demasiada gente, con lo que se despierta el
CFINT y ya no se reparte m�s pastel.
Saludos a todos,
Jesus Busquets
Grespania, S.A.
_____________________________________________________
Forum.HELP400 es un servicio m�s de NEWS/400.
� Publicaciones Help400, S.L. - Todos los derechos reservados
http://www.help400.es
_____________________________________________________
Para darte de baja, env�a el mensaje resultante de pulsar
mailto:forum.help400-request@;combios.es?body=LEAVE
_____________________________________________________
Forum.HELP400 es un servicio m�s de NEWS/400.
� Publicaciones Help400, S.L. - Todos los derechos reservados
http://www.help400.es
_____________________________________________________
Para darte de baja, env�a el mensaje resultante de pulsar
mailto:forum.help400-request@;combios.es?body=LEAVE
<<attachment: pic00491.gif>>
