Pensamentos sutis sobre arquitetura de sites

Estamos em nosso WIT-e, é claro, amblers. Sistema ERP próprio (escrevi sobre isso aqui - Como podemos passar sem o 1C? ), Seu próprio sistema CRM, seu próprio M2M para comunicação com distribuidores ("que outras palavras e abreviações inteligentes você conhece?"). E, é claro, sua abordagem à WWW, para permanecer dentro da estrutura desse paradigma de três letras.

Tudo começou com o amor da Microsoft, e algumas das primeiras versões do site no final dos anos 90 foram feitas usando a tecnologia ASP e, como banco de dados, havia um arquivo regular do MS Access. A propósito, os provedores ainda oferecem hospedagem no bom e velho ASP, 18 anos após sua atualização para o ASP.NET - aqui você tem sistemas legados em toda a sua glória.

Em geral, isso é bastante conveniente - como o banco de dados interno também é escrito no MS Access, o procedimento para preparar dados para o site foi muito simples, sem reconversões de um formato de dados para outro (MySQL por exemplo). O Access suporta uma extensão da linguagem SQL no formato "IN <nome do banco de dados externo>", que pode ser adicionado após qualquer instrução DML: INSERT, UPDATE, DELETE (aqui está outra abreviação de três letras).

À medida que esse link cresceu, é claro, ele começou a desacelerar descaradamente (além dos que acontecem não são claros quando o arquivo mdb trava com o banco de dados trava o site inteiro). A tradução do site para o ASP.NET não resolveu o problema fundamentalmente, e também foi necessário mudar para o MS SQL Server como base, mas o processo seguiu uma direção diferente. Vejamos o problema de melhorar o desempenho do site de uma perspectiva um pouco diferente.

(A propósito, meu provedor de 1Gb.ru escreve que o ASP.NET é, em média, mais rápido que o pacote LAMP padrão (Linux / Apache / MySQL / PHP), que se tornou uma revelação para mim. Mas em quem posso confiar aqui, pois não é o operador de tudo isso? )

Isenção de responsabilidade - as idéias subsequentes representam, por um lado, alguma construção teórica elevada ao absoluto, o que muitas vezes significa reduzido ao absurdo, por outro lado, implementação concreta; portanto, não se pode dizer que o autor está em suas fantasias e completamente desapegado de realidade.

Pergunta 1. Por que deveria haver um banco de dados no site?

Bem, realmente todos vocês admiram a velocidade dos bancos de dados na memória, certo? Então, por que ir longe, consiga um direito no seu site. E ainda mais. Na inicialização, carregue todos os dados nas matrizes disponíveis no nível do site como um todo (objeto Aplicativo no ASP.NET, Variáveis ​​Globais no PHP, daqui por diante) e, em vez de escrever consultas no banco de dados, faça um loop entre essas matrizes. Tudo é adequado para o carregamento inicial de dados - o mesmo banco de dados do MS Access, mas pelo menos arquivos CSV de texto! - a operação é realizada com pouca frequência e seu tempo de execução não desempenha nenhum papel.

Existem perguntas, mas já temos respostas prontas para elas.

  1. , - , ? – ( , -), — ,
  2. ( ) . . – ( ) , ? , – / , – , . . Catalog ( -!) 2 – :



    MinIndex MaxIndex. , - ( ) – Parts ID Catalog, – .

Observe que essa ideia pode ser continuada ainda mais. Da mesma forma que os dados são transferidos do banco de dados sob o site para a estrutura de dados do próprio site, ao gerar uma página da Web, os dados precisam ser colocados em sua própria estrutura - ou seja, em matrizes JavaScript. E sem AJAXs, assincronia, tratamento de erros de comunicação e muito mais. E assim foi feito em nosso site em páginas contendo todos os tipos de configuradores.

A propósito, diferentemente dos arquivos de banco de dados, as matrizes na memória do servidor da Web (e também do navegador da Web, embora com reservas) ocupam um tamanho aproximadamente igual à sua representação binária, enquanto um banco de dados vazio com uma única tabela já se baseia em muitas centenas de kilobytes.

Pergunta 2. Por que preciso usar scripts em um servidor web?

Trago um pedaço de código em várias linhas, deliberadamente simplificado e na mais louca das linguagens de programação - VBA (exceto 1C)

        Set IE = CreateObject("InternetExplorer.Application")

        IE.Navigate "wit.ru"
        While IE.ReadyState < READYSTATE_COMPLETE
        Wend

        Set str = IE.Document.DocumentElement
        HTML = str.innerhtml

O código faz o seguinte - executa a página no navegador muito popular de uma empresa conhecida e salva o resultado da elaboração do script do servidor como HTML puro. Você adivinhou, provavelmente, o que será oferecido a seguir? Muito bem - é bem possível criar um site como HTML puramente nos anos 90.

(Novamente em 1GB.ru: “O IIS processa solicitações com rapidez e eficiência em arquivos estáticos”).

Ao mesmo tempo, pode ser necessário se preocupar em transcodificar endereços como
wit.ru/card.aspx?id=23&prodid=1022985
em endereços da Web estáticos O Pages também é uma conhecida tecnologia de ajuste de servidor da Web, originalmente inventada para enganar os mecanismos de pesquisa e a otimização da Web.

Aqui é necessário, provavelmente, formular o princípio básico do qual todos os outros são derivados. Quanto mais tempo e recursos gastamos na preparação de dados para o site, mais fácil será para ele exibi-lo e mais rápido ele será capaz de fazê-lo. Nesse caso, nosso back-end pode funcionar no modo contínuo, distribuindo dados prontos no site com a frequência necessária. E essa abordagem funcionará em todos os casos, exceto, é claro, trocas de resumos ou janelas de algumas Amazonas ou Alibaba, onde os dados mudam a cada segundo.

Conclusão


Estou ciente de que os problemas no artigo são muito pontudos e uma solução não padrão é proposta. Atrevo-me a sugerir (esse não é o meu tópico) que essa abordagem funcione para qualquer sistema embarcado; caso contrário, em um dispositivo de computação fraco, você precisará colocar um mini- mecanismo de banco de dados e um manipulador de scripts em vez do servidor Web mais simples (ao custo de mais consumo de memória - operacional e constante).

All Articles