![]() |
![]() |
![]() |
![]() |
![]() |
FTP | ![]() |
![]() |
CCD | ![]() |
![]() |
Buscar | ![]() |
![]() |
Trucos | ![]() |
![]() |
Trabajo | ![]() |
![]() |
Foros | ![]() |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
![]() |
|
Herramientas | Buscar en Tema | Desplegado |
#1
|
|||
|
|||
Verdaderas razones para no usar InterBase Open Source 6.0.1
Compañeros del foro,
Después de algo de investigación, no he podido encontrar razones de peso para migrar de InterBase Open Edition 6.0.1 a cualquier versión más reciente, ya sea Firebird o InterBase. Hablando única y exclusivamente de rendimiento, puro rendimiento en bruto, es decir sin tomar en cuenta todas esas nuevas características muy monas que tanto Firebird como InterBase han ido adquiriendo con el tiempo (capacidad multiprocesadores, extensiones al SQL-92, bonitas interfaces de la Consola de InterBase, etc.), no he podido encontrar información en la Internet sobre mejoras sustantivas en el rendimiento neto. Actualmente uso fervientemente InterBase Open Edition 6.0.1 de Borland y en estos momentos lo estoy utilizando para la aplicación más demandante que he tenido la oportunidad de desarrollar. Diariamente se insertan al rededor de 8,000 registros (en un año serán 3 millones, más o menos), en promedio se conectan al rededor de 15 clientes simultáneamente. La aplicación incluye algunos queries complejones que utilizan subqueries y a veces tardan hasta un minuto en arrojar los resultados. Como podrán ver la demanda de esta aplicación al pobre InterBase se describe como brutal, que digo brutal: "BESTIAL". Honestamente no podría decir que sienta que InterBase se esté quedando corto, de hecho tengo la oportunidad de migrar a SQL Server pero le tengo fe a InterBase y se que podrá con el castigo. De hecho ahora que lo pienso se supone que debería poder con eso y más; es más, siempre he pensado que InterBase tiene la misma capacidad que SQL Server... no sé por qué se me ocurrió esa idea de migrar a SQL Server. En fin, después de exponer el caso, lo que me gustaría saber es si Uds. piensan que podría obtener una mejora sustantiva en el rendimiento de mi aplicación si migro ya sea a Firebird o bien a la versión más actual del InterBase de "paga". Oigan... no me malentiendan. Yo sé que pues.. Firebird e InterBase 7.xx habrán incorporado muchas mejoras respecto a los "bugs"... es solo que necesito saber si hay una mejora sustancial en el rendimiento neto respecto a mi versión de InterBase... si ese es el caso, pues entonces migraré, ya que aunque actualmente InterBase me da el ancho (jaja, sin albures por favor), pues no me vendría nada mal una mejora respecto a los tiempos que mis clientes tienen que esperar para obtener los resultados de sus consultas. ¿Cómo ven? Saludos. Última edición por Equinoxe fecha: 25-01-2006 a las 03:50:39. |
#2
|
||||
|
||||
Si lees esto te convencerás de que firebird es bastante más rápido que interbase.
Uno de los principales motivos es la selección de los planes, en firebird "aciertan" mucho más que en interbase. Hace años que instalamos (donde trabajo) firebird a nuestros clientes (en lugar de interbase) y la primera impresión al empezar a trabajar los usuarios es: ¡¡¡ufff, qué diferencia, ahora va todo más rápido!!!. Pero si a tí te va bien tal y como está ahora... pues no lo cambies.
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal |
#3
|
|||
|
|||
Los de Borland dicen q IB7 es 2 veces mas rapido q IB6, los de Firebird dicen q fb1.5 es 30% mas rapido..
Es recomendable actualizar a fb ya es un RDBMS q tiene mucho futuro y gana cada vez mas en estabilidad.. |
#4
|
|||
|
|||
Conclusión
Creo que cualquier expectativa mía o de Uds. se ha quedado corta y con mucho.
Después de mucho pensarlo me decidí a hacer la prueba con Firebird... y obtuve rendimientos superiores al 600%!!! Algunos de los queries más lentos, con InterBase promediaban un tiempo de respuesta de 27 segundos. Con Firebird tarda 3.5 segundos. Los queries son los mismos, la base de datos (archivo GDB) es la misma, solo cambia el RDBMS, de InterBase a Firbird. No sé hasta qué punto mis tests reflejen la mejora real de rendimiento de Firebird respecto a InterBase, pero en un sentido práctico la diferencia ha sido... muy grande. |
#5
|
||||
|
||||
y es software libre
![]()
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal |
#6
|
||||
|
||||
Ten en cuenta que cada vez son mas comunes los equipos con caracteristicas multiprocesador, como hyperthreading, multiples procesadores por placa y los nuevos dual core de AMD e Intel.
Ademas lentamente estan los de 64 bits. Y ya que un equipo con mas de un procesador puede desempeñarse mejor y los equipos de 64 bits tienen a su alcanze un total de 4 GB POR APLICACION (versus solo 3 GB max por SISTEMA OPERATIVO) en un SO de 32 bits y un alcance de varios terabytes de RAM en uno de 64 bits, ademas de las mejoras al desempeño neto, y que un motor relacional esta en la categoria del softwarte que SI se beneficia de estas mejoras (junto a 3D, aplicaciones cientificas y servidores) tonces, no deberias descartar como mejora al desempeño el soporte que cada motor le esta dando a estas cosas. Por otro lado, en tu caso el asunto es muuuuyyy facil. Si esta bueno, no lo arregles, y si se necesita las cosas nuevas, la migracion DE iB 6 a cualquiera de los dos es de lo mas indolora posible.
__________________
El malabarista. |
#7
|
|||
|
|||
El cambio a Firebird ha sido una grata sorpresa... tanto en rendimiento como en transparencia en la migración.
|
#8
|
||||
|
||||
Cita:
¿Es así o es un problema de esos pcs?
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal |
#9
|
||||
|
||||
No de los PCs, sino de los sistemas de 32 bits+procesadores de 32 bits. De hecho, por defecto, es maximo asi:
1 GB RAM para el OS 2 GB RAM para el resto Para que queden 3 GB de RAM para el resto hay que configurar una opcion en el boot ini (que activa el soporte para maximo 3 GB). El asunto es que eso es un hack, y hay aplicaciones que se descontrolan por ello. Solo se que para SQL Server hay gente que activa esa opcion, porque SQL SERVER sabe como cojer esos 3 GB (o sea, que las aplicaciones normales solo pueden coger 2 GB RAM aunque haya mas instalada). Por el contrario, si el sistema CORRE sobre un procesador AMD 64 bits o uno Intel que NO sea el Itanium (porque el Itanium no soporta un SO de 32 bits), el SO puede darle los 4 GB enteros a cada aplicacion, sin problemas de compatibilidad ni reprogramacion alguna. En conclusion: SO 32 + Procesador 32 bits = MAX 2 GB RAM para aplicaciones y 3+ por medio de hacks o boards especializados SO 32 + Procesador hybrido 32/64 = MAX 4 GB por aplicacion. SO 64 + Procesador 64 = Creo que son 16 TB de RAM????
__________________
El malabarista. Última edición por mamcx fecha: 28-01-2006 a las 01:18:58. |
![]() |
|
|
![]() |
||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Como instalar BDE para una base de Interbase? | judoboy | Conexión con bases de datos | 2 | 16-07-2003 13:56:46 |
Libreria de UDF para interbase | chutipascal | Debates | 3 | 28-06-2003 14:28:33 |
Instalación Interbase 6.0 OPEN SOURCE en Windows 2000 | aglopez | Firebird e Interbase | 0 | 10-06-2003 17:12:34 |
Setrange para interbase | Giniromero | Conexión con bases de datos | 1 | 28-05-2003 14:59:54 |
Fisterra, ERP Open Source | kinobi | Noticias | 0 | 11-05-2003 11:29:44 |
![]() |
|