Escalabilidade de Aplicações Web
Quando se trata de desenvolvimento de aplicações web, escalabilidade é um dos tópicos mais importantes. Aplicações web são projetadas para atender muitos usuários. Enquanto para algumas apps poucos usuários simultâneos podem ser o máximo, para outras aplicações 100 pode ser o mínimo. É uma das principais diferenças entre um app desktop e uma aplicação web. Um app desktop atende um usuário por vez, mas uma aplicação web atende múltiplos usuários simultaneamente. À medida que o número de usuários cresce, problemas de escalabilidade podem começar a surgir. Muitos desses problemas estão relacionados a um design de aplicação com falhas. Uma aplicação web deve ser capaz de atender múltiplas sessões simultâneas e deve cuidar do aumento no uso de recursos.
Considere que você está portando uma aplicação desktop para uma aplicação web. Na sua aplicação desktop, você tem um TDataset e um TDBGrid que carregam todas as linhas disponíveis de uma tabela. Agora suponha que cada vez que uma nova sessão inicia, milhares de linhas são buscadas da tabela e adicionadas ao grid. Considere que cada vez que a tabela fica ativa, ambas as estruturas de dados podem consumir até alguns megabytes de memória. Isso não seria um problema se fosse um aplicativo desktop, já que todos os recursos do sistema poderiam pertencer ao app desktop. No entanto, em uma aplicação web, cada nova sessão consumirá essa quantidade de memória. Nesse caso, se você tem 100 sessões ativas e cada sessão consome 10 MB de RAM, a memória total necessária será 100 x 10 = 1.000 MB = 1 GB.
Como você pode ver, o consumo de memória pode se tornar enorme se suas sessões não forem otimizadas para o uso de recursos. Isso mostra a importância da otimização de recursos para aplicações onde a escalabilidade é importante. Podem existir casos onde a escalabilidade não tem a maior prioridade. Por exemplo, se você desenvolve uma aplicação web para um sistema com até 10 usuários, escalabilidade não é um problema, mas para uma aplicação web onde 100 usuários são o mínimo, o gerenciamento de recursos deve garantir que sua aplicação nunca fique sem recursos.
A Stress Test Tool pode ajudar a encontrar problemas de escalabilidade. Executar um teste de estresse pode mostrar precisamente a quantidade máxima de memória que seu servidor consumirá quando um certo número de sessões estiver em execução. Pode ser usado para testar sua aplicação web em um cenário de pior caso e verificar se ela passa no teste sob tais condições raras. Se sua aplicação conseguir passar no stress test, estará pronta para ser implantada em um ambiente de produção.
O próprio uniGUI é otimizado em muitos aspectos para lidar com recursos. Para dar alguns exemplos, ele armazena bitmaps em arquivos de cache, cria forms quando abertos e os destrói quando o usuário os fecha, mantém ImageLists em arquivos de cache, etc. Da mesma forma, desenvolvedores devem considerar adotar um Create Resource on Demand princípio para otimizar o uso de recursos.
Um bom exemplo podem ser tabelas de banco de dados e datasets relacionados. Em uma abordagem clássica Delphi, um desenvolvedor pode colocar o componente de conexão e todos os datasets relacionados em um DataModule, mas em uniGUI isso forçaria a criação de todos os datasets toda vez que uma nova sessão fosse iniciada. Isso traria ainda mais problemas se os datasets estiverem Active por padrão.
No uniGUI a abordagem correta é colocar os componentes de conexão no MainModule e colocar os datasets nos forms ou em DataModules pertencentes aos forms. Quando você coloca um dataset em um form, ele será criado quando o form for mostrado e destruído quando o form for fechado. Essa abordagem otimizará o uso de memória relacionado aos datasets.