Aumentar Velocidad en Proceso de Facturación

Dom Dic 01, 2013 3:04 pm

Buen Día

Tenemos un cliente de un supermercado que tiene un volumen considerable de operaciones al día, y se esta haciendo muy incomodo para sus clientes y ellos mismos la espera en el proceso de facturación, específicamente al momento de totalizar el documento y registrar el tipo de pago y finalizar la operación, tarda hasta 30 Segundos en realizar la impresión de la factura tomar el numero de la maquina fiscal y reaparecer el panel de datos del cliente para la nueva factura.

Este cliente tiene un servidor, una estación administrativa y3 puntos de venta cada uno con impresoras fiscales BIXOLON, que ya hemos aumentado la velocidad de los puertos "com" para tratar de solventar el problema, descargamos todo trabajo del servidor... no es operado por nadie para evitar cargas de procesos.

Se realizan recálculos de existencia diariamente, y de vez en cuando nosotros realizamos actualización de estructuras de datos , lo que ha funcionado medianamente bien para reordenar los datos, además hacemos un chequeo de las tablas en MySQL o optimización.

La pregunta final es: ¿ HAY ALGUNA MANERA DE ACELERAR EL PROCESO DE TOTALIZACIÓN DE LAS FACTURAS ?

para una posible solución: Se puede programas algún proceso adicional??, se puede aplicar alguna opción por MySQL a las tablas de movimiento?? se debe modificar algún campo clave en las tablas de MySQL??? hay que revisar algún problema en la conexión ODBC para acelerar los procesos???

agradezco cualquier ayuda e idea, si esta probada mejor... Gracias

Lun Dic 02, 2013 6:20 pm

Buenas noches wcarval ojala que den repuesta a ese problema por que tengo 3 clientes con la ultima version y esta terriblemente lento con respecto a las versiones anteriores como la 7x o las primeras 8x.
Yo creo que la lentitud se debe a estadisticas que el sistema envia por internet o por lo menos trata de enviar por internet.
Ya que no hay repuestas uno empieza a sacar conclusiones

Mar Dic 03, 2013 9:51 am

algo como este post te puede ayudar, solo hay que optimizar los indices de las tablas que en el proceso el sistema toca...

imagina que en un libro no tenga "indice"... es muy lento buscar una información, habría que irse secuencialmente ...
ahora con unos buenos indices... la cos cambia...

https://premiumsoft.superforo.net/t655-indice-en-al-tabla-opermv?highlight=indice

Saludos

Mar Dic 03, 2013 11:19 am

buenos dias syhcomputacion tengo un cliente que desde el primer dia es lento el proceso y arrancando desde 0

Mar Dic 03, 2013 11:40 am

hay muchos factores, memoria del equipo, procesador, etc .. etc ... pero si no tiene indices la tabla... es muy lento el proceso...

escríbeme a mi correo y cuadramos para ayudarte.

Saludos

Miér Dic 04, 2013 4:27 am

Gracias syhcomputacion tambien la lentitud esta en la interface del mismo sistema para ir de una opcion a otra es muy lenta, no como en las primeras 8x o la 7x tu salias de un menu a otro de una manera muy comoda y rapida.
Una pregunta tu tienes funcionando la ultima version de la 8x

Miér Dic 04, 2013 8:12 am

no, la ultima tiene algunos detalles que han sido reportados... estamos a la espera del reporte que esta al dia... pero no...

Vie Dic 13, 2013 4:37 pm

Feliz día.
No quiero sonar negativo. Pero no esperen ninguna respuesta de parte de Premium-Soft.
Yo tengo exactamente el mismo problema, inclusive pagando por el servicio, no pudieron resolver la lentitud en la facturación. Mantuve comunicación constante vía telefónica y Skype les di acceso a mi servidor, les pase el 100% de mi DB y simplemente de un día para otro dejaron de atenderme y no volvieron a contestar mis correos.
Les dije que no quería nada de gratis, que estaba dispuesto a pagar pero al parecer el programa tiene un serio problema cuando de trata de facturar en negocios de abarrotes; especialmente en facturación al crédito. Les comente lo que plantea syhcomputacion, referente a los índices, y me dijeron que eso no resolvería nada, que comprometería la estabilidad del programa, que ellos estaban trabajando en una solución. Eso nunca llego.
Ahora, syh computacion, se que el problema tiene que ver con las tablas opermv, operclit y operti.
Pero: ¿qué columnas indexar sin comprometer la estabilidad de la base de datos?

Saludes y felices fiestas.

Lun Dic 16, 2013 9:49 am

Cesar, contactame y revisamos que es lo que tienes... ya que si te pongo cuales columnas, y otras cosas por aca a los mejor queda algo en el aire y no resolvemos... escríbeme a mi correo para enviarte mi nro de cel para conversar..

Saludos

Vie Dic 20, 2013 10:01 am

Me pasó éste problema con un cliente que usa la versión 8.1 anterior a la publicada, desde el primer día. Usa una máquina fiscal Bixolon de matriz de puntos, y ahí al parecer está el talón de Aquiles, pues en otro punto de facturación con una Hasaar no presenta ése inconveniente. Inclusive, fue el técnico de la impresora Samsung y actualizó el firmware, probó otro cable y nada. Cuestión al momento de Obtener el Número de Factura Fiscal. Hoy día sigue sin solución.

Dom Ene 12, 2014 9:43 pm

buenas mi gente del foro buenoo yo tenia ese problema tambien sistema de facturacion lentooo,pateticoo,que lo que me probocaba era agarrar a patadas la pc..jajaja..

pero probando y probando...no me quedo otra opcion que la impresora fiscal,la envie para que me le hicieran servicio...al momento de probar el sistema nuevamente,quedo excelente ahora el proceso de facturacion dura unos 5 segundos para max 8 segundos y ya puedo seguir atendiendo a otro cliente...al parecer mi impresora necesitaba servicio..

espero ayudar..en mi experiencia.. saludos

Mar Ene 14, 2014 11:11 pm

Hola buenas hoy después de estar mucho tiempo fuera del aire, abarrotado de trabajo en unos cambios profundo en unas base de datos de unos clientes y desarrollado una especie de histórico de transacciones de Premium-Soft. Me puse a leer este apartado sobre la polémica que se siempre se destapa cuando se trata de la velocidad del sistema, en mi opinión muy personal y experiencia en este fascinante mundo de los sistemas hay algo que debemos de reconocer es que a medida que la bases de datos van creciendo el sistema se va poniendo lento y muy lento. ¿Cuáles son las posibles causas del problema?

1. El sistema operativo en la cual está instalada las Bases de Datos.
2. La cantidad de memoria RAM.
3. El tipo de instalación y configuración del MySQL.

¡Para entender un poco más de Bases de Datos MySQL! las tablas que utilizan Premium-Soft por ser transaccionales deben de utilizar un motor INNODB y por ser un motor para base de datos transaccionales sacrifica velocidad operativa ya que en comparación con otros motores de base de datos es el más lento de todos por su naturaleza. A esto se une una base de datos que en sus tablas de movimiento son muy grandes o sea que tienen muchos campos y cuando el sistemas las invoca para cualquier transacción por lo general se genera un cursor con dicha consulta y con la totalidad de sus campos por cada tabla que ella abre y si lo mescla con una maquina baja en recursos operativos como memoria RAM estos hace que su sistema sea un cacharro viejo y lento, por esta razón a medida que la base de datos comienza a crecer los problemas de rendimiento en el sistema. Otra razón clara es la arquitectura de MySQL que una vez que se configura el motor de INNODB MySQL genera un archivo de nombre ibdata1.log que va creciendo sin control por el tipo de configuración estándar de la instalación de la base de datos esto es otro flagelo y en otro apartado hablare mas de este archivo de su configuración y optimización del mismo para obtener más rendimientos positivos. También comparto el análisis de Richard Rojas (S & H Computación, C.A.) cuando se refiere a los índices pero esto es efectivo para consultar y generar repuestas rápidas de búsqueda de información, pero al tratar de insertar data al sistema con una operación de venta donde se involucran 6 tablas que se inserta información, se valida es donde uno dice para que me sirven los índices.
Recomendaciones:

Yo tengo varios clientes grandes que incluso trabajan con varias sucursales y están conectadas a un solo servidor con conexiones VPN y no dejo que sus data sobre pasen los 2 GB de información porque el sistema se me pone mongólico y muy lento y para ello es que realizo un histórico del sistema, apertura una nueva data y paso las tablas padres, cuentas por pagar y cuentas por cobrar liberando las tablas de movimiento para desahogar el sistema, claro está que esto no debería ser lo normal es solo un método que yo elabore para poder superar el flagelo de la lentitud del sistema a medida que vaya creciendo sus tablas de movimiento.
Desde ayer comencé hacer prueba y realice una serie de configuraciones donde pude alcanzar una mejora de nueve veces más rápido el acceso a la información con una data de un cliente que es bastante grande y la pruebas que llevo son bastantes satisfactorias y de seguir así pues en otro apartado le contare como me ha ido con la pruebas y para los interesados en saber cono optimizar la base de datos le tocara utilizar el comodín de llamar a un amigo para poder solventar un poco la lentitud del sistema actual.

Jesús E. Araujo G.
Ingeniería de Informática
yesusmen@gmail.com
Venezuela, Trujillo Edo. Valera

Miér Ene 15, 2014 9:06 pm

Saludos....

Excelente aporte Amigo Jesus....

Ahora bien... Pregunto lo siguiente: Que es una Base de Datos Grande?
Me atrevo a decir que la mayoria de los usuarios de PS y los que participamos en este foro, maneja una BD no mayor a 1Gb.... Por lo tanto, creo que ese seria el ultimo punto a atacar.

Por otra parte, el problema ha causado tanto alboroto porque en revisiones anteriores (inclusive la version 8 ), el sistema se estaba comportando de manera decente, lo que nos hace pensar que los programadores hicieron algo que esta perturbando el rendimiento del sistema.
Tambien asumo que los que han reportado problemas de velocidad ya han verificado parametros como el Hardware tanto de las estaciones de trabajo como de la red en si, RAM, etc.

Como experiencia puedo comentarte que una vez tuvimos instalada la base de datos bajo un servidor Linux y el rendimiento (en ese momento, bajo la version 7) no mejoro significativamente.

Nosotros manejamos una BD de en promedio 250 Mb, algo que me parece nada para un manejador de BD como MySQL, con todo y lo viejo que pueda ser, y con una carga de operaciones de alrededor 25 op/dia, en un ambiente de 10 WS.

Fijate por ejemplo que el amigo menciona la compatibilidad de la impresora. Claro en su caso es muy puntual porque necesita velocidad en este proceso. Yo particularmente trabajo mas que todo con presupuestos y compras, y el sistema de verdad se torna muy lento para cambiar entre un campo y otro.

Por lo tanto, insisto, el problema viene desde adentro. Desde los cambios o mejoras realizadas en una version, que han iniciado una reaccion en cadena y temo que en algun momento explote por el lado mas flaco. (lease, el usuario final).

Solo espero que PS responda antes...

Exito!

Jue Ene 16, 2014 7:42 pm

Buenas tardes, noches..

Revisando un poco sobre el tema, ya que nosotros utilizamos MySQL para otros sistemas propios los cuales, tienen años funcionando y no se nos ha presentado el problema de velocidad, encontre lo siguiente:

"InnoDB se utiliza en muchos grandes sitios de bases de datos que necesitan alto rendimiento. El famoso sitio de noticias de Internet Slashdot.org corre sobre InnoDB. Mytrix, Inc. almacena más de 1TB de datos en InnoDB, y otros sitios manejan una carga promedio de 800 inserciones y actualizaciones por segundo en InnoDB. "

El artículo completo en: http://dev.mysql.com/doc/refman/5.0/es/innodb-overview.html

Yo opino que pueden estar influyendo muchos factores, entre los cuales si analizamos los cambios de Premium, podemos ver el aumento de componentes gráficos, que lo hace ver muy bien, pero consume más recursos y las cargas de formularios son un poco mas lentas que antes. El antiguo Premium Adm 7x 2011.9.8 es de 6.774 kb y el actual de 13.141 kb. Aunque quizás la cuestión no esta en los kb sino en las imagenes utilizadas. Nosotros desarrollamos un sistema de taller bien complejo que el ejecutable tiene 30.993kb y funciona bien rapido.

Como han indicado algunos colegas, cada consulta es cargada a un cursor en memoria y si la consulta no esta bien estructurada lleva un tiempo mayor realizarla.

Por supuesto que la cantidad de memoria, el procesador, el sistema operativo influyen.

Otros de los cambios que han venido sucediendo es el crecimiento en campos de las tablas principales. Por ejemplo la tabla operti de la version 7x tenía 114 campos la actual es de 117. La tabla opermv era de 87 columnas y ahora es de 91 columnas. Unos autores dicen que no debería pasar de 60 campos y otros dicen que no importa para nada. Yo creo conveniente dividir las tablas.

Otro factor que es conocido y en la comunidad foxpro se comenta es que nuestras aplicaciones funcionan mejor con el odbc 3.51 que con los mas nuevos. Yo siempre utilizo la version 3.51.

El otro punto es los indices que deben ser analizados para mejorar el rendimiento, con respecto a esto hay mucha información (http://www.tufuncion.com/optimizar_mysql)

Lo cierto es que quien tiene la última palabra para dar una respuesta real y no nuestras suposiciones son el equipo de programadores, que saben todos los procesos que se ejecutan en cada operación. Que quizás muchos de ellos son transparentes a nuestra vista.

Saludos a todos

Jue Ene 16, 2014 9:40 pm

Okey segundo apartado de MySQL:

Para continuar y tratar de entender un poco sobre la Bases de Datos y los sistemas en el caso de Premium-Soft, quiero ser “eco” de un comentario que escuche en un congreso de bases de datos que asistí. “Nadie hace sistemas lentos y rápidos”, lo que se debe hacer es saber normalizar bases de datos y tratar de dividirlas cuando tienes muchos campos esto es parte de una buena normalización para optimizar el ancho de banda si el sistema está basado en la WEB y si es en una red local para optimizar el cursor que se aloja en la memoria de la maquina mejor conocido como Buffers.

Ahora bien voy a explicar un poco que es el Motor (engine), para MySQL cuando es creada fue concebido para el manejo de alto volúmenes de información estática y el motor nativo de esta base de datos es MyISAM, cuando me refiero a información estática es que solo un usuario puede realizar un operación tal como (Insert, Update, Delete),y se puede realizar esta tarea eficientemente ya que este motor cuando se realiza alguna de estas operaciones bloquea las tablas lo que nos indica que si otro usuario en ese momento solicita alguna otra operación distinta a los se le está efectuando en ese mismo momento el gestor de base de datos no le permite hacer nada hasta que la tabla se libere por completo y es por esta razón es que MyISAM a pesar de que es un motor nativo de MySQL no funciona en sistemas transaccionales. Es por ello que una empresa Alemana ve una gran potencialidad de en MySQL hace un motor completamente transaccional que cumpla las normas (ASID):

-Atomicidad: es la propiedad que asegura que la operación se ha realizado o no, y por lo tanto ante un fallo del sistema no puede quedar a medias.

-Consistencia: Integridad. Es la propiedad que asegura que sólo se empieza aquello que se puede acabar. Por lo tanto se ejecutan aquellas operaciones que no van a romper las reglas y directrices de integridad de la base de datos. La propiedad de consistencia sostiene que cualquier transacción llevará a la base de datos desde un estado válido a otro también válido.

-Aislamiento: es la propiedad que asegura que una operación no puede afectar a otras. Esto asegura que la realización de dos transacciones sobre la misma información sean independientes y no generen ningún tipo de error.

-Durabilidad: es la propiedad que asegura que una vez realizada la operación, ésta persistirá y no se podrá deshacer aunque falle el sistema.

INNODB es el nombre que se le da a este motor de base de datos y los programadores comienzan a utilizarlos en sistemas de información transaccionales ya que una de la propiedades principales de este motor es que los bloqueos lo realiza a nivel de registro y no de tabla, que dependiendo del aislamiento que se encuentra configurado permite las lecturas y escrituras dependiendo del caso y la norma adoptada por el programador, y otra propiedad importante que cuenta con un motor de base de dato en virtud de crear un bloque de transacción para garantizar la estabilidad de los datos, pero todas esta propiedades y virtudes son interesantes para sistemas como Premium-Soft realizar una aplicación en tres capas ya que el gestor de base de datos MySQL es gratuito y es el más utilizado en el mundo. Okey cuando me réferi a tres capas esto no es más que una arquitectura cliente-servidor que el objetivo primordial es la separación de la lógica de negocios de la lógica de diseño; un ejemplo básico de esto consiste en separar la capa de datos de la capa de presentación al usuario. O sea como se come esto es fácil cuando no utilizamos tantos términos de ingeniería de software solo es que el programador hace una capa o interface grafica es los que Ud. observan cuando ejecutan el sistema una belleza de interfaz grafica que Premium-Soft nos muestra a la vista, otra capa es la base de datos en este caso es MySQL y como ultima capa es la programación o negociación que se utiliza para conectar la capa grafica y la capa base de datos, que está condicionada a un gestor de fase intermedia llamado ODBC que es un estándar de acceso de base de datos desarrollado por SQL Access Group en 1992. Y como podemos analizar esto, para hacerlo fácil es una conexión que le permite a la aplicación conectar un modelo de negociación programada para alterar la base de datos como lo crea conveniente el fabricante de la aplicación en nuestro caso Premium-Soft. Esto hace que el recurso utilizado para mover todo lo que he venido hablando se requiere de buenas condiciones de Servidor (maquina que posea la base de datos) y los Clientes (maquina que ejecuta la aplicación y la información nos llega mediante consulta que se almacena en cursores y que a su vez de alojan en buffers un espacio de la memoria de la maquina local). Espero que me vayan entendiendo lo que he tratado de decir hasta ahora.

Observando el comportamiento y la arquitectura de la bases de datos realizadas por Premium-Soft obviamente carece de una normalización y sus tablas principales de movimiento constantes son tablas con demasiados campos que cuando se realiza una operación el cursor que genera es la totalidad de los campos de la tabla y dependiendo de lo que se está haciendo puede poner en el buffers una gran cantidad de datos que la maquinas mas pintadas puedan bajar su rendimiento. Esto es solo mi punto de vista, yo utilizo en las maquinas que instalo Premium-Soft sin importar el Windows que utilice siempre le configuró el config, agregando dos líneas (Files = 120 y Buffers = 35) para reservar memoria operativa para estos tipos de cursores que genera Premium-Soft en su arquitectura de software. Así que todo lo demás que si interface grafica e impresora fiscales no son un motivo de peso para la lentitud del sistema como lo ha expresado en los anteriores apartados o comentarios realizados.

Nota: en mi siguiente apartado revelare los avances realizados por la nueva configuración que he realizado a una base de datos que tienes más de 2 GB y se están comportando bastante bien alcanzado velocidades casi locales como si se estuvieran realizado en el mismo servidor.

Jesús E. Araujo G.
Ingeniería Informática
yesusmen@gmail.com
Venezuela, Valera Edo. Trujillo

Miér Jul 02, 2014 8:48 pm

La disminución de rendimiento es lamentablemente una falla común actualmente con el premium.

Con el tiempo he hecho pruebas con el sistema mediante los Logs de mysql y en varias ocasiones he observado que las consultas que el sistema realiza a la base de datos en algunos casos no son las óptimas, son correctas pero no hacen uso de una sintaxis mas sencilla que genere un cursor mas liviano que al mismo tiempo permita obtener los datos de forma mas eficiente.

Como todos sabemos el "*" no es la mejor manera de realizar un Select, esto empeora si nuestra consulta tiene algún JOIN, y mas aún si ese JOIN involucra dos o más tablas de gran tamaño (opermv, bonifven,kardex,operti por citar un ejemplo) al mismo tiempo es necesario tomar en cuenta que cuando realizamos una consulta el motor de mysql busca la forma mas sencilla de hacerlo, se vale de índices, de tipos de datos, incluso de la misma clave primaria (El cual es el primer índice de una tabla en mysql) si no se dan estas condiciones mysql termina consultando la tabla completa.

También he analizado procesos completos y he visto que Premium tiende a repetir muchas veces algunas sentencias select,delete,update de manera innecesaria y en otros casos que en el desarrollo de el proceso completo algunas sentencias son incluso redundantes.

Como se entenderá al generar constantemente cursores que se crean con las condiciones incorrectas citadas anteriormente por obviedad se obtendrá una baja del performance.

Nosotros mismos podemos hacer pruebas con los select y mysql nos explicará como está haciendo para suministrarnos resultados. Para eso existe la sentencia Explain Select la cual está bien documentada en la red.

Como comentan varios colegas los índices permiten mejorar el tiempo de respuesta, el problema es que para la inserción de datos tienen un efecto contrario porque al insertar un registro éste deberá actualizarse también en tantos indices como tenga la tabla, por lo que hay que tener sumo cuidado de no generarlos indiscriminadamente sobretodo en tablas gigantescas y que tengan muchas inserciones,deletes y updates concurrentes como opermv por citar un caso.

Todas estas son consideraciones constructivas para el departamento de desarrollo de Premium pero principalmente a todos los soportistas que trabajamos con éste software. Premium Soft debe escuchar a sus aliados integradores y clientes de lo contrario el efecto a futuro podría ser muy negativo.

Saludos Cordiales.

Jue Jul 03, 2014 6:19 am

Buen dia
De Hecho perdi una venta porque el cliente me dijo que no quiso el premiium porque es muy pesado y compro otra marca

Jue Jul 03, 2014 9:16 am

Creo que estas ultimas versiones estan muy bien de diseño, graficos, mensajes de publicidad, etc... hay una opcion de licencia donde esta puede ser patrocinada o no... cuando es patrocinada... la ventana de publicidad no aparece.... un consejo seria que aparte de desaparecer la ventana de publicidad, se debería ejecutar una versión mas liviana... menos gráficos, algo un poco mas plano (como hoy dia traen los telefonos, una version mas liviana que consuma menos memoria y bateria), ya que hoy dia las empresa buscan eficiencia en vez de belleza en las ventanas....es un consejo... y asi el que quiera algo mas liviano que compre la licencia patrocinada... y listo..

Saludos

Dom Jul 06, 2014 10:19 pm

Amigo Richard yo pienso igual que tu que debe tener una interfaz mas sencilla porque la actual esta demasiado cargada.

Sin embargo pienso que eso se puede palear ya adaptando las estaciones de trabajo a los requerimientos minimos actuales (4gb de ram y un procesador doble núcleo).

Pero en contra de esas consultas internas que no son eficientes en muchos casos no se puede hacer nada, eso se traga los recursos del mas poderoso servidor.

Un saludo

Dom Sep 21, 2014 4:56 pm

Yo solucione un problema parecido a tu caso con una instalación y configuración del sistema y un par de desarrollos verticales y el supermercado funciona muy bien. Llámame para asesorarte y llegues a u feliz término con tu cliente…

Jesus E. Araujo G.
Ingeniería Informática
Valera – Trujillo. Venezuela
Yesusme@gmail.com

Aumentar Velocidad en Proceso de Facturación

Aumentar Velocidad en Proceso de Facturación

Re: Aumentar Velocidad en Proceso de Facturación

Re: Aumentar Velocidad en Proceso de Facturación

Re: Aumentar Velocidad en Proceso de Facturación

Re: Aumentar Velocidad en Proceso de Facturación

Re: Aumentar Velocidad en Proceso de Facturación

Re: Aumentar Velocidad en Proceso de Facturación

Re: Aumentar Velocidad en Proceso de Facturación

Re: Aumentar Velocidad en Proceso de Facturación

Re: Aumentar Velocidad en Proceso de Facturación

Re: Aumentar Velocidad en Proceso de Facturación

Re: Aumentar Velocidad en Proceso de Facturación

Re: Aumentar Velocidad en Proceso de Facturación

Re: Aumentar Velocidad en Proceso de Facturación

Re: Aumentar Velocidad en Proceso de Facturación

Re: Aumentar Velocidad en Proceso de Facturación

Re: Aumentar Velocidad en Proceso de Facturación

Re: Aumentar Velocidad en Proceso de Facturación

Re: Aumentar Velocidad en Proceso de Facturación

Re: Aumentar Velocidad en Proceso de Facturación

Re: Aumentar Velocidad en Proceso de Facturación