Apache MPM Event

Я над этим работаю.

Для начала - не я хвалился, что nginx использует меньше памяти. Это утверждал netwind - подобные вещи уже не требуют доказательств и самоочевидны?

И какими настройками?

Это вот:

http://en.wikipedia.org/wiki/Slowloris

- Когда клиент меееедленно делает запрос.

Мне тоже кажется, что так разумнее.

Скопипастим классику:

Вообще-то, да. Меньше чем apache в пересчете на одного клиента. Вопрос лишь в том насколько меньше.

Фигню скопипастил. Напиши да или нет.

Реально использованный стек можно посмотреть в /proc/<pid>/smap, но нигде не видно включает ли значение суммарное значение rss этот стек.

Вот у меня стек в апачах очень большой - по 70 мб на процесс. Скорее всего он не используется весь.

Вообще-то нет. Программы - разные. nginx не создает тредов - ну так есть разные структуры данных, связанные с обрабатывающимися запросами. Ты ведь не обязан тупо верить, что они организованы оптимально?

А почему такие? Я выставил в nginx и апаче такие - что они не отказываются обработать штатную нагрузку на обычном , "средненьком" сервере. Поставлю 1024 - получу вопли от клиента по поводу ошибок. Это что, так nginx и должен работать? 🍿

Включает. Нужно было перевести текст?

Кстати, а как называется опция, которая у ps размер стека показывает? В man ps ничего путного по stack+size на накопал:

$ ps -V

procps version 3.2.8

Согласен. Тогда тестировать надо через wget --rate-limit.

Правда я считаю что основное потребление памяти приносит не mod_proxy, а накладные расходы на обслуживание существования соединения.

---------- Добавлено в 16:49 ---------- Предыдущее сообщение было в 16:48 ----------

Достаточными для того, чтобы обработать 1000 клиентов, но при этом, на Ваш взгляд, оптимальные по памяти.

---------- Добавлено в 16:50 ---------- Предыдущее сообщение было в 16:49 ----------

Ну не знаю. Можем увеличить размер теста и соответствующие настройки с 1000 коннектов до 50000 коннектов, результат-то от этого не изменится.

Надо перевести. я имел ввиду стек внутри процесса. очевидно, у каждого потока свой собственный стек. или нет?

предложение "SIZE is the virtual size of the process (code+data+stack) " относится к виртуальному размеру. то есть SIZE не связано с тем, сколько страниц из этого запрошенного стека реально использованы.

насчет ps я, кажется, ошибся. тоже не знаю как этот стект посчитать из данных ps.

Не стал выпендриваться, провёл сухой тест на стандартных настройках, смотрел реал тайм, выполнялись запросы, я копировал с htop процесс который обрабатывал запросы.

для себя сделал выводы почти всё одинакова.

Естественно запросы были к static

PID USER     PRI  NI  VIRT   RES   SHR S CPU% MEM%   TIME+  Command

3163 www-data  20   0 97780  2888  1392 S 69.0  0.1  0:06.50 /usr/sbin/apache2 -k start

3045 www-data  20   0 30576  1724   676 R 63.0  0.1  0:18.39 nginx: worker process 

nginx
root@debian:~# ab -n 100000 http://192.168.11.2:80/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 192.168.11.2 (be patient)
Completed 10000 requests
Completed 20000 requests
Completed 30000 requests
Completed 40000 requests
Completed 50000 requests
Completed 60000 requests
Completed 70000 requests
Completed 80000 requests
Completed 90000 requests
Completed 100000 requests
Finished 100000 requests



Server Software:        nginx/0.7.67
Server Hostname:        192.168.11.2
Server Port:            80

Document Path:          /
Document Length:        177 bytes

Concurrency Level:      1
Time taken for tests:   7.897 seconds
Complete requests:      100000
Failed requests:        0
Write errors:           0
Total transferred:      38800000 bytes
HTML transferred:       17700000 bytes
Requests per second:    12662.48 [#/sec] (mean)
Time per request:       0.079 [ms] (mean)
Time per request:       0.079 [ms] (mean, across all concurrent requests)
Transfer rate:          4797.89 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:     0    0   0.2      0      74
Waiting:        0    0   0.0      0       5
Total:          0    0   0.2      0      74

Percentage of the requests served within a certain time (ms)
  50%      0
  66%      0
  75%      0
  80%      0
  90%      0
  95%      0
  98%      0
  99%      0
 100%     74 (longest request)

apache2

root@debian:~# ab -n 100000 http://192.168.11.2:8080/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 192.168.11.2 (be patient)
Completed 10000 requests
Completed 20000 requests
Completed 30000 requests
Completed 40000 requests
Completed 50000 requests
Completed 60000 requests
Completed 70000 requests
Completed 80000 requests
Completed 90000 requests
Completed 100000 requests
Finished 100000 requests


Server Software:        Apache/2.2.16
Server Hostname:        192.168.11.2
Server Port:            8080

Document Path:          /
Document Length:        278 bytes

Concurrency Level:      1
Time taken for tests:   12.382 seconds
Complete requests:      100000
Failed requests:        0
Write errors:           0
Non-2xx responses:      100000
Total transferred:      48100000 bytes
HTML transferred:       27800000 bytes
Requests per second:    8076.40 [#/sec] (mean)
Time per request:       0.124 [ms] (mean)
Time per request:       0.124 [ms] (mean, across all concurrent requests)
Transfer rate:          3793.70 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:     0    0   0.3      0      94
Waiting:        0    0   0.3      0      94
Total:          0    0   0.3      0      94

Percentage of the requests served within a certain time (ms)
  50%      0
  66%      0
  75%      0
  80%      0
  90%      0
  95%      0
  98%      0
  99%      0
 100%     94 (longest request)
root@debian:~#

root@debian:~# dpkg -l | grep nginx
ii  nginx                               0.7.67-3                     small, but very powerful and efficient web server and mail proxy
root@debian:~# dpkg -l | grep apache
ii  apache2-mpm-event                   2.2.16-6+squeeze4            Apache HTTP Server - event driven model
ii  apache2-utils                       2.2.16-6+squeeze4            utility programs for webservers
ii  apache2.2-bin                       2.2.16-6+squeeze4            Apache HTTP Server common binary files
ii  apache2.2-common                    2.2.16-6+squeeze4            Apache HTTP Server common files
root@debian:~#

Был интересный момент с тестом.

ab -n 100000 -c 10 http://192.168.11.2:8080/

ab -n 100000 -c 10 http://192.168.11.2:80/

Я уже не стал копировать, nginx выполняет шустрее но грузит на 100% CPU

apache выполнил более мягче и нагрузил цпу на 80%

Порой nginx шустрый и быстрый, но всегда-ли нужна эта супер скорость.

покажи хоть, какие модули апачу накрутил

Наверно, это для большой статики адекватно. Посмотрел разные пузомерки (ab, siege, etc) - не нашел подобных ограничений. Хотелось бы стандартный бенчмарк показать, а не мой_кривой_скрипт_с_wget.sh

Думаешь, надо убрать модули ? - это даст выигрыш в обработке запросов ? ( статик запросов )

Всё выполнено base install

Мы же умные мы же глядим колонку RES )) зачем нам с библиотеками плюсовать.

Concurrency Level: 1 - никому не интересен.

10 - уже шаг к тому, при каких условиях нужно сравнивать.

еще надо как-то медленность клиента сымитировать.

поставьте -c 100, 500, 1000 и приведите результат :)