Форум сайта python.su
Как понимать ответ сервера на запрос - что это?
1. Отдельный процесс.
2. Отдельный поток.
3. Вообще ни-то ни другое, а всё работает только на внутренних событиях.
Я хочу понять одну вещь:
здесь пишут http://habrahabr.ru/blogs/python/84629/ что
>>> nums = xrange(100000000)
>>> -1 in nums # 1 тик (6,6 с)
import os
def small_ticks():
while True:
t = time.time()
time.sleep(0.1)
print time.time()-t
Офлайн
>И обещают что это залочит другие потоки этого приложения
по теории должно быть так
>Я проверил следующее, в двух консолях (одной машины естественно)
“одного приложения” != “одной машины”
при работе если wsgi приложение занято, то сервер создает ещё одно рядом, т.е. их будет несколько и они будут параллельно работать.
Отредактировано (Июль 22, 2010 08:48:51)
Офлайн
для интереса набросал пример, у меня на пару секунд блочится процесс.
# coding:utf8
import thread
import time
def myThread(param):
for x in xrange(10):
print x
time.sleep(0.2)
thread.start_new_thread(myThread, ('this param',))
time.sleep(0.5)
print 'start'
if -1 in xrange(100000000): pass
print 'finish'
time.sleep(2)
Офлайн
o7412369815963Наверное неплохой комп у тебя :D
для интереса набросал пример, у меня на пару секунд блочится процесс.
o7412369815963А приложение - это что? и сервер - это тоже что? Сорри, я просто с трудом догоняю таки штуки. Почему я спрашиваю? Если родитель сервера - питон, не будет ли в примере как выше, ведь внутри питона все “потоки” условные.
при работе если wsgi приложение занято, то сервер создает ещё одно рядом, т.е. их будет несколько и они будут параллельно работать.
Офлайн
alexx11Ответ какого сервера? apache? а они тоже бывают разные. Читайте про проектирование веб серверов - http://groups.google.ru/group/fido7.ru.unix.prog/browse_thread/thread/e8f8edf4f2f2447b/?pli=1
Как понимать ответ сервера на запрос - что это?
alexx11Вот тут стоит уточнить о каком “сервере”(на который обращаются) идет речь. Это будет apache, nginx, некий сервер приложений написанный на питоне или еще что?
А теперь внимание вопрос: что будет с пользователями которые обращаются на сервер запущенный через WSGI, в тот момент когда один из них исполняет “гигантский тик”, они будут out of service (как в первом случае) , или ощутят притормаживание (как во втором)?
Отредактировано (Июль 22, 2010 14:19:49)
Офлайн
alexx11Здесь как раз наоборот - родитель питона - apache :) Т е веб сервер порождает много процессов с питоном… как-то так вроде.
А приложение - это что? и сервер - это тоже что? Сорри, я просто с трудом догоняю таки штуки. Почему я спрашиваю? Если родитель сервера - питон, не будет ли в примере как выше, ведь внутри питона все “потоки” условные.
Отредактировано (Июль 22, 2010 14:38:46)
Офлайн
Alex2ndrХмм… Дело в том что ни apache ни других веб-серверов у меня нет ;) apache - это вообще отдельный user обычно, но разве вопрос об этом?
Здесь как раз наоборот - родитель питона - apache
Офлайн
Если ты запускаешь bottle.run() - это для дебага и разработки, в данном случае только один процесс - один приконектился, второй ждет.
для деплоймента нужно разворачивать нормальный сервак. хотя если кол-во клиентов будет не большим то можно и так оставить, у меня на работе 2 сервиса работает от bottle.run(), все довольны.
а на счет “залочит”, нужно делать так что-б контент моментально отдавался. у меня была версия блога которая генерировала страницы за 2мс, т.е. один поток мог обработать до 500 клиентов в секунду.
Офлайн
alexx11Если у вас самописный сервер на питоне то да - длительные атомарные операции будут все лочить. Как вариант можно делать многопроцессную версию, используя processing. Но там своих граблей навалом… Именно поэтому выгодно использовать apache - он распределяем запросы по процессам за нас.
Более того когда я запускаю под юзером приложение через WSGI я в ps axu могу наблюдать только обычный питон, что опять же подтверждает мои опасения того что один тик, будет всё лочить.
o7412369815963Вы же понимаете, что это идеальный вариант. Основная потеря времени происходит в сетевом общении - пересылка через медленные каналы, потеря пакетов, шейпер и тд. По локальной сети может и вариант, но уже в WAN такого не будет. Именно поэтому часто и нужна связка nginx+apache(т е фронтенд-бэкенд).
а на счет “залочит”, нужно делать так что-б контент моментально отдавался. у меня была версия блога которая генерировала страницы за 2мс, т.е. один поток мог обработать до 500 клиентов в секунду.
Офлайн
o7412369815963Ага, это типа дзена, я стараюсь :)
нужно делать так что-б контент моментально отдавался.
Alex2ndrА как программы не питоне запускать через mod_python или mod_wsgi?
Именно поэтому выгодно использовать apache - он распределяем запросы по процессам за нас.
Отредактировано (Июль 23, 2010 10:21:41)
Офлайн