Comments 64
omploader.org вас кинул )
Да что ж это такое? Срочно подскажите нормальный картинко-хостинг.
S3
У imageshack.us тоже есть ограничения.
Используйте (да-да, опять реклама) pict.com, picasaweb.google.com, fotki.yandex.ru
Используйте (да-да, опять реклама) pict.com, picasaweb.google.com, fotki.yandex.ru
fotki.ru
dropbox
он вернулся :)
Вам следует посмотреть на gevent/eventlet (оба используют greenlet). Они могут действовать следующим образом — производится замена стандартного модуля socket на неблокирующий (monkey-patching), и соответственно все библиотеки, которые используют python-сокеты становятся неблокирующими (к сожалению или к счастью к ним НЕ относится ни python-mysql ни psycopg2, но есть mysql-connector и pg8000).
Интересно, про pg8000 не слышал, спасибо.
Django я не пробовал так запускать, потому что не использую его, но вот SQLAlchemy прекрасно работает таким образом в неблокирующем стиле.
Можно Svarga тогда смело запускать, он на SQLAlchemy крутится. А для Django в любом случае надо будет написать свой БД бэкенд для pg8000 или mysql-connector, и тоже запустить, дело часа.
Кстати, нашел недостаток подхода, как мне кажется. В pgasync есть пул соединений. Когда вы запрашиваете соединение, то на самом деле ничего не происходит, интересное начнется только в момент получения курсора, из пула вам выделят соединение.
Это решает проблему, что будет, если к вам придет 100 пользователей в секунду — получите ли вы 100 подключений к БД? По-моему это не очень хорошо. Второе это установка соединения — синхронный код ничего не знает о пуле, и вполне способен устанавливать соединение на каждый запрос.
Это как раз момент, с которым я немного подвис с pgasync — думаю как лучше работать с пулом, когда возвращать подключение в пул.
Это решает проблему, что будет, если к вам придет 100 пользователей в секунду — получите ли вы 100 подключений к БД? По-моему это не очень хорошо. Второе это установка соединения — синхронный код ничего не знает о пуле, и вполне способен устанавливать соединение на каждый запрос.
Это как раз момент, с которым я немного подвис с pgasync — думаю как лучше работать с пулом, когда возвращать подключение в пул.
Дык эта, Грааль нашли уже давно :-P
UFO just landed and posted this here
Тут как раз предлагается вариант, когда усложнений в коде не появляется.
UFO just landed and posted this here
Во-первых прекрасно понятно как — подводных камней нет, или по крайней мере с ними все понятно. А теперь начинаем считать стоимость разработки с нуля всего кода, что уже есть. Затем вспоминаем, что программирование на C++ это известный ужас, в сравнении с Python, и стоить будет еще дороже. Итак, пару дней на допил моего варианта, или всё с нуля, и с песнями, и еще кучу денег на зарплаты программистам, а дедлайн как нибудь потом?
UFO just landed and posted this here
Что именно будет делать django в течении времени, когда происходит ввод/вывод?
UFO just landed and posted this here
Как этого можно добиться, не переписывая все приложение с нуля? Как Вы будете реендерить страничку для другого пользователя, если приложение написано для работы в одном процессе?
С другой стороны, у нас нет простоев и потерь времени на ожидание IO, потери у нас только на переключение контекста и порождение новых процессов, чтобы его минимизовать есть префорк. Выигрышь будет копейки. Единственное, где можно выиграть, ИМХО, в отдаче статики. Но это и так делается, через нгингс.
С другой стороны, у нас нет простоев и потерь времени на ожидание IO, потери у нас только на переключение контекста и порождение новых процессов, чтобы его минимизовать есть префорк. Выигрышь будет копейки. Единственное, где можно выиграть, ИМХО, в отдаче статики. Но это и так делается, через нгингс.
Есть же мультиплексоры ввода-вывода, такие как select, epoll, kqueue, с помощью них во время ожидания на I/O, можно выполнять другой код.
Greenlet же это userspace поток, то есть вычисление, которое можно «заморозить», а потом продолжить. С помощью них реализуется вытесняющая многозадачность. Таким образом, в одном OS-процессе мы имеем несеолько greenlet'ов, по одному на каждый запрос например, во время ожидания одного greenlet'а на I/O, какой-то другой greenlet можеть продолжать выполнение, обслуживая другого пользователя.
Greenlet же это userspace поток, то есть вычисление, которое можно «заморозить», а потом продолжить. С помощью них реализуется вытесняющая многозадачность. Таким образом, в одном OS-процессе мы имеем несеолько greenlet'ов, по одному на каждый запрос например, во время ожидания одного greenlet'а на I/O, какой-то другой greenlet можеть продолжать выполнение, обслуживая другого пользователя.
Т.е. выигрыш должен получиться за счет меньшего потребления ресурсов на переключение greenlet-овских минипотоков, по сравнению потреблением ресурсов на переключение контекста процессов ОС?
Мое мнение — на Win32 и Apache на процессах возможно имеет смысл, на UNIX/LINUX выигрыш должен быть небольшим. Но надо учитывать, что будет проигрыш в надежности.
Мое мнение — на Win32 и Apache на процессах возможно имеет смысл, на UNIX/LINUX выигрыш должен быть небольшим. Но надо учитывать, что будет проигрыш в надежности.
> Мое мнение — на Win32 и Apache на процессах возможно имеет смысл, на UNIX/LINUX выигрыш должен быть небольшим.
А какая разница?
> Но надо учитывать, что будет проигрыш в надежности.
Тоже непонятно откуда такой вывод.
А какая разница?
> Но надо учитывать, что будет проигрыш в надежности.
Тоже непонятно откуда такой вывод.
— Разница в том, что в Win32 очень медленное порождение процессов, поэтому там все, что требует мало-мальской производительности должно быть на тредах.
— Потому, что уровень изоляции параллельных задач в тредах по определению хуже, чем в процессах. Главное, в случае фатальной ошибки в приложении на процессах рушится один процесс, то в приложении на тредах — все приложение.
— Потому, что уровень изоляции параллельных задач в тредах по определению хуже, чем в процессах. Главное, в случае фатальной ошибки в приложении на процессах рушится один процесс, то в приложении на тредах — все приложение.
Так мы же говорим о greenlet'ах, причём тут процессы?
А с чем сравниваем? ИМХО, с базовой реализацией/ обычной конфигурацией. А обычная конфигурация, это апач и каждый клиент обслуживается префоркнутым процессом апача.
Или я не понимаю вообще о чем мы говорим.
Или я не понимаю вообще о чем мы говорим.
Вы, видимо, уже сравниваете prefork на Windows и prefork на Unix :-).
Виндовс: Префорк vs greenlets
UNIX: префорк vs greenlets
UNIX: префорк vs greenlets
Переключение между greenlet'ами намного быстрее чем между процессами и даже потоками Windows/UNIX.
Вытесняющая? Вы точно о гринлетах?
не только статика. nginx позволяет еще экономить на обработке медленных клиентов. nginx пока не получит всех необходимых данных не передает из далее по цепочке. Как результат нет процессов FastCGI которые ожидают завершения ввода/вывода.
Запустить рядом еще одну джангу?
есть мнение, что С++ — редкостной неизящности язык. Скажем так, в нем десятки способов выстрелить себе в ногу. Помимо производительности у него больше особых плюсов не водится. Ах да, производительность… Тогда уж Java хотя бы.
К сожалению, ничего другого в настоящее время на горизонте не видно.
UFO just landed and posted this here
Так, а вот про операционки — это вы поподробней. Какая из больших современны ОС написана на С++?
Я вот искренне всегда думал про С.
Я вот искренне всегда думал про С.
UFO just landed and posted this here
Linux: Most of the code (71%) was written in the C programming language.
Windows — то же самое, может, процент плюсов чуть больше.
На чистых плюсах написаны BeOS и WinCE / WinMobile
Windows — то же самое, может, процент плюсов чуть больше.
На чистых плюсах написаны BeOS и WinCE / WinMobile
На C пишут, и очень много, вас кто-то ввел в заблуждение.
Мы говорим про Веб. А в вебе Ява — языки под JVM — в определенных областях рулит. Например, резко масштабируемые приложения со Scala.
В системных вещах непревзойден C; компиляторы/интерпретаторы тоже на нем пишутся.
C++ — больше десктоп и верхний слой графических API в разных ОС. Ну и игры. Еще пишут, случается, штуки вроде поисковиков — я на собеседовании был, где такая работа подразумевалась.
В системных вещах непревзойден C; компиляторы/интерпретаторы тоже на нем пишутся.
C++ — больше десктоп и верхний слой графических API в разных ОС. Ну и игры. Еще пишут, случается, штуки вроде поисковиков — я на собеседовании был, где такая работа подразумевалась.
UFO just landed and posted this here
Черт, не понимаю, почему бы и нет? Чем django так элитарна, что ее нельзя заставить работать асинхронно? Почему бы не использовать асинхронность? Nginx сильно поиграл от нее? Tornado проиграл? Или быть может Node.js неюзабельный отстой? Давайте конкретно — чем плоха асинхронная Django? Да, она не даст вам скорости Node.js, так как Python в текущей реализации в C код не транслируется на лету, но выжать заветные 5-10% (и это чисто умозрительная прикидка), чем это плохо?
По-моему гораздо наивнее начать переписывать код на C++.
По-моему гораздо наивнее начать переписывать код на C++.
Взяв немного фантазии, буханку хлеба и две спицы, можно сделать троллейбус. Но зачем? (с)
Я вам страшную вещь скажу. В обычном веб-приложении 80% времени работы занимает ожидания ввода-вывода. И пусть ваше с++ приложение (разработанное в 10 раз дольше) работает не 0.5сек, а 0.05 — без того же самого неблокирующего ввода-вывода оно будет висеть и 5 секунд ждать ответа от базы.
У с++ есть своя ниша, где он востребован — но для разработки надо очень хорошо представлять, где и какой инструмент применять, его ограничения и возможности их обхода.
У с++ есть своя ниша, где он востребован — но для разработки надо очень хорошо представлять, где и какой инструмент применять, его ограничения и возможности их обхода.
Писать код не на C/C++ дешевле и быстрее. Если у вас миллион клиентов, то уже другие суммы у вас будут — то ли этот миллион обслужится сотней серверов, то ли тремяста серверами, по-моему разница на лицо. Если можно выжать еще 5-10 процентов, то это надо сделать, тем более, что это дешево и быстро.
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Sign up to leave a comment.
Django в неблокирующем стиле, или в погоне за Священным Граалем