Este artigo est� escrito em Ingl�s e Portugu�s
English version:
A recent thread in the IIUG mailing list (relative to a reverse DNS issue) reminded me of a new Panther (version 11.7) functionality that was on my list for articles. I've been avoiding many of the bigger and more important features because they will take a lot of time to write about... I hope this one will be shorter.
Informix needs to read several files or interact with DNS servers each time you try to open a connection. Considering Unix and Linux (Windows is a bit different technically, but not that much conceptually), these are some of the actions the engine must do:
- Depending on your host resolution criteria it will probably open the /etc/hosts file to search for your client's IP address. If it's not there it will contact your DNS server in order to request the name associated with the IP address.
Note that all this is done by a system call. - It will access /etc/passwd (or equivalent) to get your user details (HOME dir, password - this is probably stored in another file like /etc/shadow - , user id, group id etc.)
Depending on your environment these activities can take a bit of time, and require some significant CPU usage. There are systems with high number of connections per second which can naturally transform this into a significant issue.
To give you an example I do regular work on a system that used to receive a very large number of requests from CGI programs. So, each request received by HTTP required a new process on the application server, and a new connection on the database server. They had peaks of tens of requests per second. Currently they're using Fast CGI with noticeable improvements.
Anyway, IBM decided to give us the chance to optimize this by caching previous results (file searches and DNS requests). This is done with the new parameter called NS_CACHE (from Name Service Cache). The format of this $ONCONFIG parameter is:
host=num_secs,services=num_secs,user=num_secs,group=num_secs
Each comma separated pair (functionality=num_secs) configures the number of seconds that the engine will cache a query result for that functionality. I'm calling it functionality, because it can be implemented through files or system APIs. The documentation could be clearer, but let's check each one:
- host
This is the host and IP address resolution service. Depending on your system configuration (on most Unixes and Linux this is specified in /etc/nsswitch.conf) it can be resolved by reading the /etc/hosts file and/or making a request to your DNS servers - service
This should be the map between service names and system ports, usually done by reading /etc/services. The only situation that comes to my mind where this is used is when you're trying to start a listener (either during engine startup or after that with onmode -P) or when you're trying to make a distributed query to another engine, and you use names in your INFORMIXSQLHOSTS instead of port numbers. In any case, I may be missing something... - user
This is very important. It refers to all the user related info that Informix gathers from the OS and that is relevant to Informix. The information can be stored in /etc/passwd, /etc/shadow, or indirectly be managed by external services like LDAP. It can include:
- Home dir
- User ID
- Group ID
- Password
- User status (enable or disable - group
This relates to the OS group information. Usually done by reading /etc/group
The parameter can be changed online with onmode -wm
It's important that you fully understand the implications of caching these kind of information. By asking Informix to cache this info, we're also assuming the risk of working with stale information. Let's imagine a simple scenario. Assume this sequence of events:
- At time T0 you connect using user and password to the engine which is setup to cache user information for 600s (10 minutes).
- At time T1 you change that user password
- At time T2, the same user tries to connect to the Informix database with the new password. It will fail!
- At time T3 (T0 + the number of seconds to cache user information) the user repeats the connection attempt with the new password. It will succeed!
If for example you do some changes to your user's information you can run:
onmode -wm NS_CACHE="host=900,service=900,user=0,group=900"
onmode -wm NS_CACHE="host=900,service=900,user=900,group=900"
These commands will flush the user information cache, and then reactivate it.
So, the point I'd like to make is that this feature can help you improve performance (specially for systems with an high connection rate), but it can have some side effects. You can workaround these ones, but for that you must know they exist.
Vers�o Portuguesa:
Uma discuss�o recente na lista de correio do IIUG (relativa a um problema com reverse DNS) lembrou-me de uma funcionalidade nova do Panther (vers�o 11.7) que estava na minha lista de temas a abordar. Tenho andando a evitar muitas das maiores e mais importantes novidades porque vou demorar bastante tempo a escrever sobre elas.... Espero que esta seja mais reduzida.
O Informix tem de ler diversos ficheiros ou interagir com servidores de nomes (DNS) cada vez que abre uma conex�o. Considerando o Unix e Linux (em Windows ser� um pouco diferente tecnicamente, mas n�o muito conceptualmente), estas s�o as ac��es que o motor tem de fazer durante o estabelecimento de uma conex�o:
- Dependendo do crit�rio usado para resolver endere�os e nomes, provavelmente ir� abrir o ficheiro /etc/hosts para procurar o IP da conex�o. Se n�o o encontrar ir� provavelmente contactar o servidor de nomes (DNS) e pedir o nome associado ao IP de onde chega a conex�o.
Note-se que isto � feito com uma chamada de sistema e n�o cabe ao Informix definir os crit�rios. - Ir� aceder ao /etc/passwd (ou equivalente) para obter os dados do utilizador (HOME dir, password - isto deve estar guardado noutro ficheiros como o /etc/shadow- , id de utilizador, id de grupo etc.)
Dependendo do seu ambiente estas opera��es podem demorar um pouco e requerer um consumo de CPU relevante. Existem sistemas com muitas conex�es novas por segundo o que naturalmente pode transformar isto num problema s�rio.
Para dar um exemplo, trabalho regularmente com um sistema que em dada altura recebia um enorme n�mero de pedidos por CGI. Sendo CGI, cada pedido recebido via HTTP requeria um novo processo na m�quina do servidor aplicacional, e uma nova conex�o na base de dados. Tinham picos de dezenas de liga��es por segundo. Actualmente est�o a usar Fast CGIs com benef�cio not�rios.
De qualquer forma a IBM decidiu dar aos utilizadores a oportunidade de optimizarem estes aspectos, atrav�s de uma cache que guarda respostas anteriores (pesquisas em ficheiros e resultados de DNS). Isto � feito com um novo par�metro designado NS_CACHE (de Name Service Cache). O formato do par�mtro do $ONCONFIG �:
host=num_segs,services=num_segs,user=num_segs,group=num_segs
Cada par (funcionalidade=num_segs) separado por v�rgula, configura o n�mero de segundos durante os quais o motor ir� manter em cache o resultado de uma pesquisa para essa funcionalidade. Estou a chamar-lhe "funcionalidade", porque pode ser implementada usando ficheiros ou APIs de sistema. A documenta��o deveria ser mais clara, mas vamos ver cada uma:
- host
O servi�o de resolu��o de nomes e endere�os IP. Conforme a configura��o do seu sistema (na maioria dos Unixes e Linux isto � definido em /etc/nsswitch.conf) pode ser resolvido pelo ficheiro /etc/hosts ou fazendo um pedido aos servidores de DNS - service
Este � o mapeamento entre o nome de servi�os e as portas de sistema, habitualmente feito atrav�s da leitura do ficheiro /etc/services. As �nicas situa��es que me ocorrem em que isto � usado � quando arrancamos com um listener (seja no arranque do motor ou depois quando se usa o onmode -P), ou quando tentamos executar uma query distr�buida a outro motor, e usamos nomes no nosso INFORMIXSQLHOSTS em vez de n�meros de portos. Mas pode estar a escapar-me alguma coisa, e haver outras... - user
Este � muito importante. Refere-se a toda a informa��o relativa aos utilizadores que o Informix obt�m do sistema operativo e que � relevante para o Informix. A informa��o � guardada no /etc/passwd e /etc/shadow, ou gerida indirectamente em servi�os externos como LDAP. Pode incluir:
- Home dir
- ID de utilizador
- ID de grupo
- Palavra passe
- Estado do utilizador (activo, inactivo) - group
Isto diz respeito � informa��o de grupos do sistema operativo. Normalmente feito por consulta ao ficheiro /etc/group
O par�metro pode ser modificado online com o comando onmode -wm
� importante que entenda completamente todas as implica��es de fazer caching deste tipo de informa��o. Ao pedir ao Informix que guarde e reutilize a informa��o j� obtida, estamos tamb�m a assumir o risco de trabalhar com informa��o entretanto desactualizada. Vamos imaginar um cen�rio simples. Consideremos a seguinte sequ�ncia de eventos:
- No momento T0 conectamo-nos usando um utilizador e palavra chave a um motor configurado para efectuar caching por 600 segundos (10 minutos).
- No momento T1 mudamos a palavra chave desse mesmo utilizador.
- No momento T2 o mesmo utilizador tenta conectar-se ao Informix usando a nova palavra chave. Vai falhar!
- No momento T3 (T0+ o n�mero de segundos configurado para a cache de utilizador) o utilizador repete a tentativa de acesso com a nova palavra chave. Vai ter sucesso!
Se por exemplo efectuar mudan�as na informa��o dos utilizadores, pode executar:
onmode -wm NS_CACHE="host=900,service=900,user=0,group=900"
onmode -wm NS_CACHE="host=900,service=900,user=900,group=900"
Estes comandos fazem a limpeza da informa��o e depois re-activam a cache.
Portanto, o ponto que gostaria de frisar � que esta funcionalidade pode melhorar o desempenho (especialmente em sistemas com elevada frequ�ncia de novas conex�es), mas tamb�m pode ter efeitos secund�rios. Estes podem ser contornados, mas para isso temos de saber que existem.
