3. MWS NGINX
Proyecto de código abierto
https://nginx.org/en/docs/
Servidor web, proxy HTTP y correo
Event Drive y asíncrono*
Presenta buen rendimiento y escalabilidad
(problema C10K: https://es.wikipedia.org/wiki/Problema_C10k)
Modular
Proceso master y varios procesos
worker
HTTP2
*Comparativa con Apache https://anturis.com/blog/nginx-vs-apache/
introducción
5. MWS nginx
sudo apt-get install nginx (como el resto)
Proceso master: debe iniciarse como 'root'
Procesos workers: se inician por master con
usuario indicado en configuración.
Ficheros configuración (puede cambiarse)
l
/etc/nginx/nginx.conf: configuración básica
l
mime.types
l
fastcgi_params:
l
Proxy.conf
l
sites.conf
Podemos tener más con directiva include:
include otra_configuracion.conf;
include sites/*.conf;
Configuración
6. MWS nginx
Directivas:
l
worker_processes: Número máximo de
procesos para el servidor web. ¿Cuál?
Recomendación:
grep processor /proc/cpuinfo | wc -l
l
worker_connections: Número máximo de
conexiones simultáneas para workers
l
keepalive_timeout: Tiempo de espera (75”
por defecto)
l
user nobody nobody;
l
error_log logs/error.log;
l
pid logs/nginx.pid;
Directivas de configuración
7. MWS nginx
Directivas, sintaxis:
l
k, m, g (K, M, G) kilobytes, Mega, Giga→
l
ms,s,m,h,d-> Milisegundos, segundos, minutos,
horas, días
l
w, M, y semanas, meses, años→
Variables: pueden ser usadas en la definición de
valores de las directivas. Siempre comienzan con $.
l
Referidas a las cabeceras cliente: $http_hosts,
$http_user_agent, $http_referer,
$http_x_forwarded_for (ip del cliente si está tras
proxy), $http_cookie, $http_ (para cabeceras
adicionales enviadas por cliente, con nombre
cabecera en minúsculas y '-' remplaza a '_')
l
$nginx_version
Configuración: variables
8. MWS nginx
Sobre las cabeceras de respuesta:
l
$sent_http_content_type
l
$sent_http_content_length
l
$sent_http_location
l
$sent_http_last_modified
l
$sent_http_connection (si keepalive o cerrada)
l
$sent_http_keep_alive (tiempo que estará “viva”)
l
$sent_http_transfer_encoding
l
$sent_http_cache_control
l
$sent_http_
Configuración: variables
9. MWS nginx
Sobre Nginx
l
$arg-XXX: query_string con XXX el nombre
parámetro
l
$args: todos los args de query_string
l
$binary_remote_addr: IP en binario (4 bytes)
l
$body_bytes_sent: número bytes (sin cabeceras)
l
$bytes_sent: total
l
$connection: num serie que identifica la conexión
l
$connection_requests: num request de conexión
activa
l
$cookie_XXX: acceso a cookies, con XXX nombre
l
$document_root
l
$host: la de la cabecera HTTP
l
$hostname: del servidor
l
$https: se usa o no (vacía)
Configuración: variables
10. MWS nginx
Sobre Nginx
l
$limit_rate
l
$msec: tiempo actual en ms
l
$remote_addr, $remote_port,
$remote_user, $query_string,
$request_method,....
l
$status: código de respuesta
l
$uri: igual a $document_uri: uri de la
petición
l
...
Configuración: variables
11. MWS nginx
Directivas de bloque: Admiten otras directivas, pero
no cualquiera y pueden anidarse y se hereda la del
bloque superior
l
events { worker_connections 1024; }
l
http { server {
l
listen 80;
l
server_name example.com;
l
access_log /var/log/nginx/example.com.log;
l
location ^~ /admin/ {
l
index index.php;
l
access_log off;
l
}
l
}
l
include mime.types;
l
}
Directivas de bloque
13. MWS nginx
daemon (on|off); Modo background o no. Por
defecto on. Útil para depurar.
debug_points (stop|abort); Por defecto
inhabilitada
env MI_VARIABLE=mi_valor;
error_log fichero nivel; (nivel: debug, info,
notice, warn, error, crit, alert, emerg de→
más a menos detallado, emerg solo reporta
los críticos) Para deshabilitar: /dev/null
l
Contexto: main, http, server y location
log_not_found (on|off); registra HTTP 404
master_process (on|off); Habilitar 1 master
más workers. Si no, solo 1 proceso.
Core module directives
14. MWS nginx
pcre_jit (on|off); Habilita Just-in-Time
compilation para expresiones regulares
(rendimiento) Exige –with-pcre-jit y –enable-
jit en compilación de nginx
pid fichero; Por defecto, en compilación
ssl_engine enginename; Por defecto, none.
Enginename es el nombre del acelerador SSL
HW en tu sistema (openssl engine -t para
comprobar)
thread_pool name threads=number
[max_queue=number]; (defecto threads=32
y max_queu=65536) Pool para la directiva
aio para servir grandes ficheros
Core module directives
15. MWS nginx
user username groupname;
worker_processes number;
worker_directory directorio; Directorio de
trabajo (para ficheros core) y debe tener +w
para username
worker_rlimit_nofile número; De ficheros que
un worker puede procesar simultáneamente
worker_rlimit_core tam; Tamaño de los
ficheros core por worker.
worker_aio_request número; aio+epoll →
número máximo de operaciones I/O
pendiente por worker
Core module directives
16. MWS nginx
Permite configurar los
mecanismos/funcionamiento de red
En events bloks (events {})
Directivas:
l
accept_mutex (on|off); Exclusión mútua para→
escuchar sockets
l
accept_mutex_delay time; Espera para adquirir
un recurso (solo si anterior ON)
l
debug_connection IP; Logs detallados para un
equipo concreto (exige compilación con
--debug)
l
worker_connections number; Número de
conexiones que un worker puede procesar
simultáneamente
events module
17. MWS nginx
use kqueue; Modelo de eventos:
l
select: Es el de defecto. No recomendado para
elevada carga.
l
poll: Es mejor que select para gran carga, pero
no admitido por todos los sistemas
l
Kqueue: eficiente para FreeBSD 4.1+, MacOS
X, OpenBSD 2.9+
l
epoll: Eficiente para Linux 2.6+
l
/dev/poll: Eficiente para Solaris 7 11/99+, IRIX
6.5.15+
events module directives
18. MWS nginx
Solo es para habilitar la inclusión de ficheros:
include sites/*.conf
Importante: si el path es relativo, siempre se
toma como base el directorio de configuración
configuration module
19. MWS nginx
Contiene todo lo relacionado con bloques,
directivas y variables del servidor HTTP
Dispone de 3 bloques lógicos:
l
http: define faceta HTTP server de Nginx
l
server: relacionado con los “servidores web”
Solo se usa con un bloque http
l
location: define un grupo de configuraciones
para aplicar a una localización concreta del sitio
web. Puede ser usado en un bloque server o en
otro location
HTTP Core module
21. MWS nginx
Directivas de socket y host
l
listen [address][:port] [options];
Context:server
l
Options: ssl, default_server (web site por
defecto), spdy, proxy_protocol
l
server_name name [*.domain name2 ...];
Context: server
l
server_name *.website.*;
l
server_name ~^(www).example.com$;
l
server_name _ "";
l
server_name_in_redirect (on|off);
l
Context: http, server, location
l
port_in_redirect (on|off); (Añadir o no el puerto
en la URL de redirección)
HTTP Core module
22. MWS nginx
Directivas de paths y documentos
l
root directorio; Define documentroot
l
Context: http, server, location, if Acepta variables
l
alias directorio;
l
Context: location Acepta variables
l
error_page codigo1 [codig2 …] [=otro_code]
[=@block | URI ]
l
Context: http, server, location, if. Acepta vars
l
error_page 404 =200 /index.html
l
error_page 404 @notfound; #va al bloque de
location “notfound”
l
index file1 [file2...];
l
Context: http, server, location Acepta vars
l
try_files file1 [file2...] [@block | URI ];
l
Context: http, server, location Acepta vars
HTTP Core module
23. MWS nginx
Directivas sobre las peticiones de los clientes
l
keepalive_requests num; Número máx de
peticiones por conexión
l
Context: http, server, location
l
keepalive_timeout secs [secs2];timeout
header=secs2
l
Context: http, server, location
l
send_timeout secs; Para cerrar conexión inactiva
l
Context: http, server, location
l
client_body_* Sobre el cuerpo de la petición→
l
Context: http, server, location
l
types { mimetype1 extension1;[...]}
l
Context: http, server, location
l
→ include mime.types; (para incluir todos)
l
default_type mimetype; para los tipo no incluidos→
HTTP Core module
24. MWS nginx
Directivas sobre límites y restricciones
l
limit_except método {allow,deny}; previene el uso de
métodos excepto el que explícitamente se habilita
l
Context: location
l
limit_rate bps; Limita ratios de transferencia de
conexiones individuales de clientes
l
Context: http, server, location,if
l
limit_rate_after bytes; Pasada la cantidad marcada
por bytes a máxima velocidad, se aplica la de
limit_rate
l
satisfay uri {}; Marca condiciones que debe cumplir
el cliente (allow, deny, auth_basic,...,any, all)
l
Context: location
l
Internal;-> No puede ser accedido desde exterior
l
Context: location
HTTP Core module
25. MWS nginx
Directivas sobre caché y procesamiento de ficheros
l
disable_symlinks (on|if_not_owner)
l
directio (off|value); Ficheros > value, serán leídos
con mecanismos Direct I/O
l
Context: http,server, location
l
open_file_cache max=N inactive=T; N entradas
como máximo y T segundos sin acceso en caché.
Guarda info sobre el fichero, no contenido.
l
Context: http,server, location
l
log_not_found (on|off);
l
Context: http,server, location
l
resolver IP_DNS [valid=time];
l
Context: http,server, location
l
resolver_timeout time; Timeout para la query DNS
l
Context: http,server, location
HTTP Core module
26. MWS nginx
LOCATION: permite especificar un patrón que se
comprobará con el documento en las URI de las
peticiones. Sintaxis:
location [= |~|~*|^~|@] pattern { ... }
La parte opcional se denomina location modifier y
define qué debe hacer nginx con el patrón indicado
l
Sin modifier El inicio del documento debe→
concordar con el patrón
l
= Documento debe concordar exactamente y el→
patrón debe ser una cadena literal
l
~ Debe concordar case-sensitive con la expresión→
regular; ~* case-insensitive→
l
^~ Similar al 1º, pero parando la búsqueda de→
otros
l
@ referencia a un bloque
HTTP Core module: location block
27. MWS nginx
LOCATION: Se pueden definir múltiples bloques con
diferentes patrones, buscando la concordancia en
este orden:
l
Con modifier =
l
Sin modifier, coincidencia exacta
l
Con modifier ^~
l
Con modifier ~ o ~*
l
Sin modifier Si el string coincide con el inicio de la
URI, se devuelve el bloque
HTTP Core module: location block
28. MWS nginx
server{
server_name website.com;
location /files/ {
# applies to any request starting with "/files/"
# for example /files/doc.txt, /files/, /files/temp/
}
location = /files/ {
# applies to the exact request to "/files/"
# and as such does not apply to /files/doc.txt
# but only /files/
}
}
URI: http://website.com/files/doc.txt se aplica 1º→
URI: http://website.com/files/ se aplica el 2º→
HTTP Core module: location block
29. MWS nginx
server{
server_name website.com;
location /doc {
[...] # requests beginning with "/doc"
}
location ~* ^/document$ {
[...] # requests exactly matching "/document"
}
}
URI: http://website.com/document Ambos coinciden, se→
aplica orden de prioridad y el seleccionado será el 2º
Si en el 1º, ponemos ^~, se aplicaría el 1º (por prioridad)
HTTP Core module: location block
33. MWS nginx
server {
If ($request_method = POST) {
[….]
}
}
Rewrite module: Conditional structure
Para aplicar configuraciones de acuerdo a condiciones
específicas
Operadores:
l
None: Condición true si la variable o datos no es
vacia
l
=, !=
l
~ , ~* , Coincide con expresión regular. ~ es
case-sensitive, ~* es case-insensitive. Negación: !
~ , !~*
l
-f , !-f fichero
l
-d , !-d Directorio
l
-x , !-x Como -f, que existe y, además, ejecutable
34. MWS nginx
if (-f $uri) {
break; # break if the file exists
}
if ($uri ~ ^/search/(.*)$) {
set $query $1;
rewrite ^ /search.php?q=$query?;
Rewrite module: Directivas
rewrite regexp replacement [flag]
l
Context: server, location, if
l
Flag: last, break, redirect (302), permanet (301)
Break. Ejemplo. SI existe, no reescribe
Context: server, location, if
return code | text;
Context: server, location, if
set $var1 “some”
Context: server, location, if
uninitialized_variable_warn; Log cuando se use una no→
inicializada
rewrite_log (on|off) registrará cada operación realizada→
35. MWS nginx
Rewrite module: ejemplos reescrituras
rewrite ^/([0-9]+)/.*$ /article.php?id=$1?;
l
URI: http://website.com/33526/us-economy-strengthens
l
Rewritten: http://website.com/article.php?id=33526
rewrite ^/topic-([0-9]+)-([0-9]+)-(.*).html$
/viewtopic.php?topic=$1&start=$2?;
l
URI: http://website.com/topic-1234-50-some-
keywords.html
l
RW: http://website.com/viewtopic.php?
topic=1234&start=50
rewrite ^/wiki/(.*)$ /wiki/index.php?title=$1?;
l
URI:http://website.com/wiki/Some_keyword
l
RW: http://website.com/wiki/index.php?
title=Some_keyword
36. MWS nginx
Módulos
l
HTTP Referer: filtrar peticiones en función de la
cabecera HTTP Referer *
l
HTTP Limit Zone: Limita el nº conexiones
simultáneas del mismo cliente
l
User ID: cookies identificativas
l
FLV: reproducir vídeos en streaming
l
Perl: Ejecución de guiones Perl
l
WebDAV
l
SecureLink: para proteger páginas con claves
secretas
l
XSLT: postprocesamiento de páginas mediante
XSLT
* http://www.elladodelmal.com/2017/04/pon-un-referrer-policy-y-mejora-la.html Y https://securityheaders.io
Configuración
37. MWS nginx
En un servidor Nginx se debe ajustar:
l
user -> no privilegiado
l
worker_process auto Por defecto es 1,→
aunque lo mejor es uno por CPU disponible
l
worker_priority 0; Reasignar prioridad en→
función del servidor (recordad -20 max
prioridad, 20 min prioridad y el kernel suele
tener -5)
l
log_not_found on;Puede ser interesante para
depurar nuestro sitio
l
worker_connections 1024; Para definir al
número total de conexiones que acepta tu
servidor (junto con worker_process) y depende
de RAM y CPU
Ajustes necesarios
38. MWS nginx
NGINX puede ser muy útil a APPS en:
l
Caching integration
l
Changing content on-the-fly
l
Using Server Side Includes
l
Decision-making in NGINX
l
Creating a secure link
l
Generating images
l
Tracking website visitors
l
Preventing inadvertent code execution
Para desarrolladores
39. MWS nginx
Para desarrolladores: Caching integration
Objetivo: mejorar el rendimiento de nuestra
app
App no usa caché:
l
Uso de proxy_cache_ * y/o fastcgi_cache_*
l
Para páginas individuales, cabeceras: Expires
and Cache-Control headers y X-Accel-Expires
Las interpreta NGINX y no las envía al cliente.
l
Ejemplo: Página de noticias en la que se
decide
l
Página frontal será cacheada 1'
l
Cada artículo 1 día
l
Cada imagen tanto como sea posible
40. MWS nginx
Para desarrolladores: Caching integration
http {
# here we configure two separate shared memory zones for the keys/metadata
# and filesystem paths for the cached objects themselves
proxy_cache_path /var/spool/nginx/articles keys_zone=ARTICLES:16m
levels=1:2 inactive=1d;
proxy_cache_path /var/spool/nginx/images keys_zone=IMAGES:128m levels=1:2
inactive=30d;
# but both paths still lie on the same filesystem as proxy_temp_path
proxy_temp_path /var/spool/nginx;
server {
location / {
# this is where the list of articles is found
proxy_cache_valid 1m;
}
location /articles {
# each article has a URI beginning with "/articles"
proxy_cache_valid 1d;
}
location /img {
# every image is referenced with a URI under "/img"
proxy_cache_valid 10y;
}
}
41. MWS nginx
Para desarrolladores: Caching DB
Si tu app almacena páginas prerenderizadas en base
de datos, NGINX puede servirlas directamente desde
memcached
l
SI URI está en caché, se sirve
l
Si no, se pide a la app
location / {
set $memcached_key “$uri?$args”;
memcached_pass 127.0.0.1:11211;
error_page 404 502 504 = @app; //sustituirá el
código de error por el que devuelva app
}
Location @app {
proxy_pass 127.0.0.1:8080;
42. MWS nginx
Para desarrolladores: Caching FS
Si tu app escribe páginas prerenderizadas en el FS,
NGINX puede servirlas con cabeceras apropiadas:
Expires and Cache-Control
server{
root /var/www
location / {
location = /index.html {
expires 5m;
}
location ~* /.*.(js|css)$ {
expires 24h;
}
location ~* /.*.html$ {
expires 3d;
}
location /img {
expires max;
}
43. MWS nginx
Para desarrolladores: on-the-fly
Post-process: añadir un string, transformación del
HTML,... NGINX proporciona módulos para ello: addition,
sub y xslt (transformar XML usando XSLT)
server{
root /var/www
location / {
location / {
add_before_body /header;
add_after_body /footer;
}
location /header {
proxy_pass http://127.0.0.1:8080/header;
}
location /footer {
proxy_pass http://127.0.0.1:8080/footer;
}
}
sub_filter_once off;
sub_filter '<img src="img/' '<img src="/img/';
sub_filter </head> '<meta name="frontend" content="web3"></head>';
sub_filter_types text/css;
44. MWS nginx
Para desarrolladores: secure link
Protección de ciertas partes sin autenticación completa.
HASH MD5 del link + secret
location /downloads/ {
secure_link_secret supersecreto;
If ($secure_link = “”) {
Return 403;
}
try_files /downloads/$secure_link =404;
}
HTML:
<a href="/downloads/<hash>/libro_del_curso.pdf">Descarga libro del máster</a>
http://wiki.nginx.org/HttpSecureLinkModul
e
46. MWS nginx
Para desarrolladores: tracking web visitors
Para rastrear visitantes únicos: userid module. Configura una
cookie por cliente cuyo valor tenemos en $uid_set. Cuando
vuelve y la cookie es válida, estará en $uid_got
http {
log_format useridcomb '$remote_addr - $uid_got [$time_local] '
'"$request" $status $body_bytes_sent ' '"$http_referer"
"$http_user_agent"';
server {
server_name .example.com;
access_log logs/example.com-access.log useridcomb;
userid on;
userid_name uid;
userid_domain example.com;
userid_path /;
userid_expires 365d;
userid_p3p 'policyref="/w3c/p3p.xml", CP="CUR ADM OUR
NOR”';
}
47. MWS nginx
Para desarrolladores: preventing code exe
Para mandar todos los requerimiento PHP a FastCGI server,
tenemos la opción A. Si nuestros usuarios suben ficheros a la
misma estructura de directorio, puede ser un problema (podrían
subir ficheros .jpg, etc con php embebido que se interpretaría)
Para prevenir esta posibilidad, opción B. Con try_files nos
aseguramos que el fichero exista.
B
location ~* .php {
try_files $uri =404;
include fastcgi_params;
fastcgi_pass 127.0.0.1:9000;
}
A
location ~* .php {
include fastcgi_params;
fastcgi_pass
127.0.0.1:9000;
}
48. MWS nginx
Para desarrolladores: proxy inverso URL
Ejemplo: la parte cliente y todas las rutas del frontend (con
AngularJS) se sirvan a través de la ruta /. Y que nuestra API
(con, por ejemplo, Node.js) se sirva a través de la ruta /api
# HTTP proxy
server {
listen 80;
server_name midominio.com;
access_log /var/log/nginx/nginx.access.log;
error_log /var/log/nginx/nginx.error.log;
client_max_body_size 5M;
location / {
add_header Cache-Control "no-store, no-cache, must-revalidate, post-check=0, pre-check=0";
# Ruta de los ficheros estáticos
root /var/www;
try_files $uri $uri/ /index.html =404;
}
location /api {
proxy_set_header 'Access-Control-Allow-Origin' 'http://midominio.com';
proxy_set_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, PUT, DELETE';
proxy_set_header 'Access-Control-Allow-Headers' 'X-Requested-With,Accept,Content-Type,
Origin';
proxy_pass http://127.0.0.1:3000;
proxy_redirect off;
proxy_buffering on;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header origin 'http://midominio.com';
}
}
49. MWS nginx
Balanceo de carga: round robin
peticiones distribuidas entre los servidores de forma cíclica.
Las más pesadas pueden asignarse al mismo servidor
Distribuye las peticiones de forma ecuánime pero la carga no
salvo que usemos la directiva weight
upstream app {
server app1:8080;weight=3;
server app2:8080;
server app3:8080;
}
server {
listen 80;
location / {
proxy_pass http://app;
add_header X-Upstream $upstream_addr;
}
}
50. MWS nginx
Balanceo de carga: least-conected
La siguiente petición es atendida por el servidor con menos
conexiones activas.
Como el anterior, no reparte por sesión
upstream app {
least_conn;
server app1:8080;
server app2:8080;
server app3:8080;
}
server {
listen 80;
location / {
proxy_pass http://app;
add_header X-Upstream $upstream_addr;
}
}
51. MWS nginx
Balanceo de carga: ip-hash
Se usará la dirección IP de origen para redirigir todas las peticiones
al mismo servidor que se conoce como sticky session
También: hash $cookie_username; en vez de IP, usa la cookie de
usuario
upstream app {
ip_hash;
server app1:8080;
server app2:8080;
server app3:8080;
}
server {
listen 80;
location / {
proxy_pass http://app;
add_header X-Upstream $upstream_addr;
}
}
52. MWS nginx
Balanceo de carga
Los chequeos de salud se hacen de forma pasiva según el
resultado de las peticiones que se envían.
>max_fails, estado erróneo y estará durante fail_timeout
Tras fail_timeout, se le envía nueva petición. Si se responde
bien, pasa estado correcto.
La directiva health_check permite configurar la pruebas de
funcionamiento que se realizan a los servidores
upstream app {
ip_hash;
server app1:8080 max_fails=5 fail_timeout=30s;
server app2:8080;
server app3:8080;
}
54. MWS nginx
nginx -t
nginx -t -c fichero_de_configuración
nginx -V información sobre el→
argumentos de compilación, módulo
incluídos.
nginx -g Permite incluir→
configuraciones de directivas que no
estén en el fichero de configuración:
nginx -g “timer_resolution 200ms”
Testing configuration
Solicitudes múltiples acceso concurrente o única llamada para obtener todos los recursos (multiples peticiones por concexión)
Version 1.1 of the protocol made bandwidth optimization improvements to HTTP/1.0. For example, HTTP/1.1 introduced chunked transfer encoding to allow content on persistent connections to be streamed, rather than buffered. HTTP pipelining further reduces lag time, allowing clients to send multiple requests before a previous response has been received to the first one. Another improvement to the protocol was byte serving, which is when a server transmits just the portion of a resource explicitly requested by a client.
FastCGI es una alternativa al CGI estándar, cuya diferencia radica principalmente en el hecho de que el servidor crea un único proceso persistente por cada programa FastCGI en lugar de uno por cada solicitud del cliente.
Ventajas [editar]
Ahorro de Tráfico: Las peticiones de páginas Web se hacen al servidor Proxy y no a Internet directamente. Por lo tanto, aligera el tráfico en la red y descarga los servidores destino, a los que llegan menos peticiones.
Velocidad en Tiempo de respuesta: El servidor Proxy crea un caché que evita transferencias idénticas de la información entre servidores durante un tiempo (configurado por el administrador) así que el usuario recibe una respuesta más rápida.
Demanda a Usuarios: Puede cubrir a un gran número de usuarios, para solicitar, a través de él, los contenidos Web.
Filtrado de contenidos: El servidor proxy puede hacer un filtrado de páginas o contenidos basándose en criterios de restricción establecidos por el administrador dependiendo valores y características de lo que no se permite, creando una restricción cuando sea necesario.
Modificación de contenidos: Basándose en la misma función del filtrado, y llamado Privoxy, tiene el objetivo de proteger la privacidad en Internet, puede ser configurado para bloquear direcciones y Cookies por expresiones regulares y modifica en la petición el contenido.
Desventajas [editar]
Las páginas mostradas pueden no estar actualizadas si éstas han sido modificadas desde la última carga que realizó el proxy caché.
Un diseñador de páginas web puede indicar en el contenido de su web que los navegadores no hagan una caché de sus páginas, pero este método no funciona habitualmente para un proxy.
El hecho de acceder a Internet a través de un Proxy, en vez de mediante conexión directa, impide realizar operaciones avanzadas a través de algunos puertos o protocolos.
Almacenar las páginas y objetos que los usuarios solicitan puede suponer una violación de la intimidad para algunas personas.
SSI (Server Side Includes) are directives that are placed in HTML pages, and evaluated on the server while the pages are being served. They let you add dynamically generated content to an existing HTML page, without having to serve the entire page via a CGI program, or other dynamic technology.
The decision of when to use SSI, and when to have your page entirely generated by some program, is usually a matter of how much of the page is static, and how much needs to be recalculated every time the page is served. SSI is a great way to add small pieces of information, such as the current time. But if a majority of your page is being generated at the time that it is served, you need to look for some other solution.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
Apache inicia varios subprocesos y cada petición es atendida por uno de estos; cuando termina con esta petición este subproceso podría atender a otro cliente o ser terminado, según al valor de MaxRequestsPerChild.
Es el modo más estable, ya que un error crítico solo afectaría a una petición. Este es el único modo en que se pueden usar módulos / extensiones que no sean Thread-Safe.
Requiere más recursos (Memoria RAM y CPU) para atender cierto número de peticiones simultaneas, respecto a otras configuraciones. Esto limita drásticamente la escabilidad del servidor.
Favorece el uso intensivo de PHP. Los aceleradores de PHP no son Thread-Safe, pero al usarlos junto a Prefork podemos justificar el mayor uso de php (o páginas sin ningún tipo de caché, aparte del acelerador en sí).
Prefork es la configuración predeterminada en la mayoría de instalaciones.
EN 2.4, MaxClients es MaxRequestWorkers
Wherever in your URL-space you do not have an Options FollowSymLinks, or you do have an Options SymLinksIfOwnerMatch, Apache will need to issue extra system calls to check up on symlinks. (One extra call per filename component.) For example, if you had:
DocumentRoot &quot;/www/htdocs&quot;
&lt;Directory &quot;/&quot;&gt;
Options SymLinksIfOwnerMatch
&lt;/Directory&gt;
and a request is made for the URI /index.html, then Apache will perform lstat(2) on /www, /www/htdocs, and /www/htdocs/index.html. The results of these lstats are never cached, so they will occur on every single request. If you really desire the symlinks security checking, you can do something like this:
DocumentRoot &quot;/www/htdocs&quot;
&lt;Directory &quot;/&quot;&gt;
Options FollowSymLinks
&lt;/Directory&gt;
&lt;Directory &quot;/www/htdocs&quot;&gt;
Options -FollowSymLinks +SymLinksIfOwnerMatch
&lt;/Directory&gt;