DjangoBB LoFi version

Полная версия: WSGI, где многопоточность???

Начало » Web » WSGI, где многопоточность???

1 2 3 4

o7412369815963

Июль 28, 2010 20:00:38

alexx11
o7412369815963 О! респект и уважуха что разобрался, а теперь ответь на вопрос пожалуйста, если не sleep а поиск из массива вставить, ну как из предыдущего примера, то второй клиент зависнет или нет?

Хороший вопрос.

Время одного построения страницы.
processes=1 threads=5, $ ab -n 10 http://localhost/

Time taken for tests:   62.128 seconds
Time per request:       6212.754 [ms] (mean)

В среднем 6,2 сек (этот комп у меня по слабее, чем тот на работе)

Терь тестируем:
processes=1 threads=5, $ ab -n 5 -c 5 http://localhost/, одновременно 5 запросов

Concurrency Level:      5
Time taken for tests:   31.933 seconds
Complete requests:      5
Failed requests:        3
   (Connect: 0, Receive: 0, Length: 3, Exceptions: 0)
Write errors:           0
Total transferred:      1103 bytes
HTML transferred:       153 bytes
Requests per second:    0.16 [#/sec] (mean)
Time per request:       31932.981 [ms] (mean)
Time per request:       6386.596 [ms] (mean, across all concurrent requests)
Transfer rate:          0.03 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    4   3.0      6       6
Processing: 25680 30679 2794.1  31927   31932
Waiting:     6368 21794 9707.2  25678   31927
Total:      25681 30682 2796.0  31933   31933

потрачено 32 сек, запросы выполнились последовательно, последний запрос висел все 32 сек, первый вернулся за 6 сек. пока все как по теории.

processes=5 threads=1, $ ab -n 5 -c 5 http://localhost/, выделим 5 процессов для wsgi

Concurrency Level:      5
Time taken for tests:   13.177 seconds
Complete requests:      5
Failed requests:        1
   (Connect: 0, Receive: 0, Length: 1, Exceptions: 0)
Write errors:           0
Total transferred:      1104 bytes
HTML transferred:       154 bytes
Requests per second:    0.38 [#/sec] (mean)
Time per request:       13177.003 [ms] (mean)
Time per request:       2635.401 [ms] (mean, across all concurrent requests)
Transfer rate:          0.08 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    8  11.6      8      25
Processing: 11740 12729 571.6  12962   13160
Waiting:    11740 12724 569.3  12953   13152
Total:      11741 12737 575.8  12962   13177

как видим все запросы выполнились примерно за 12 сек одновременно, проц при этом лежал на полке (100% загрузка), у меня Core Duo 6750, 2 Ядра - попробуем 2 запроса: $ ab -n 2 -c 2 http://localhost/

Concurrency Level:      2
Time taken for tests:   5.734 seconds
Complete requests:      2
Failed requests:        1
   (Connect: 0, Receive: 0, Length: 1, Exceptions: 0)
Write errors:           0
Total transferred:      441 bytes
HTML transferred:       61 bytes
Requests per second:    0.35 [#/sec] (mean)
Time per request:       5734.235 [ms] (mean)
Time per request:       2867.117 [ms] (mean, across all concurrent requests)
Transfer rate:          0.08 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:  4866 5300 614.0   5734    5734
Waiting:     4866 5300 614.1   5734    5734
Total:       4866 5300 614.1   5734    5734

все четко, каждому запросу по ядру, время выполнения обоих 5 сек параллельно.

Теперь посмотрим как mod_wsgi раздает задачи, сначала по потокам или по процессам.
processes=5 threads=5, $ ab -n 5 -c 5 http://localhost/

Concurrency Level:      5
Time taken for tests:   13.482 seconds
Complete requests:      5
Failed requests:        0
Write errors:           0
Total transferred:      1105 bytes
HTML transferred:       155 bytes
Requests per second:    0.37 [#/sec] (mean)
Time per request:       13481.948 [ms] (mean)
Time per request:       2696.390 [ms] (mean, across all concurrent requests)
Transfer rate:          0.08 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.1      0       1
Processing: 12058 12598 596.2  12682   13481
Waiting:    12058 12595 591.6  12682   13469
Total:      12059 12598 596.3  12682   13482

все запросы выполнились параллельно, значит сначала идет раздача по процессам

ну и в заключение сделаем смешанную нагрузку
processes=5 threads=5, $ ab -n 10 -c 10 http://localhost/ , теоретический должно быть примерно 13 сек * 2 слоя = 26 сек, (2 слоя т.е. 5 потоков начнут работать, 5 повиснут из-за gil. один слой из 5 запросов выполняется примерно 13сек), смотрим…

Concurrency Level:      10
Time taken for tests:   27.046 seconds
Complete requests:      10
Failed requests:        1
   (Connect: 0, Receive: 0, Length: 1, Exceptions: 0)
Write errors:           0
Total transferred:      2209 bytes
HTML transferred:       309 bytes
Requests per second:    0.37 [#/sec] (mean)
Time per request:       27045.770 [ms] (mean)
Time per request:       2704.577 [ms] (mean, across all concurrent requests)
Transfer rate:          0.08 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0   14  11.1     12      28
Processing: 12530 22150 5626.7  25048   27043
Waiting:    12017 18411 5398.7  19916   27017
Total:      12559 22164 5626.2  25060   27045

так и есть.

alexx11

Июль 29, 2010 05:49:27

И всё таки она крутится =) Значит несмотря на GIL можно вполне спокойно жить, и наслаждаться многозадачностью.

Андрей Светлов

Июль 29, 2010 08:36:19

Дался вам этот GIL. Чаще всего его ругают те, у кого собственные руки кривые.

o7412369815963

Июль 29, 2010 09:16:13

и вообще говорят gil есть во всех интерпретаторах (хотя это не так), но только питоновский ставят ребром и пытаются его улучшить.

alexx11

Июль 29, 2010 12:36:31

Андрей Светлов
Дался вам этот GIL. Чаще всего его ругают те, у кого собственные руки кривые.

wikipedia
При своей работе основной интерпретатор Python постоянно использует большое количество потоково-небезопасных данных.

Я считаю при создании о пряморуких как-то не сильно думали=). Так-что внимательно изучаем изгибы и смотрим за что ухватиться.

kmax

Июнь 16, 2011 17:47:50

задался вопросом, повторить эксперимент с многопоточностью.
И выяснилась, одна неприятная весчь.
Конечно, тредов можно наплодить, НО процесс который их держит будет работать на одном ядре/процессоре.
Т.е. на четырех ядерном процессоре, mod_wsgi приложение в 4 потока будет работать, так будто доступно только одно ядро из четырех.

Да! Можно запустить четыре процесса, в каждом из которых будет несколько тредов, но в таком случае, расход памяти увеличится (каждый процесс будет кушать память отдельно)
Память для кеширования придется вывести из памяти процесса, так как кеш не будет общим для тредов из разных процессов.

Пробовал:
apache2 + mod_wsgi
nginx + mod_uwsgi
rocket (python based webserver)

Поправьте меня.
Расскажите как сделать чтобы треды в wsgi использовали бонус многопроцессорности.

o7412369815963

Июнь 16, 2011 18:30:25

> но в таком случае, расход памяти увеличится (каждый процесс будет кушать память отдельно)
нет, грубо говоря - память кушают треды, а не процессы.

> Память для кеширования придется вывести из памяти процесса, так как кеш не будет общим для тредов из разных процессов.
для этого есть мемкеш и подобные, и можно вывести не только из памяти процесса, но и из памяти сервера. т.е. на другой хост. например так использую при большой нагрузке, веб приложение запускают на нескольких серверах и у них ест общий “мемкеш”.

При маленькой нагрузке можно использовать обмен через БД.

> Расскажите как сделать чтобы треды в wsgi использовали бонус многопроцессорности.
На каждом ядре висят процессы, при появлении запроса на wsgi треде, раздаем всем процессам задачи. Но для веба это не нужно. Веб - это интерфейс. А тяжелую нагрузку отдаем “фоновому роботу” который не wsgi.

kmax

Июнь 17, 2011 06:19:56

Спасибо за ответ.

o7412369815963
>
> Расскажите как сделать чтобы треды в wsgi использовали бонус многопроцессорности.
На каждом ядре висят процессы, при появлении запроса на wsgi треде, раздаем всем процессам задачи. Но для веба это не нужно. Веб - это интерфейс. А тяжелую нагрузку отдаем “фоновому роботу” который не wsgi.

А где можно узнать подробнее про отдачу фоновым роботам которые не wsgi ? И желательно, чтобы это можно было равномерно распределить по кластеру роботов :) Асинхронно нескольким :)

Хочу придумать high-load велосипед, но знаний не хватает. И поэтому про роботов крайне интересно. Может кейвордсов для поиска подбросите.

Почему-то хочу, чтобы на python и wsgi :)

o7412369815963

Июнь 17, 2011 09:28:50

Термин “high-load” обычно относят к нагрузке от наплыва пользователей, большого кол-ва обращений. А мы здесь начали говорить о том как проц. загрузить - например можно запустить архивирование dvd фильма.

>А где можно узнать подробнее про отдачу фоновым роботам
Я в некоторых проектах использую xml-rpc, в некоторых “общение через базу”. При этом wsgi приложение не висит и ждет, а отрабатывает за 0,001сек - выводить текущий статус задачи/ процент выполнения.

> Хочу придумать high-load велосипед,
Сначала нужно определиться с целью (проектом).

Например то же архивирование dvd:
1) Прилетел запрос в wsgi, запускаем .sh скрипт, клиенту возвращаем “идет запуск”.
2) Этот скрипт в файлик пишет “идет архивирование” и запускает многопоточный архиватор, который грузит все ядра. После окончания архивирования, скрипт пишет в файлик “завершено”.
3) При очередном обращении клиента (можно по таймеру авторефреш страницы), wsgi приложение отдает содержимое файлика.

В итоге получили то что вы хотели: клиент зашел на страницу, жмякнул кнопку - на сервере пошла нагрузка всех ядер, клиенту на экран выводится состояние обработки.

kmax

Июнь 17, 2011 15:03:58

o7412369815963
Термин “high-load” обычно относят к нагрузке от наплыва пользователей, большого кол-ва обращений. А мы здесь начали говорить о том как проц. загрузить - например можно запустить архивирование dvd фильма.

Ну я про high-load термин, понимаю как система, которая позволяет “бесконечно” масштабироваться.
И конечно, большой наплыв посетителей/большое количество записей, возможно обработать, при достаточном количестве серверов.

Про определение с проектом - это да.

o7412369815963
>А где можно узнать подробнее про отдачу фоновым роботам
Я в некоторых проектах использую xml-rpc, в некоторых “общение через базу”. При этом wsgi приложение не висит и ждет, а отрабатывает за 0,001сек - выводить текущий статус задачи/ процент выполнения.

А xml-rpc - это по сути разве не http запрос?

Мдя, сразу стало понятно про роботов :)

Спасибо