Nestas últimas duas semanas tive o prazer de começar a trabalhar com WEB Services, mais propriamente com SOAP, usando a library NuSOAP para PHP.
O projecto consistia em centralizar um número variável de bases de dados alojadas em vários locais espalhados por todo o país.
Tendo lido e ouvido falar sobre SOAP, decidi propor SOAP para se fazer essa centralização, ou pelo menos se fazer alguns testes para se verificar a capacidade do SOAP para fazer a transferência de uma grande quantidade de dados através de uma linha ADSL comum.
Quando falo em grandes quantidades de dados, refiro-me a tabelas de base de dados com cerca de 256 colunas ( vários tipos ) com mais de 150 mil linhas, este é um dos casos extremos, mas esta tabela virá a crescer diariamente.
Entretanto ficou outra pessoa responsável pelos testes e exemplos do SOAP, enquanto fiquei a tratar de outros assuntos urgentes.
Como se pode prever, os testes não foram bem efectuados ou totalmente efectuados, não se chegou a testar o envio de uma grande quantidade de dados.
Ou seja, quando se foi testar no servidor de produção, verificou-se que a maior parte dos pedidos excediam o tempo de timeout (30 segundos por default definido no NuSoap), como nesta altura já era eu que estava responsável pelo projecto, tive que assumir as responsabilidades.
Os pedidos estavam a demorar tanto tempo, porque para além de ser necessário enviar uma grande quantidade de dados, é necessário inserir os dados na base de dados central, o que ainda leva um certo tempo.
Depois de algumas pesquisas no Google ( o melhor amigo do programador actual ), descobri que para transferir grandes quantidades de dados o SOAP por HTTP, não deve ser usado para estes tipos de transferências, por uma série de razões, torna-se pesado para o servidor/local porque os pedidos têm de ser completamente carregados em memória antes de serem enviados e também introduz muito "overhead".
Para resolver o problema aumentou-se o tempo de timeout no SOAP para 60 segundos (algo completamente desconhecido pelo meu colega que fez os testes). E até ao momento parece que o problema ficou resolvido. Embora a centralização esteja algo lenta.
O conselho que posso dar em relação ao uso de SOAP, é que não pode ser usado para transferências de uma grande quantidade de dados ao mesmo tempo, como neste caso específico.
O problema maior neste projecto, foi a falta de investigação sobre a tecnologia que se ia usar, como é que ela se comporta em vários ambientes, resultando em vários problemas e dores de cabeça para mim.
Se a tecnologia tivesse sido testada convenientemente poderia-se ter aplicado de maneira diferente ou não ter-se-ia decidido não a usar para fazer a centralização. Poupando bastante tempo.
Será que é nestes pormenores que se distingue um bom programador de um mau programador? Esta será a programação para o próximo tópico deste blog, como distinguir um bom programador de um mau programador.
Em breve também um pequeno tutorial como usar SOAP em PHP usando a library NuSoap.
O projecto consistia em centralizar um número variável de bases de dados alojadas em vários locais espalhados por todo o país.
Tendo lido e ouvido falar sobre SOAP, decidi propor SOAP para se fazer essa centralização, ou pelo menos se fazer alguns testes para se verificar a capacidade do SOAP para fazer a transferência de uma grande quantidade de dados através de uma linha ADSL comum.
Quando falo em grandes quantidades de dados, refiro-me a tabelas de base de dados com cerca de 256 colunas ( vários tipos ) com mais de 150 mil linhas, este é um dos casos extremos, mas esta tabela virá a crescer diariamente.
Entretanto ficou outra pessoa responsável pelos testes e exemplos do SOAP, enquanto fiquei a tratar de outros assuntos urgentes.
Como se pode prever, os testes não foram bem efectuados ou totalmente efectuados, não se chegou a testar o envio de uma grande quantidade de dados.
Ou seja, quando se foi testar no servidor de produção, verificou-se que a maior parte dos pedidos excediam o tempo de timeout (30 segundos por default definido no NuSoap), como nesta altura já era eu que estava responsável pelo projecto, tive que assumir as responsabilidades.
Os pedidos estavam a demorar tanto tempo, porque para além de ser necessário enviar uma grande quantidade de dados, é necessário inserir os dados na base de dados central, o que ainda leva um certo tempo.
Depois de algumas pesquisas no Google ( o melhor amigo do programador actual ), descobri que para transferir grandes quantidades de dados o SOAP por HTTP, não deve ser usado para estes tipos de transferências, por uma série de razões, torna-se pesado para o servidor/local porque os pedidos têm de ser completamente carregados em memória antes de serem enviados e também introduz muito "overhead".
Para resolver o problema aumentou-se o tempo de timeout no SOAP para 60 segundos (algo completamente desconhecido pelo meu colega que fez os testes). E até ao momento parece que o problema ficou resolvido. Embora a centralização esteja algo lenta.
O conselho que posso dar em relação ao uso de SOAP, é que não pode ser usado para transferências de uma grande quantidade de dados ao mesmo tempo, como neste caso específico.
O problema maior neste projecto, foi a falta de investigação sobre a tecnologia que se ia usar, como é que ela se comporta em vários ambientes, resultando em vários problemas e dores de cabeça para mim.
Se a tecnologia tivesse sido testada convenientemente poderia-se ter aplicado de maneira diferente ou não ter-se-ia decidido não a usar para fazer a centralização. Poupando bastante tempo.
Será que é nestes pormenores que se distingue um bom programador de um mau programador? Esta será a programação para o próximo tópico deste blog, como distinguir um bom programador de um mau programador.
Em breve também um pequeno tutorial como usar SOAP em PHP usando a library NuSoap.
