Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Релиз http-сервера nginx 1.6.0 "	+/–
Сообщение от opennews (ok), 24-Апр-14, 19:56
После года разработки представлена (http://nginx.org/#2014-04-24) новая стабильная ветка высокопроизводительного HTTP-сервера nginx 1.6.0 (http://nginx.org/), которая вобрала в себя изменения, накопленные в рамках основной ветки 1.5.x. В дальнейшем все изменения в  стабильной ветке 1.6 будут связаны с устранением ошибок и внесением незначительных улучшений, не нарушающих API. Одновременно сформирована (http://mailman.nginx.org/pipermail/nginx-announce/2014/00013...) основная ветка nginx 1.7, в рамках которой будет продолжено развитие новых возможностей. Из улучшений (http://nginx.org/ru/CHANGES.ru-1.6), добавленных в процессе формирования основной ветки 1.5.x, можно отметить: -  Новый модуль ngx_http_auth_request_module (http://nginx.org/ru/docs/http/ngx_http_auth_request_module.html), для организации авторизации клиента на основании результата запроса по определённому URI (например, при успешной авторизации в другой директории);-  В модуле ngx_http_spdy_module (http://nginx.org/ru/docs/http/ngx_http_spdy_module.html) добавлена поддержка протокола SPDY 3.1 (http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-dra...). Для ограничения скорости передачи ответов клиенту в SPDY-соединениях теперь допускается использовать директиву limit_rate; -  В модуль ngx_http_proxy_module (http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#pro...) добавлена возможность подтверждения корректности содержимого просроченных элементов кэша при помощи условных запросов с полем заголовка If-Modified-Since;-  Новые переменные:  $ssl_session_reused и $proxy_protocol_addr;-  Новые директивы: -  ssi_last_modified, sub_filter_last_modified и        xslt_last_modified;-  fastcgi_buffering;-  proxy_cache_revalidate, fastcgi_cache_revalidate, scgi_cache_revalidate и uwsgi_cache_revalidate;-   ssl_buffer_size, ssl_session_ticket_key, ssl_session_tickets;-  proxy_ssl_protocols и proxy_ssl_ciphers;-  spdy_chunk_size; -  Возможность использования нескольких директив error_log;-  В директивы allow и deny добавлена поддержка unix domain    сокетов;-  В директиву listen добавлена поддержка  параметра fastopen;-  В директивы proxy_next_upstream,        fastcgi_next_upstream, scgi_next_upstream и uwsgi_next_upstream добавлена поддержка параметра http_403; -  Директива disable_symlinks теперь использует O_PATH в Linux;-  При использовании длинных цепочек сертификатов задействована оптимизация SSL handshake;-  В почтовый прокси-сервер добавлена поддержка SMTP pipelining;-  В resolver добавлена поддержка IPv6;-  В секцию contrib добавлены скрипты для подсветки синтаксиса в vim-  В модуль ngx_http_uwsgi_module добавлена поддержка SSL;-  В модуле ngx_http_mp4_module обеспечен пропуск дорожек,        имеющих меньшую длину, чем запрошенная перемотка. Обеспечена поддержка byte ranges и аргумента end; -  В  директивы listen и real_ip_header добавлен параметр proxy_protocol;-  Поддержка byte ranges при сохранении ответов в кэш. Новшества (http://nginx.org/en/CHANGES), представленные в выпуске nginx 1.7.0: -  Поддержка верификации сертификатов SSL-бэкендов; -  Поддержка SNI (Server Name Indication, позволяет обеспечить доступ через шифрованное соединение к виртуальным хостам на одном IP) при работе с SSL-бэкендами; -  Новая переменная $ssl_server_name. -  Возможность использования параметра "if" в директиве access_log. URL: http://mailman.nginx.org/pipermail/nginx-announce/2014/00013... Новость: http://www.opennet.me/opennews/art.shtml?num=39638
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от steven_w (ok), 24-Апр-14, 19:56	+8 +/–
Ну и комбайн, скоро апач догонит.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #2, #17, #21

2. Сообщение от Аноним (-), 24-Апр-14, 20:12	–2 +/–
Уже перегнал. Апач не может в SMTP, IMAP и POP3.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #3

3. Сообщение от Аноним (-), 24-Апр-14, 20:17	+4 +/–
А ему это надо?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #14

4. Сообщение от Аноним (-), 24-Апр-14, 20:35	+1 +/–
Разработчики также сделали опрос для сообщества, чтобы лучше спланировать будущие релизы: http://mailman.nginx.org/pipermail/nginx/2014-April/043282.html
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #6, #9

6. Сообщение от Аноним (-), 24-Апр-14, 20:57	–1 +/–
Там какие-то глупые вопросы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #19

9. Сообщение от хм (?), 24-Апр-14, 21:24	–1 +/–
>Разработчики также сделали опрос для сообщества, чтобы лучше спланировать будущие релизы: https://www.surveymonkey.com/s.aspx?sm=nQUaqZCCgCT1gpjs%... aspx?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #20, #29

11. Сообщение от PyMonty (?), 24-Апр-14, 22:33	–1 +/–
Рекомендуется использовать основную ветку: http://nginx.com/blog/nginx-1-6-1-7-released/
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #27

14. Сообщение от rob pike (?), 24-Апр-14, 23:09	–1 +/–
Ему уже ничего не надо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

15. Сообщение от неАноним (??), 24-Апр-14, 23:13	–1 +/–
УРА! sni!!!!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #40, #58

17. Сообщение от Аноним (-), 25-Апр-14, 00:13	+/–
Апача хрен догонишь по пожирону ресурсов и неэффективной отгрузке статики.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

19. Сообщение от Аноним (-), 25-Апр-14, 00:50	+1 +/–
> Там какие-то глупые вопросы. Вопросы как вопросы. Вполне можно и фи высказать и похвалить и указать что не так.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

20. Сообщение от Аноним (-), 25-Апр-14, 00:52	+1 +/–
> aspx? Это вообще совершенно посторонний ресурс занимающийся проведением опросов. Хотя, конечно, aspx в опросе про nginx - это да, фэйловато :). Могли бы нанять пару веб-обезьянок, они бы формы для опроса за пару дней накодили без таких фиаско.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #26

21. Сообщение от Аноним (-), 25-Апр-14, 00:54	+/–
> Ну и комбайн, скоро апач догонит. Nginx крут тем что уже достаточно фичаст для того чтобы им можно было пользоваться, а не чертыхаться на все и вся, но при этом намного быстрее и легче чем апач. А замена апача на нжинкс на сайте отгружающем пнг и жыпег оказалась заметна на глаз. Так что авторы нжинкса могут собой гордиться - редкое явление когда продукт такого плана можно заметить невооруженным глазом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #50

22. Сообщение от rob pike (?), 25-Апр-14, 01:21	+/–
Я бы с большим интересом выслушал рассказ о месте апача в мире образца 2014 года. Кроме очевидных случаев legacy, конечно. С учетом наличия ngx_lua и сопутствующих модулей. (Про фронтенд не будем, разумеется, дабы не избивать младенцев^W старцев совсем больно). А так-то в своё время 1.3.x был очень хорош. А вместе с mod_perl так и просто ultimate. Только с тех пор много воды утекло.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #23

23. Сообщение от Stax (ok), 25-Апр-14, 01:51	+4 +/–
(из любопытства - нет, я реально не слежу за ситуацией) - nginx уже научился htaccess? Т.е. не общему конфигу, перечитываемому через restart/reload, а "изменил кто-нибудь настройки данного каталога - и на лету то, что под ним стало отдаваться иначе". По-моему, раньше утверждалось, что nginx "ради скорости" by design такого никогда не сможет. Поменяли что-нибудь - скажите админу пере грузить конфиг, иначе ничего не подхватится.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #24, #25, #28, #31, #57

24. Сообщение от Куяврег (?), 25-Апр-14, 02:08	–4 +/–
> Поменяли что-нибудь - скажите админу перегрузить конфиг, иначе ничего не подхватится. ай беда... как же теперь быть шаредпомойкам...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #53

25. Сообщение от rob pike (?), 25-Апр-14, 02:34	+2 +/–
Да, вполне кейс. Хотя, конечно, considered "нинужна" (http://wiki.nginx.org/LikeApache-htaccess), но мы не станем им уподобляться. Я бы, наверное, написал для таких кейсов пятнадцатистрочник, ловящий через inotify изменения и шлющий nginx-у сигнал перечитать конфиг - и странно если никто его, в общем виде с конфигурируемостью и прочим не написал, но может я чего не вижу, сонный.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #32

26. Сообщение от хм (?), 25-Апр-14, 06:57	+1 +/–
>> aspx? > Это вообще совершенно посторонний ресурс занимающийся проведением опросов. Хотя, конечно, > aspx в опросе про nginx - это да, фэйловато :). Могли > бы нанять пару веб-обезьянок, они бы формы для опроса за пару > дней накодили без таких фиаско. спасибо, капитан. Оно еще и символично. На CDN nginx, а сзади IIS.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #30

27. Сообщение от Аноним (-), 25-Апр-14, 09:15	+2 +/–
> Рекомендуется использовать основную ветку: http://nginx.com/blog/nginx-1-6-1-7-released/ Рекомендуют, так как им тестировщики нужны. Поэтому в своё время они unstable в mainline и переименовали, но суть мало изменилась.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #48

28. Сообщение от NikolayV81 (ok), 25-Апр-14, 09:42	+/–
Смысл nginx именно в том что бы сократить время/ресурсы на обработку запроса, парсить конфиг на ходу дурацкая с точки зрения производительности идея. Почему не сделано автоматическое обновление, тоже понятно, reload позволяет не применять настройки если они кривые, что очень удобно в использовании. У этого решения есть плюсы и минусы, основной плюс - скорость работы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #41

29. Сообщение от Andrey Mitrofanov (?), 25-Апр-14, 10:05	+/–
>/s.aspx?sm=nQUaqZCCgCT1gpjs+uGOvw== > aspx? Ты бы хотел, чтоб в следующий раз опрос был на mod_lua?  /s.lua?sm=nQUaqZCCgCT1gpjs+uGOvw==, да?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #49

30. Сообщение от Аноним (-), 25-Апр-14, 10:35	+/–
> Оно еще и символично. На CDN nginx, а сзади IIS. Ну да, IIS гомно. Вы не знали? Сюрприз. Остается правда вопрос - зачем платить за серверную винду и IIS? Кроме "тyпость админов/манагеров упомянутого ресурса" разумных ответов в голову не приходит. А нжинкс приделали уже потом, когда заметили что IIS под нагрузкой жидко сдpиcтывает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

31. Сообщение от Аноним (-), 25-Апр-14, 10:38	–3 +/–
> уже научился htaccess? Он не научится ему никогда. Если вам на эффективность и скорость пофиг и надо вашу cpaную общественную помойку в виде шаредхостинга где 100500 ничего не делающих "сайтов" свалено - вам на опач, гoвнo в гoвнe не тонет как раз. А нжинкс пытается обрабатывать запросы эффективно. Лишние чтения файловых систем почем зря - явно не в тему.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

32. Сообщение от Аноним (-), 25-Апр-14, 11:41	+/–
На то есть важная причина. В случае некорректного .htaccess'а проблеме будет подвержена только директория, в которой он лежит. В случае некорректного инклюда в nginx.conf весь релоад зафейлится, а после экстренного ребута сервера nginx вообще не взлетит, пока этот инклюд не поправят.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #33, #34, #35, #47

33. Сообщение от NikolayV81 (ok), 25-Апр-14, 11:53	–1 +/–
> На то есть важная причина. В случае некорректного .htaccess'а проблеме будет подвержена > только директория, в которой он лежит. В случае некорректного инклюда в > nginx.conf весь релоад зафейлится, а после экстренного ребута сервера nginx вообще > не взлетит, пока этот инклюд не поправят. Странно сначала релоад непроверенный и сразу же reboot экстренный, ну так никто не мешает и httpd.conf поломать...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #37

34. Сообщение от rob pike (?), 25-Апр-14, 12:16	+/–
Ну придется добавить проверку (вызов nginx с ключом -t, и посылать сигнал только если ОК), большое дело.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #36

35. Сообщение от rob pike (?), 25-Апр-14, 12:20	+/–
> после экстренного ребута сервера nginx вообще > не взлетит, пока этот инклюд не поправят. Это неприятно, да. Модуль мог бы инклудить только то что корректно, но так с разбегу не уверен что это можно корректно реализовать используя только "законные" API nginx-а. Впрочем, те, кому это действительно нужно, могли бы и патч поддерживать, он простенький же должен получаться.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #52

36. Сообщение от Аноним (-), 25-Апр-14, 13:32	+/–
Вы не поняли. В случае наличия одного некорректного инклюда не удастся добавлять/менять никакие другие инклюды, пока тот не пофиксят. поэтому для сценария использования .htaccess такой метод неприемлем - все-таки один сломанный .htaccess не мешает остальным.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #38

37. Сообщение от Аноним (-), 25-Апр-14, 13:34	+/–
Ну так никто не пускает жопоруких кодеров в httpd.conf. .htaccess же они править могут. Это дает возможность позволить им переопределять конфигурацию сервера для себя, не мешая жить другим даже в случае синтаксических ошибок.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33 Ответы: #39

38. Сообщение от rob pike (?), 25-Апр-14, 13:49	+/–
Я ниже дописал об этом
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36

39. Сообщение от NikolayV81 (ok), 25-Апр-14, 15:32	+/–
> Ну так никто не пускает жопоруких кодеров в httpd.conf. .htaccess же они > править могут. Это дает возможность позволить им переопределять конфигурацию сервера для > себя, не мешая жить другим даже в случае синтаксических ошибок. Да это понятно, но в nginx-е не нужно (ИМХО), другая модель работы (он же идейно скорее замена lighttpd ). Кстати видел рекламу шаред-хостингов с front-end на nginx, вероятно как то решают такие вопросы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

40. Сообщение от cadmi (?), 25-Апр-14, 15:36	+1 +/–
> УРА! sni!!!! Вы так бурно радуетесь тому, что SNI в сторону клиента поддерживается, начиная с 0.5.23, вышедшей 7 лет назад? :) Или вы прямо жить не могли без SNI в сторону бэкенда?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #60

41. Сообщение от Stax (ok), 25-Апр-14, 16:25	+2 +/–
Я не про дурацкая/не дурацкая (можно сделать опцией, в конце концов.. хоть на стадии компиляции), а про кейз. Он реально существует и востребован, и это один из примеров, где nginx до httpd не дотягивает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #42

42. Сообщение от NikolayV81 (ok), 25-Апр-14, 16:44	+/–
> Я не про дурацкая/не дурацкая (можно сделать опцией, в конце концов.. хоть > на стадии компиляции), а про кейз. Он реально существует и востребован, > и это один из примеров, где nginx до httpd не дотягивает. Для этого есть apache, зачем оно в nginx, если для shared-хостинга хочется организовать именно nginx в фронт-end и с поддержкой какой-то части .htaccess, то это можно сделать скриптами с проверкой, но ведь функциональность того же .htaccess зависит от набора модулей apache, сначала добавим access/deny туда, потом функции mod_rewrite, потом настройки mod_php ( а с nginx-ом как его запустить то ;) ) и так далее, в итоге получим тот же монструозный apache, который уже есть и в котором исправлены многие детские промахи, памяти он тоже будет жрать не как сейчас.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #43

43. Сообщение от Nas (??), 25-Апр-14, 18:20	+/–
NikolayV81, Если за nginx стоит апач, то mod_rewrite отлично работает для php-скриптов, например. В подавляющем большинстве случаев он только для этого и нужен (по опыту в хостинге).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42

44. Сообщение от Аноним (-), 25-Апр-14, 18:26	+/–
вопрос чайника - а оно с вебсокетами еще не дружит ? последний раз глядел на это чудо, когда - не было :/
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #45, #46

45. Сообщение от rob pike (?), 25-Апр-14, 19:00	+/–
http://nginx.org/en/docs/http/websocket.html
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44

46. Сообщение от Аноним (-), 25-Апр-14, 20:48	+/–
http://nginx.org/ru/docs/http/websocket.html
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44

47. Сообщение от Аноним (-), 26-Апр-14, 02:55	–1 +/–
> а после экстренного ребута сервера nginx вообще не взлетит, В нормальных ДЦ не бывает "экстренных ребутов", ибо вменяемые админы и бесперебойники.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #54

48. Сообщение от Аноним (-), 26-Апр-14, 03:00	+/–
> Рекомендуют, так как им тестировщики нужны. А они не думали что тестировщик - это профессия такая? Раз уж они корпорация с коммерческими блобиками - наверное можно и команду тестировщиков тогда нанять.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #51

49. Сообщение от тигар (ok), 26-Апр-14, 10:41	+/–
>>/s.aspx?sm=nQUaqZCCgCT1gpjs+uGOvw== >> aspx? > Ты бы хотел, чтоб в следующий раз опрос был на mod_lua?   > /s.lua?sm=nQUaqZCCgCT1gpjs+uGOvw==, да? ngx_lua_module, двоешниг, mod_штота это опач. а опач нужен в 2014 году только для того чтобы организовать http[s] перед svn и на этом, пожалуй, все.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #56

50. Сообщение от Аноним (-), 26-Апр-14, 11:41	–2 +/–
> Nginx крут тем что уже достаточно фичаст для того чтобы им можно было пользоваться, а не чертыхаться на все и вся Чтобы не чертыхаться на отсутствие поддержки htaccess, нужна исключительная сила воли и любовь к Сысоеву.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #55

51. Сообщение от Аноним (-), 26-Апр-14, 11:43	–1 +/–
> А они не думали что тестировщик - это профессия такая? Раз уж > они корпорация с коммерческими блобиками - наверное можно и команду тестировщиков > тогда нанять. Использовать халявных - более выгодно, так как снижает расходы компании. BSD-way же!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48

52. Сообщение от Аноним (-), 26-Апр-14, 11:45	+/–
> Впрочем, те, кому это действительно нужно, могли бы и патч поддерживать, он > простенький же должен получаться. Это много кому нужно, но в мейнстрим не пустят принципиально, так что гемор получится приличный. А в мейнстрим, скорее всего, не пускают, чтобы сделать это в качестве эксклюзивной фичи nginx gold enterprise edition.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35

53. Сообщение от Аноним (-), 26-Апр-14, 11:47	+/–
> ай беда... как же теперь быть шаредпомойкам... Учитывая, что шаредпомойки - это не меньше половины рынка вебни, правильно сказать "как же быть Сысоеву?"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24

54. Сообщение от Аноним (-), 26-Апр-14, 11:48	+1 +/–
> В нормальных ДЦ не бывает "экстренных ребутов", ибо вменяемые админы и бесперебойники. И бэкапов там не делают, по той же причине.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47

55. Сообщение от XoRe (ok), 26-Апр-14, 23:13	+1 +/–
>> Nginx крут тем что уже достаточно фичаст для того чтобы им можно было пользоваться, а не чертыхаться на все и вся > Чтобы не чертыхаться на отсутствие поддержки htaccess, нужна исключительная сила воли и > любовь к Сысоеву. htaccess не нужен всем поголовно. Да, шаред хостингам он нужен, т.к. ещё полно cms'ок, которые написаны так, чтобы его использовать. Поэтому на шаред хостингах стоит апач бекендом (а фронтенд - давно nginx). Но и то - просто потому, что клиенты не умеют/не хотят отказаться от htaccess. А клиент платит - клиент получает. Это единственная объективная причина, когда можно оставить apache. Ах да, ещё есть свой хостинг разработчиков, которые пишут сайты на заказ. Но это подвид шаред хостинга - все делается для клиента. В остальных случаях (т.е. когда сайт свой) можно сказать, что все упирается в скилл/лень админов и разработчиков. Т.е. причины уже субьективные.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50

56. Сообщение от XoRe (ok), 26-Апр-14, 23:17	+/–
> а опач нужен в 2014 году только для того чтобы организовать http[s] > перед svn и на этом, пожалуй, все. Ещё redmine (и ещё что-нибудь на ruby пускать) через mod_passenger, а потом лениться переделывать :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49

57. Сообщение от XoRe (ok), 26-Апр-14, 23:23	+/–
> (из любопытства - нет, я реально не слежу за ситуацией) - nginx > уже научился htaccess? Наверное никогда. Но это нужно, по большому счету, только на шаред хостингах. Ну и на хостингах разрабов (которые пишут сайты для размещения на шаред хостингах). Т.е. это одна ниша, причем не самая большая. А для своего сайта логику из htaccess можно впихнуть в конфиг nginx.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

58. Сообщение от XoRe (ok), 26-Апр-14, 23:24	+/–
> УРА! sni!!!! Интересно, напуркуа брать SNI от бекенда.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

59. Сообщение от Аноним (-), 28-Апр-14, 16:46	–1 +/–
nginx шаред хостингу не нужен даже перед апачем. Где он будет хранить n TB статики? А еще в шаред хостинге нет необходимости в эффективности. А если речь идет о быстродействии php на толстых серверах, то одним nginx там тоже не обойтись. Опять же, .htaccess это не только простота и гибкость, но и безопасность. Так что каждому свое и каждый для своего.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #61

60. Сообщение от vovans (ok), 28-Апр-14, 17:10	+/–
Зачем запятая перед "что"?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40

61. Сообщение от Аноним (-), 28-Апр-14, 19:01	+/–
Нужен, чтобы у апача воркеры подолгу не висели во время отдачи ответов сервера. Апач гораздо лучше работает по принципу: быстро получил запрос от nginx - обработал - быстро отдал ответ nginx'у, чем по принципу: принял запрос от (потенциально медленного, напр. мобильного) клиента - обработал запрос - медленно отдал ответ клиенту.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59

62. Сообщение от Аноним (-), 28-Апр-14, 19:35	+/–
Может все-таки префорки, а не воркеры?
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема