Comments 16
С MS SQL Django из коробки работал или что-то дополнительно нужно ставить?
Из коробки python и django не умеет работать с MS SQL Server.
Нужно поставить питоний драйвер pyodbc и django драйвер django-pyodbc.
Нужно поставить питоний драйвер pyodbc и django драйвер django-pyodbc.
Интересно, когда Django заработает на IronPython? Очень хотелось бы иметь нативную поддержку IIS, писать питоновские модули на C# + полный доступ к .NET. Есть ли какие-нибудь подвижки в этом направлении? В плане производительности будет намного выигрышней, на мой взгляд
только не выкладывайте их в паблик, пожалуйста.
IronPython и поддержка его в Django — это не к нам. Как будет поддержка, так и добавим. Пока помоему и с обычным питоном неплохо получилось. К тому же чем больше таких Windows клиентов и хостингов, тем больше вероятность что разработки пойдут в этом направлении.
phasma: Кого не выкладывать и почему?
phasma: Кого не выкладывать и почему?
1. «писать питоновские модули на C# + полный доступ к .NET.» — можно мне преемущества этого рассказать?
и простите я все еще не понимаю зачем джангу запускать с иис — уже с ним столько тут писали и говорили. работая под иис вы ограничиваете себя платформами.
и простите я все еще не понимаю зачем джангу запускать с иис — уже с ним столько тут писали и говорили. работая под иис вы ограничиваете себя платформами.
1. У нас системы на .NET + Win Server 2008 + MSSQL
2. Я люблю Питон
3. Мне нравится Джанго
4. IronPython быстр и в нем нет GIL, поддерживает многопоточность
5. К нему можно писать модули на C# (может понадобится в работе со строками, где IronPython не очень быстр, а также для более сложной компонентой ООП архитектуры где имеют преимущество языки со строгой типизацией)
6. Разворачивать на существующей инфраструктуре. Не понадобится ставить *NIX со всеми вытекающими чтобы быстро разворачивать небольшие проекты.
7. Можно прикручивать к имеющимся БД MS SQL
8. "— можно мне преемущества этого рассказать?" — Для чего придумали Jython?
«Вы ограничиваете себя платформами» — это скорее религиозное понятие. Мы всего-лишь вибираем определенные инструменты для определенных задач, и пока нас все устраивает.
2. Я люблю Питон
3. Мне нравится Джанго
4. IronPython быстр и в нем нет GIL, поддерживает многопоточность
5. К нему можно писать модули на C# (может понадобится в работе со строками, где IronPython не очень быстр, а также для более сложной компонентой ООП архитектуры где имеют преимущество языки со строгой типизацией)
6. Разворачивать на существующей инфраструктуре. Не понадобится ставить *NIX со всеми вытекающими чтобы быстро разворачивать небольшие проекты.
7. Можно прикручивать к имеющимся БД MS SQL
8. "— можно мне преемущества этого рассказать?" — Для чего придумали Jython?
«Вы ограничиваете себя платформами» — это скорее религиозное понятие. Мы всего-лишь вибираем определенные инструменты для определенных задач, и пока нас все устраивает.
> Мы всего-лишь вибираем
> Не понадобится ставить *NIX со всеми вытекающими чтобы быстро разворачивать небольшие проекты.
Ваш первоначальный выбор резко сузил возможный выбор в будущем (для ваших коллег, например). Установку Linux сервера, кстати, можно автоматизировать так, что сайт будет разворачиваться вместе с системой вобще без участия человека.
> Не понадобится ставить *NIX со всеми вытекающими чтобы быстро разворачивать небольшие проекты.
Ваш первоначальный выбор резко сузил возможный выбор в будущем (для ваших коллег, например). Установку Linux сервера, кстати, можно автоматизировать так, что сайт будет разворачиваться вместе с системой вобще без участия человека.
запуск Django на IIS
Но зачем?
Быстро замените скрин с хромом на ие9 — это ж блог микрософта!
> Настройки везде по умолчанию, т.к. цель протестировать именно наиболее типичные конфигурации
Бредятина какая… Никто не использует настройки MySQL по умолчанию. И вобще конфиги выкладывать положено. И после этого: Ба! Чудеса в решете!
> Почему Nginx + fcgi + MySQL показал столь странные 175 запросов в секунду – не понятно.
…
> Для тестирования Apache и Nginx использовалась Ubuntu 11.04 Server x64. IIS 7 тесты > работали на Windows Server 2008 R2.
Нет чтобы сравнить nginx на Ubuntu/Windows + IIS Windows.
> Хочется отдельно отметить способность IIS 7 держать большое число подключений. в то время как Ubuntu, с настройками по умолчанию, с ростом числа подключений быстро пасовала.
По графикам этого не скажешь… У nginx+ubuntu даже «по умолчанию» графики заметно лучше.
p.s.
А пинать апач в наши дни за prefork — дело неблагородное.
Бредятина какая… Никто не использует настройки MySQL по умолчанию. И вобще конфиги выкладывать положено. И после этого: Ба! Чудеса в решете!
> Почему Nginx + fcgi + MySQL показал столь странные 175 запросов в секунду – не понятно.
…
> Для тестирования Apache и Nginx использовалась Ubuntu 11.04 Server x64. IIS 7 тесты > работали на Windows Server 2008 R2.
Нет чтобы сравнить nginx на Ubuntu/Windows + IIS Windows.
> Хочется отдельно отметить способность IIS 7 держать большое число подключений. в то время как Ubuntu, с настройками по умолчанию, с ростом числа подключений быстро пасовала.
По графикам этого не скажешь… У nginx+ubuntu даже «по умолчанию» графики заметно лучше.
p.s.
А пинать апач в наши дни за prefork — дело неблагородное.
>Бредятина какая… Никто не использует настройки MySQL по умолчанию. И вобще конфиги выкладывать положено. И после этого: Ба! Чудеса в решете!
Цель была не померять кто круче, а показать насколько предствленное решение готово или нет к использованию на боевом сервере. А так оптимизировать можно много чего… Нас интересовало как система работает «из коробки».
>Нет чтобы сравнить nginx на Ubuntu/Windows + IIS Windows.
Хорошая идея! Постараемся добавить еще этот тест.
>По графикам этого не скажешь… У nginx+ubuntu даже «по умолчанию» графики заметно лучше.
На графиках показано количетсво запросов в секунду. Этот параметр сильно зависит от производительности самого интерпретатора питона, и тут есть куда расти, но видно что уже вполне на уровне.
Сейчас для веб приложений важнее даже не количество запросов в секунду, а скорее количество клиентов, которых оно может обслуживать одновременно. Этот параметр по-правильному померять намного сложнее. К сожалению просто не хватает времени на все.
>А пинать апач в наши дни за prefork — дело неблагородное.
Больше не будем.
Цель была не померять кто круче, а показать насколько предствленное решение готово или нет к использованию на боевом сервере. А так оптимизировать можно много чего… Нас интересовало как система работает «из коробки».
>Нет чтобы сравнить nginx на Ubuntu/Windows + IIS Windows.
Хорошая идея! Постараемся добавить еще этот тест.
>По графикам этого не скажешь… У nginx+ubuntu даже «по умолчанию» графики заметно лучше.
На графиках показано количетсво запросов в секунду. Этот параметр сильно зависит от производительности самого интерпретатора питона, и тут есть куда расти, но видно что уже вполне на уровне.
Сейчас для веб приложений важнее даже не количество запросов в секунду, а скорее количество клиентов, которых оно может обслуживать одновременно. Этот параметр по-правильному померять намного сложнее. К сожалению просто не хватает времени на все.
>А пинать апач в наши дни за prefork — дело неблагородное.
Больше не будем.
> Цель была не померять кто круче, а показать насколько предствленное решение готово или нет к использованию на боевом сервере.
Вот представим картину. «из коробки» буфферы настроены из расчета 512 мб ОЗУ. При вашем кол-ве запросов, многоядерном цпу и предполагаемых 512 мб нафиг летит оптимизационная схема, выбранная планировщиком БД. Причем она летит по-разному под Lin и под Win. Любой, кто работает с БД, скажет вам, что мерять надо «не виртуальное что-то там», а конкретный реальный сервис.
Лично мои ожидания от такого рода статей: адекватная одинаковая оптимизация + конфиги в паблик.
Ну и АБ, имхо, не очень подходит для тестирования в вашем случае, поскольку нужно не кол-во запросов, а эмулировать клиента. Теоретически я бы даже мог помочь вам с написанием таких тестов, но ваш выбор технологий явно не для меня.
Вот представим картину. «из коробки» буфферы настроены из расчета 512 мб ОЗУ. При вашем кол-ве запросов, многоядерном цпу и предполагаемых 512 мб нафиг летит оптимизационная схема, выбранная планировщиком БД. Причем она летит по-разному под Lin и под Win. Любой, кто работает с БД, скажет вам, что мерять надо «не виртуальное что-то там», а конкретный реальный сервис.
Лично мои ожидания от такого рода статей: адекватная одинаковая оптимизация + конфиги в паблик.
Ну и АБ, имхо, не очень подходит для тестирования в вашем случае, поскольку нужно не кол-во запросов, а эмулировать клиента. Теоретически я бы даже мог помочь вам с написанием таких тестов, но ваш выбор технологий явно не для меня.
Я абсолютно и полностью с вами согласен! Но проводить такое тестирование в разы сложнее. К сожалению у нас маленькая команда и мы физически не успеваем столько сделать. Нужно же еще программировать, доводить продукт, внедрять его у хостингов. Сейчас работаем над поддержкой node.js, Sinatra, Tornado, Chicago Boss, почти доделали асинхронность (comet) в рельсах 3.0, работаем над интеграцией с хостинг панелями. При этом ни производители платформ, ни open source коммюнити и пальцем не пошевелят чтобы как-то поучаствовать. Твитнуть разок в своей ленте — большее на что мы можем расчитывать. Одни хостинги готовы сотрудничать, потому что сразу видят свою выгоду. Но что с них взять — разьве что платформу для тестирования…
Цель тестирования была на скорую руку показать что данное решение находится «примерно на уровне» и его можно использовать. Подавляющее большинство тестов в сети вообще меряют Hello World-ы и ничего.
Более полное тестирование возможно будет позже. Много позже…
Цель тестирования была на скорую руку показать что данное решение находится «примерно на уровне» и его можно использовать. Подавляющее большинство тестов в сети вообще меряют Hello World-ы и ничего.
Более полное тестирование возможно будет позже. Много позже…
Я абсолютно и полностью с вами согласен! Но проводить такое тестирование в разы сложнее. К сожалению у нас маленькая команда и мы физически не успеваем столько сделать. Нужно же еще программировать, доводить продукт, внедрять его у хостингов. Сейчас работаем над поддержкой node.js, Sinatra, Tornado, Chicago Boss, почти доделали асинхронность (comet) в рельсах 3.0, работаем над интеграцией с хостинг панелями. При этом ни производители платформ, ни open source коммюнити и пальцем не пошевелят чтобы как-то поучаствовать. Твитнуть разок в своей ленте — большее на что мы можем расчитывать. Одни хостинги готовы сотрудничать, потому что сразу видят свою выгоду. Но что с них взять — разьве что платформу для тестирования…
Цель тестирования была на скорую руку показать что данное решение находится «примерно на уровне» и его можно использовать. Подавляющее большинство тестов в сети вообще меряют Hello World-ы и ничего.
Более полное тестирование возможно будет позже. Много позже…
Цель тестирования была на скорую руку показать что данное решение находится «примерно на уровне» и его можно использовать. Подавляющее большинство тестов в сети вообще меряют Hello World-ы и ничего.
Более полное тестирование возможно будет позже. Много позже…
Sign up to leave a comment.
Быстрый и автоматический запуск Django на IIS 7.x в production-среде (+ тесты производительности)