Comments 22
# Указываем корень где будет лежать сайт
root /path/to/www;
# Всю статику отдаем nginx
location ~* ^.+\.(jpg|jpeg|gif|png|ico|css|js|bmp)$ {
root /path/to/www;
}
строчки не имеют смысла, если у вас один и тот же root, да и вообще nginx отдаст эти файлы так сказать по дефолту, если вы на них handler не повесите :) имеет смысл поставить expires побольше в этот location и возможно настроить размер буферов для отдачи (если статических файлов действительно много)
root /path/to/www;
# Всю статику отдаем nginx
location ~* ^.+\.(jpg|jpeg|gif|png|ico|css|js|bmp)$ {
root /path/to/www;
}
строчки не имеют смысла, если у вас один и тот же root, да и вообще nginx отдаст эти файлы так сказать по дефолту, если вы на них handler не повесите :) имеет смысл поставить expires побольше в этот location и возможно настроить размер буферов для отдачи (если статических файлов действительно много)
Спасибо, добавил в топик.
А, и да, конфиг брал очасти свой, а на проекте как-раз таки и есть хендлер, поэтому пришлось уточнять.
* отчасти
могу еще одну вещь неявную сказать, если соберешься ставить expires на статические файлы, то лучше убрать оттуда js/css, либо придется прописывать в проекте включение их следующим образом:
и при изменении lib.js менять версию, чтобы браузеры перечитывали содержимое
это из собственных наблюдений :)
и при изменении lib.js менять версию, чтобы браузеры перечитывали содержимое
это из собственных наблюдений :)
А можно узнать, причем тут размеры буферов для отдачи? Я вот, всю жизнь, считал, что лучше отдавать через sendfile.
Перенесите лучше в «серверную оптимизацию» :)
Эээх, опять сборка из исходников, вместо нормальных srpm/deb-src и прочих…
Да я бы и сам рад был собрать из готовых пакетов — думаю, процесс намного бы упростился, но, как я упомянул выше, мне это не подходило. Я думаю остальным ничего не мешает все поставить из репозиториев, а настройка ничем не отличается.
из личных наблюдений — проще скомпилить и выставить свои опции, чем искать какие есть в пакете, а потом если не хватает — пересобирать пакет, да и бывает, что забываешь что-то включить, поставить тот же статус для графиков или с дебагом собрать в особо тяжелых случаях
location ~ \.php$ {
fastcgi_pass 127.0.0.1:9000;
}
лучше
location ~ \.php$ {
fastcgi_pass unix:/tmp/fastcgi_sock;
}
и в пхп соответственно поправить.
fastcgi_pass 127.0.0.1:9000;
}
лучше
location ~ \.php$ {
fastcgi_pass unix:/tmp/fastcgi_sock;
}
и в пхп соответственно поправить.
А почему, кстати?
Обращения к сокету проходят быстрее обращений по tcp, даже на локальный хост.
А вы имеете тесты или это только мысли?
Конечно тесты, даже вот фрагмент объяснения из рассылки FreeBSD (если вы по логике вещей не можете или не хотите понимать, что установление соединения по tcp протоколу, который, кстати, с проверками, занимает больше времени, нежели работа с локальным сокетом).
UNIX domain sockets have explicit knowledge that they're executing on
the same system. They avoid the extra context switch through the
netisr, and a sending thread will write the stream or datagrams directly
into the receiving socket buffer. No checksums are calculated, no
headers are inserted, no routing is performed, etc.
IP sockets over localhost are basically looped back network on-the-wire
IP. There is intentionally «no special knowledge» of the fact that the
connection is to the same system, so no effort is made to bypass the
normal IP stack mechanisms for performance reasons. For example,
transmission over TCP will always involve two context switches to get to
the remote socket, as you have to switch through the netisr, which
occurs following the «loopback» of the packet through the synthetic
loopback interface.
Полное объяснение здесь: lists.freebsd.org/pipermail/freebsd-performance/2005-February/001143.html
UNIX domain sockets have explicit knowledge that they're executing on
the same system. They avoid the extra context switch through the
netisr, and a sending thread will write the stream or datagrams directly
into the receiving socket buffer. No checksums are calculated, no
headers are inserted, no routing is performed, etc.
IP sockets over localhost are basically looped back network on-the-wire
IP. There is intentionally «no special knowledge» of the fact that the
connection is to the same system, so no effort is made to bypass the
normal IP stack mechanisms for performance reasons. For example,
transmission over TCP will always involve two context switches to get to
the remote socket, as you have to switch through the netisr, which
occurs following the «loopback» of the packet through the synthetic
loopback interface.
Полное объяснение здесь: lists.freebsd.org/pipermail/freebsd-performance/2005-February/001143.html
if (!-e $request_filename) {
rewrite ^.*$ /index.php last;
}Очень плохо. Идите читайте про
try_files.Sign up to leave a comment.
Nginx + php-fpm на CentOS 5.3