Estamos en nuestro WIT-e, por supuesto, amblers. Sistema ERP propio (escribió aquí: ¿cómo podemos prescindir de 1C? ), Su propio sistema CRM, su propio M2M para comunicarse con los distribuidores ("¿qué otras palabras y abreviaturas inteligentes conoce?"). Y, por supuesto, su enfoque de la WWW, permanecer en el marco de este paradigma de 3 letras.Todo comenzó con un amor por Microsoft, y algunas de las primeras versiones del sitio a finales de los 90 se hicieron utilizando la tecnología ASP, y como una base de datos debajo de ella se encontraba un archivo regular de MS Access. Por cierto, los proveedores aún ofrecen alojamiento en la buena ASP anterior, 18 años después de su actualización a ASP.NET, aquí tiene sistemas heredados en todo su esplendor.En general, esto es bastante conveniente: dado que la base de datos interna también está escrita en MS Access, el procedimiento para preparar los datos para el sitio fue muy simple, no hubo retraducciones de un formato de datos a otro (MySQL, por ejemplo). Access admite una extensión del lenguaje SQL de la forma "IN <nombre de la base de datos externa>", que se puede agregar después de cualquier instrucción DML: INSERTAR, ACTUALIZAR, ELIMINAR (aquí hay otra abreviatura de 3 letras).A medida que este enlace creció, por supuesto, comenzó a desacelerarse descaradamente (además, los que suceden no están claros cuando el archivo mdb se bloquea con la base de datos bloqueando todo el sitio). La traducción del sitio a ASP.NET no resolvió fundamentalmente el problema, y también fue necesario cambiar a MS SQL Server como base, pero luego el proceso fue en una dirección diferente. Veamos el problema de mejorar el rendimiento del sitio web desde una perspectiva ligeramente diferente.(Por cierto, mi proveedor de 1Gb.ru escribe que ASP.NET es en promedio más rápido que el paquete LAMP estándar (Linux / Apache / MySQL / PHP), que se ha convertido en una revelación para mí. Pero, ¿en quién puedo confiar aquí, ya que no es el operador de todo? )Descargo de responsabilidad : las ideas posteriores representan, por un lado, alguna construcción teórica elevada a lo absoluto, lo que a menudo significa reducción a lo absurdo, por otro lado, implementación concreta, por lo que no se puede decir que el autor esté en sus fantasías y completamente separado de realidad.Pregunta 1. ¿Por qué debería haber una base de datos debajo del sitio?Bueno, realmente, todos admiran la velocidad de las bases de datos en memoria, ¿verdad? Entonces, ¿por qué ir lejos? Obtenga uno justo debajo de su sitio web. Y aun más. En la inicialización inicial, cargue todos los datos en las matrices disponibles a nivel de sitio en su conjunto (objeto de aplicación en ASP.NET, variables globales en PHP, en adelante en todas partes), y en lugar de escribir consultas en la base de datos, simplemente repita estas matrices. Cualquier cosa es adecuada para la carga de datos inicial: ¡la misma base de datos de MS Access, pero al menos archivos de texto CSV! - la operación se realiza con poca frecuencia y su tiempo de ejecución no juega ningún papel.Hay preguntas, pero ya tenemos respuestas preparadas para ellas.- , - , ? – ( , -), — ,
- ( ) . . – ( ) , ? , – / , – , . . Catalog ( -!) 2 – :
MinIndex MaxIndex. , - ( ) – Parts ID Catalog, – .
Tenga en cuenta que esta idea puede continuar más. De la misma manera que los datos se transfieren desde la base de datos debajo del sitio a la estructura de datos del sitio en sí, al generar una página web, los datos que necesita se deben colocar en su propia estructura, es decir, en matrices de JavaScript. Y no hay AJAX, asincronía, manejo de errores de comunicación y más. Y así se hizo en nuestro sitio en páginas que contienen todo tipo de configuradores.Por cierto, a diferencia de los archivos de base de datos, las matrices en la memoria del servidor web (y también el navegador web, aunque con reservas) ocupan un tamaño aproximadamente igual a su representación binaria, mientras que una base de datos vacía con una sola tabla ya se basa en muchos cientos de kilobytes.Pregunta 2. ¿Por qué necesito usar scripts en un servidor web?Traigo un fragmento de código en varias líneas, deliberadamente simplificado y en el lenguaje de programación más loco: VBA (excepto 1C) Set IE = CreateObject("InternetExplorer.Application")
IE.Navigate "wit.ru"
While IE.ReadyState < READYSTATE_COMPLETE
Wend
Set str = IE.Document.DocumentElement
HTML = str.innerhtml
El código hace lo siguiente: ejecuta la página a través del navegador una vez muy popular de una empresa conocida, y guarda el resultado de calcular el script del servidor como HTML puro. Lo has adivinado, probablemente, ¿qué se ofrecerá a continuación? Muy bien: es muy posible crear un sitio tan puramente HTML en los viejos años 90.(Nuevamente, de 1GB.ru: "IIS procesa de manera muy rápida y eficiente las solicitudes de archivos estáticos").Al mismo tiempo, es posible que deba preocuparse por la transcodificación de direcciones comowit.ru/card.aspx?id=23&prodid=1022985en direcciones web estáticas páginas web también es una conocida tecnología de ajuste de servidores web, originalmente inventada para engañar a los motores de búsqueda y la optimización web.Aquí es necesario, probablemente, formular el principio básico del cual se derivan todos los demás. Mientras más tiempo y recursos gastemos en la preparación de datos para el sitio web, más fácil será para él mostrarlos y más rápido podrá hacerlo. En este caso, nuestro back-end puede funcionar en modo continuo, escupiendo datos listos en el sitio con la frecuencia que necesitamos. Y este enfoque funcionará en todos los casos, excepto, por supuesto, intercambiar resúmenes o ventanas de algunos Amazon o Alibaba, donde los datos cambian cada segundo.Conclusión
Soy consciente de que los problemas en el artículo son demasiado precisos y se propone una solución no estándar. Me aventuraré a sugerir (este no es mi tema en absoluto) que este enfoque podría funcionar para cualquier sistema embebido, donde de lo contrario, en un dispositivo informático débil, debe colocar un mini motor de base de datos y un controlador de script en lugar del servidor web más simple (a costa de más consumo de memoria: operacional y constante).