Foros Club Delphi - El diseño de 3 capas es veloz? ¿Pros y contras?

Foros Club Delphi (https://www.clubdelphi.com/foros/index.php)

- Debates (https://www.clubdelphi.com/foros/forumdisplay.php?f=29)

- - El diseño de 3 capas es veloz? ¿Pros y contras? (https://www.clubdelphi.com/foros/showthread.php?t=94323)

El diseño de 3 capas es veloz? ¿Pros y contras?

Compañeros, buen día/tarde/noche, según aplique.

Les platico. En mi lugar de trabajo tenemos una aplicación de agroingeniería y control administrativo de préstamos (si la conocen, se llama SIAGRI de Biosalc), la cual hasta hace un par de semanas funcionaba de maravilla en lo general. Recientemente se propuso hacer un cambio de modelo de 2 capas a tres capas y nos deslumbraron con las "ventajas", entre ellas la velocidad de proceso...

No quiero hacer muy largo el cuento, pero hasta el momento NO HEMOS VISTO ningún incremento en la velocidad de procesamiento, antes bien, ahora las conexiones a la base de dato duran tanto como la vida de una mosca, lentas como el servicio burocrático y eso solamente en caso que logre conectarse a la base de datos. Así que regresaremos a dos capas, pero mi jefe estará muy atento a todos sus aportes en éste tema...

Por favor, ayúdenme a convencerlo que tres capas es muy útil, o que usar dos capas es lo mejor para usar nuestra aplicación...

Pienso que un modelo 2 capas, cliente/servidor, bien diseñado es funcionalmente mucho más simple y rápido, ya que 3 capas implica una capa más, y cuantas más capas, más lento.
Aparte de que la inmensa mayoría de diseños 3 capas son realmente 2 capas, porque finalmente acaban acumulando la "vista" y "controlador" en uno mismo.
Además, si el sistema que tenéis es funcional, ágil y trabaja bien, ¿para qué cambiarlo? Para que sea más rápido, lo dudo, ahora bien, si es por alguna funcionalidad que se necesite, pues bien, no quedaría más remedio.

Mientras mas componentes y puntos de "contacto" MENOR sera la velocidad LINEAL del proceso.

Eso es de lo mas obvio y elemental.

Lo que se puede mejorar (y eso es un posible que depende de...) es la ESCALABILIDAD de tipo HORIZONTAL, o sea, la capacidad de distribuir entre multiples procesos/equipos la carga. Pero eso aumenta la complejidad.

Hay carias "capas" y si uno tiene encuenta la arquitectura de los equipos de computo:

https://gist.github.com/jboner/2841832

Cita:

Latency Comparison Numbers (~2012)
----------------------------------
L1 cache reference 0.5 ns
Branch mispredict 5 ns
L2 cache reference 7 ns 14x L1 cache
Mutex lock/unlock 25 ns
Main memory reference 100 ns 20x L2 cache, 200x L1 cache
Compress 1K bytes with Zippy 3,000 ns 3 us
Send 1K bytes over 1 Gbps network 10,000 ns 10 us
Read 4K randomly from SSD* 150,000 ns 150 us ~1GB/sec SSD
Read 1 MB sequentially from memory 250,000 ns 250 us
Round trip within same datacenter 500,000 ns 500 us
Read 1 MB sequentially from SSD* 1,000,000 ns 1,000 us 1 ms ~1GB/sec SSD, 4X memory
Disk seek 10,000,000 ns 10,000 us 10 ms 20x datacenter roundtrip
Read 1 MB sequentially from disk 20,000,000 ns 20,000 us 20 ms 80x memory, 20X SSD
Send packet CA->Netherlands->CA 150,000,000 ns 150,000 us 150 ms

Notes
-----
1 ns = 10^-9 seconds
1 us = 10^-6 seconds = 1,000 ns
1 ms = 10^-3 seconds = 1,000 us = 1,000,000 ns

Credit
------
By Jeff Dean: http://research.google.com/people/jeff/
Originally by Peter Norvig: http://norvig.com/21-days.html#answers

O escalado:

Cita:

If L1 access is a second, then:

L1 cache reference : 0:00:01
Branch mispredict : 0:00:10
L2 cache reference : 0:00:14
Mutex lock/unlock : 0:00:50
Main memory reference : 0:03:20
Compress 1K bytes with Zippy : 1:40:00
Send 1K bytes over 1 Gbps network : 5:33:20
Read 4K randomly from SSD : 3 days, 11:20:00
Read 1 MB sequentially from memory : 5 days, 18:53:20
Round trip within same datacenter : 11 days, 13:46:40
Read 1 MB sequentially from SSD : 23 days, 3:33:20
Disk seek : 231 days, 11:33:20
Read 1 MB sequentially from disk : 462 days, 23:06:40
Send packet CA->Netherlands->CA : 3472 days, 5:20:00

Si fuera la MAXIMA velocidad, lo que hay que hacer:

Mantener todo lo posible en la CACHE de la CPU, con un mínimo de alocaciones
Usar SIMD si es posible (1er nivel de paralelismo)
Usar codigo sequencial y predecible (para que el branch predictor de la CPU sea feliz).
Procesar en "batch", lo anterior
Usar hilos (2d nivel de paralelismo) SI VALE LA PENA
Saturar todos los canales (CPU, DISCO, MEMORIA)

Lo cual apunta a un esquema 1/2 niveles maximo. 3 y mas es para explotar el 3/4 nivel de paralelismo (equipos y centros de datos).

Pero si manejas POQUITOS DATOS, como menos de lo que cabe en RAM o disco local, osea, poquito como terabytes? Mejor simple que complejo.

Cita:

Empezado por TiammatMX (Mensaje 534631)

Digamos que fue una salida en falso, pero no quiere decir que no sea el camnio. toda migración o nueva apuesta merece una oportunidad, máxime si los beneficios son conocidos.

Es posible que no hayan aplicado todas las buenas prácticas o por ahorrar esfuerzo, hayan coservado algunas funcionalidades o vicios del modelo de dos capas. (No se si sea el caso)

Hay que comprender que es un nuevo paradigma y por tanto hay que aceptarlo con sus reglas. Uno de los temas principales es la dependencia que tenemos con los DataSets y las conexiones vivas que nos permiten editar, eliminar e insertar con un minimo esfuerzo.

DataSnap y DCOM nos permiten a traves de Datamodulos remotos conservar esta dinàmica, pero esto implica también un tráfico de datos importante, de ahi que deba pensarse en cosas como consultas paginadas, si es necesario.

En cuanto a que los "deslumbraron con la velocidad de proceso", es relativo, se supone que si ganas velocidad al trasladar toda tu logica al servidor y dejar que allí suceda la magia, en lugar de hacer procesos en el cliente consultando repetidamente el servidor.

Las ventajas son claras, habria que revisar si la implementación es la correcta, o hasta que punto realmente se implementaron las tres capas.

Seria interesante concoer algo mas de la arquitectura,

Saludo,