asp.net тормозная
А ты как думаешь что медленне компилирпуемый или интерпретируемый язык? Сам подумай!
что-то я не понял, кто из них компилируемый, а кто интерпретируемый?
На самом деле как и автор данного треда до конца не разобьрался в понятиях, о которых говорит. ASP.NET это не язык, а технология. Язык - C# (или VB и я надеюсь все сдесь понимают что этот язык - компилируемый
вовремя исправил... всю жизнь ASP на VB и VBScript писали
net память любит.
а так судя по тестам:
на слабом железе - быстрее Apache+PHP+mysql
на сильном железе - быстрее IIS+Asp.net+MSSQL
т.е. связка asp.net-и-товарищи более требовательная к мин. ресурсам, зато намного лучше масштабируется
а так судя по тестам:
на слабом железе - быстрее Apache+PHP+mysql
на сильном железе - быстрее IIS+Asp.net+MSSQL
т.е. связка asp.net-и-товарищи более требовательная к мин. ресурсам, зато намного лучше масштабируется
Да я чё-та многа пи ва выпил 
Сам на С# только пишу и забыл что там хоть на чём писать можно.
Добавим VF (fortran VP (perl VPAS (pascal) - это только то что я реально сволими глами видел. Говорят, под ASP.NET можна на более чем 10 языках писать
Сам на С# только пишу и забыл что там хоть на чём писать можно.
Добавим VF (fortran VP (perl VPAS (pascal) - это только то что я реально сволими глами видел. Говорят, под ASP.NET можна на более чем 10 языках писать
Позволю поспорить
Смотря что понимать под сильным жзелезом
2 процессорный 3,2+3,0 2гб - слабое железо?
А на нём php+apache под виндами (!) бегал быстрее iis'a
Смотря что понимать под сильным жзелезом
2 процессорный 3,2+3,0 2гб - слабое железо?
А на нём php+apache под виндами (!) бегал быстрее iis'a
Мне вот наоборот кажется, что дотНет идеальный рантайм для этого. С GC выделение большого числа маленьких объектов обходиться дешево. Есть апп домены. Есть все средства, чтобы эффективно взаимодействовать с нативным уровнем.
Хотелось бы услышать конкретно, причину медлительности asp.net (если она имеет место в чем конкретно она состоит.
Хотелось бы услышать конкретно, причину медлительности asp.net (если она имеет место в чем конкретно она состоит.
> Смотря что понимать под сильным жзелезом
> 2 процессорный 3,2+3,0 2гб - слабое железо?
на первый взгляд - более чем
> А на нём php+apache под виндами (!) бегал быстрее iis'a
на каких задачах это проверялось?
> 2 процессорный 3,2+3,0 2гб - слабое железо?
на первый взгляд - более чем
> А на нём php+apache под виндами (!) бегал быстрее iis'a
на каких задачах это проверялось?
ну.... лично мне не нравится то что при изменении кода пока дождусь перекомпиляции серьёзного кода можно успеть покурить
лично я был итнициатором теста, правда тут ещё база подключается....
3000 запросов к бд с созданием, выборкой, выводом на экран и удалением.
3000 запросов к бд с созданием, выборкой, выводом на экран и удалением.
тогда все-таки хотелось бы взглянуть и на тот, и на другой код, а также на полученные времена.
млин.... сложно.... (из той конторы ушёл) Попробую, но не гарантирую что найду (может заново напишу)
А где я про язык говорил.
Общие фразы типа быстрее-медленне не интересуют -- всегда можно сказать, что руки кривые.
Идея Даркгрея понятна, asp.net расходует больше памяти. Но давай рассматривать все такие серверный вариант, где памяти больше 512. В принципе в asp.net предпочитают модель, когда создается множетсво объектов, которые между собой взаимодействуют, а потом генерируют результат. Но разве в основной объем памяти не жрут непосредственно сами данные, из которых формируется вывод, плюс всякие кеши и буферы.
Общие фразы типа быстрее-медленне не интересуют -- всегда можно сказать, что руки кривые.
Идея Даркгрея понятна, asp.net расходует больше памяти. Но давай рассматривать все такие серверный вариант, где памяти больше 512. В принципе в asp.net предпочитают модель, когда создается множетсво объектов, которые между собой взаимодействуют, а потом генерируют результат. Но разве в основной объем памяти не жрут непосредственно сами данные, из которых формируется вывод, плюс всякие кеши и буферы.
Блин. Ну в любом случае это 2 разных подхода!
ASP - компилирумая штука, т.е. ри первом проходе грубо говоря медленно (пиздец как медленно) создаётся exe-шник, который при последующих обращения довольно резво исполняется
А PhP+Apache всегда одинакого построчково интерпритируется
ASP - компилирумая штука, т.е. ри первом проходе грубо говоря медленно (пиздец как медленно) создаётся exe-шник, который при последующих обращения довольно резво исполняется
А PhP+Apache всегда одинакого построчково интерпритируется
Есть какая-нибудь телега в самой архитектуре или недостаток в реализации?
ну компиляция не в счет, вряд ли она случается часто в сравнении с частотой запросов
потом разве нельзя ngen использовать с asp.net?
Ты для начала круг задач определи.
стат. контент или дин. контент.
с подстройкой под пользователя или нет.
с базой или нет.
основная задача - вывод каталога или отдельного элемента.
application level - есть или нет.
кол-во запросов в секунду.
вес отдельного запроса
и т.д.
стат. контент или дин. контент.
с подстройкой под пользователя или нет.
с базой или нет.
основная задача - вывод каталога или отдельного элемента.
application level - есть или нет.
кол-во запросов в секунду.
вес отдельного запроса
и т.д.
Хотелось бы выделить непосредственно ту часть, что зависит от asp.net. Если по порядку, то можно рассмотреть:
1) Обработка запроса с прямой записью в Response -- медленно/быстро (точнее: есть узкое место или все реализовано хорошо)
2) Инфраструктура страницы и взаимодействия с контролами -- на сколько дорого обходится, если сравнивать с 1)
3) Реализация основных контролов
4) Механизм привязки данных и вся соответствующая модель и ее архитектура (использование Датасетов и т.д.)-- как дорого обходится, если сравнивать с 1) + Датаоидером.
5) На сколько вообще честно сравнивать 2)+ с чистым пхп, что там за оверхед дают всякие Смарти.
6) На сколько эффективно можно пользоваться кешированиями, не отказываясь от 2)-4)
7) и т.д.
Где в реальных задачах возникают проблемы с производительностью по вине asp.net. Вернее интересней будет, где можно сделать asp.net лучше (что говорит о том, что сейчас не достаточно хорошо чтобы таких проблем возникало меньше?
1) Обработка запроса с прямой записью в Response -- медленно/быстро (точнее: есть узкое место или все реализовано хорошо)
2) Инфраструктура страницы и взаимодействия с контролами -- на сколько дорого обходится, если сравнивать с 1)
3) Реализация основных контролов
4) Механизм привязки данных и вся соответствующая модель и ее архитектура (использование Датасетов и т.д.)-- как дорого обходится, если сравнивать с 1) + Датаоидером.
5) На сколько вообще честно сравнивать 2)+ с чистым пхп, что там за оверхед дают всякие Смарти.
6) На сколько эффективно можно пользоваться кешированиями, не отказываясь от 2)-4)
7) и т.д.
Где в реальных задачах возникают проблемы с производительностью по вине asp.net. Вернее интересней будет, где можно сделать asp.net лучше (что говорит о том, что сейчас не достаточно хорошо чтобы таких проблем возникало меньше?
Ну и что собственно сравнивать.
Скорость для клиента или для разработчика?
Повторюсь - при отладке большого ресурса приходится много кода держать в башке, ибо укурится в смерть можно при частом рекомпилинге А на PhP в любом случае это дело 2 секунд
Даже при рекомпилинге "hello world" на своей достаточно мощной машие ты имеешь время откинутся на спинку кресла (с) и задуматься о вечном
Скорость для клиента или для разработчика?
Повторюсь - при отладке большого ресурса приходится много кода держать в башке, ибо укурится в смерть можно при частом рекомпилинге
А на PhP в любом случае это дело 2 секунд Даже при рекомпилинге "hello world" на своей достаточно мощной машие ты имеешь время откинутся на спинку кресла (с) и задуматься о вечном
> Даже при рекомпилинге "hello world" на своей достаточно мощной машие ты имеешь время откинутся на спинку кресла (с) и задуматься о вечном
что-то я совсем не понимаю о каком компилинге идет речь, почему он у тебя занимает столько времени и зачем его надо делать при отладке.
что-то я совсем не понимаю о каком компилинге идет речь, почему он у тебя занимает столько времени и зачем его надо делать при отладке.
ты меняешь код - asp перекомпилирует страницу. Сам попробуй. Ну про хелло ворлд я загнул конечно но при нормальном ресурсе ты минимум 2 минуты ждать будешь. ПОтом всё достаточно быстро
При этом эта падла даже на критические ошибки (вроде ошибки синтаксиса) будет всё равно кучу времени думать
но при нормальном ресурсе ты минимум 2 минуты ждать будешь. ПОтом всё достаточно быстро При этом эта падла даже на критические ошибки (вроде ошибки синтаксиса) будет всё равно кучу времени думать
Ни клиента, ни разработчика (в случае разработчика и так понятно, лучше пока разработку сравнивать не будет это отдельная тема) -- сервера.
Что ты так взъелся на эту компиляцию. Даже если допустить, что она тормозная как ты ее описываешь, неужели так часто приходиться компилировать что-то после размещения приложения? Я еще понимаю, если бы нужно было бы перекомпилировать весь код, но это ведь не так. Может опять руки кривые?
Что ты так взъелся на эту компиляцию. Даже если допустить, что она тормозная как ты ее описываешь, неужели так часто приходиться компилировать что-то после размещения приложения? Я еще понимаю, если бы нужно было бы перекомпилировать весь код, но это ведь не так. Может опять руки кривые?
имхо, надо идти не от этого.
на минуту допустим, что DataSet-ы, например, в 5 раз тормознее, чем DataReader-ы - и занимают аж 5мс вместо 1мс.
Означает ли это, что DataSet-ы нельзя использовать, и их надо переписывать?
Отталкиваться надо от задач, а не от времени выполнения одной какой-то "инструкции".
на минуту допустим, что DataSet-ы, например, в 5 раз тормознее, чем DataReader-ы - и занимают аж 5мс вместо 1мс.
Означает ли это, что DataSet-ы нельзя использовать, и их надо переписывать?
Отталкиваться надо от задач, а не от времени выполнения одной какой-то "инструкции".
Не, ну ё-моё!
Ты что то меняешь в коде, хочешь видеть плоды так сказать рук своих, а оно очень долго думает
Ты что то меняешь в коде, хочешь видеть плоды так сказать рук своих, а оно очень долго думает
имхо, ты что-то не так делаешь
сайт kinfo.ru: >350 файлов в проекте
первичный запуск под отладкой - 30 сек (причем большая часть времени занимает запуск webdev-а)
далее изменение любой страницы - <1сек.
сайт kinfo.ru: >350 файлов в проекте
первичный запуск под отладкой - 30 сек (причем большая часть времени занимает запуск webdev-а)
далее изменение любой страницы - <1сек.
на минуту допустим, что DataSet-ы, например, в 5 раз тормознее, чем DataReader-ы - и занимают аж 5мс вместо 1мс.под DataSet-ми тот же DataReader сидит, поэтому потери в производительности могут быть связаны только с валидацией, но на разумных объемах данных в большинстве случаев этот вклад не заметен
Означает ли это, что DataSet-ы нельзя использовать, и их надо переписывать?
Я не имеел в виду, что нужно рассматривать так примитивно на уровне отдельной операции. Т.е. в случае датасета нужно посмотреть, что в ситуациях, когда они используются, когда требуется определенная функциональность, на сколько возможна более эффективная реализация. что если учесть возможность/необходимость кешировать данные. Например, интересно на сколько сильно можно выиграть, если привязываться к своим объектам, вроде тоже удобно с этим в asp.net.
> под DataSet-ми тот же DataReader сидит, поэтому потери в производительности
там было слово "допустим"
> на разумных объемах данных в большинстве случаев не заметен
дык, я про это и говорю, что если идти от задачи, то разница во времени работы того или иного куска кода - уже по другому смотрится, и узкие места совсем по другому выглядят
там было слово "допустим"
> на разумных объемах данных в большинстве случаев не заметен
дык, я про это и говорю, что если идти от задачи, то разница во времени работы того или иного куска кода - уже по другому смотрится, и узкие места совсем по другому выглядят
там еще совсем другой режим расходования памяти будет со всеми вытекающими из этого последствиями, и реализация датасетов сильно динамическая (опять память, рефлекшион (а рефлекшион опять память
в целом, сильных косяков - нет, поэтому не имея на руках конкретной задачи сложно говорить где могут быть явные проблемы.
зачем reflection?
ладно про рефлекшион я загнул, он там и там немного будет
просто в случае байдинга, рефлекшиона больше
ps Немного подумал и уже не уверен про рефлекшион. Как датаридер, юзает рефлекшион? Имеется в виду дорогой рефлекшион, кастинг относительно дешевый.
просто в случае байдинга, рефлекшиона больше
ps Немного подумал и уже не уверен про рефлекшион. Как датаридер, юзает рефлекшион? Имеется в виду дорогой рефлекшион, кастинг относительно дешевый.
там еще совсем другой режим расходования памяти будет со всеми вытекающими из этого последствиями, и реализация датасетов сильно динамическая (опять память, рефлекшион (а рефлекшион опять памятьоткуда такие сведения?
попробуй прочитать все данные в память (а это обычно и требуется) Reader-ом, и те же данные загрузи в DataSet. Если снять Relation-ы и у DataAdapter-а поставить SchemaMissing.Error, то получишь тоже время.
DataReader и DataSet совсем, вроде, reflection не использует
reflection используется уже на уровне контролов DataRepeater/DataGrid и то уже скорее для бизнес-объектов, чем для DataSet-ов.
reflection используется уже на уровне контролов DataRepeater/DataGrid и то уже скорее для бизнес-объектов, чем для DataSet-ов.
по-моему тоже
Ридером не обязательно грузить все в память, можно в том же цикли писать в Ответ. (Это принципиальное отличие от Датасета).
Плюс в Датасете данные в объектах сидят (если я не ошибаюсь т.е. на всякие простые типы оверхед +8 байт на каждое значение -- так и в несколько раз может больше занимать. (Это уж не так принципиально, можно и в своих структурах данные в памяти держать, по крайней мере в asp.net 2.0 такой способ тоже удобный).
Плюс в Датасете данные в объектах сидят (если я не ошибаюсь т.е. на всякие простые типы оверхед +8 байт на каждое значение -- так и в несколько раз может больше занимать. (Это уж не так принципиально, можно и в своих структурах данные в памяти держать, по крайней мере в asp.net 2.0 такой способ тоже удобный).
Т.е. адаптер реализуется так, что загрузка производится без рефлекшиона. Хорошо, не знал 
ну, а зачем там reflection?
т.е. какой именно информации о DataReader/DataSet-е у нас нет на уровне компиляции?
т.е. какой именно информации о DataReader/DataSet-е у нас нет на уровне компиляции?
адаптер генерируетсячто ты под этим имеешь ввиду?
реализован
так и не понял как DataTable устроен
в DataReader на GetValue похоже делают много кейзов
Fill тогда наверно в цикле вызывает GetValue и так и заносит object куда надо, т.е. наверно все таки обходятся без рефлекшиона
PS в DataSet все так запутано, Reflector не помогает
в DataReader на GetValue похоже делают много кейзов
Fill тогда наверно в цикле вызывает GetValue и так и заносит object куда надо, т.е. наверно все таки обходятся без рефлекшиона
PS в DataSet все так запутано, Reflector не помогает
забейте на датасет...
говоря, что асп дот нет медленная я имел ввиду, что для создания одного и того же функционала asp.net гораздо больше ресурсов чем надо....
Допустим нам надо создать функционал регистрации пользователей.
На php это пишеться в 3 функции.
На asp.net прийдется подгрузить классы работы с файлами конфига, со строками, с регекспом для строк, сессии, и Web.UI с подклассамиб и класс для базы. Итого получаем, что бы зарегить пользователя, проверить его вводимые данные, а потом кинуть все это в базу и
аторизировать его через сессию надо грузануть дофига всего....
И в этом довига свего более половины методов классов нафиг не нужны для данной цели.
Итого чисто теоретически получаем здоровенную неповоротливыю дуру, от которой отпиливают для получения нужного....
А в php добавляют.
PS Если не нравится php - perl к вашим услугам
говоря, что асп дот нет медленная я имел ввиду, что для создания одного и того же функционала asp.net гораздо больше ресурсов чем надо....
Допустим нам надо создать функционал регистрации пользователей.
На php это пишеться в 3 функции.
На asp.net прийдется подгрузить классы работы с файлами конфига, со строками, с регекспом для строк, сессии, и Web.UI с подклассамиб и класс для базы. Итого получаем, что бы зарегить пользователя, проверить его вводимые данные, а потом кинуть все это в базу и
аторизировать его через сессию надо грузануть дофига всего....
И в этом довига свего более половины методов классов нафиг не нужны для данной цели.
Итого чисто теоретически получаем здоровенную неповоротливыю дуру, от которой отпиливают для получения нужного....
А в php добавляют.
PS Если не нравится php - perl к вашим услугам
На asp.net прийдется подгрузить классы работы с файлами конфига, со строками, с регекспом для строк, сессии, и Web.UI с подклассамиб и класс для базы. Итого получаем, что бы зарегить пользователя, проверить его вводимые данные, а потом кинуть все это в базу иНу и что, это не значит, что все будет работать тормозно. А что в пхп в базу залезать не надо. ИМХО это будет самой дорогой операцией. А всякая загрузка сборок делается один раз, не на каждый запрос. Конечно метаднанные+ил+х86 требуют памяти, но ИМХО +10-20мб воркинсет погоду не делают. Зато непосредственно обработка запроса заключается в создании и инициализации объектов, что в дотНете делается быстро. Да и шаблон работы с памятью, когда сначала объекты массово создаются, а потом после обработки запроса удаляются, очень хорошо работает с GC.
аторизировать его через сессию надо грузануть дофига всего....
И в этом довига свего более половины методов классов нафиг не нужны для данной цели.Да но они могут использоваться в других частях приложения. Методы, которые не используютя, не компилируются. Страницы, которые не используются со временем вытесняются в своп. Плюс системы сборки нгеняться и разделяются между приложениями.
Итого чисто теоретически получаем здоровенную неповоротливыю дуру, от которой отпиливают для получения нужного....
Не вижу я где, в каком месте, asp.net тормозит при обработке запроса.
Единственное, что еще вызывает определенное беспокойство, так это GC, который на одном из этапов сборки блокирует все потоки. Но этот момент я не могу оценить. Можету кого есть какая инфа?
ну незнаю незнаю...
на мой взгляд все таки ASP.net тормозная...
Это исходя из того, что я уже написал, + из опыта использования forum.local и films.hackers.
Как даркгрей писал в треде из которого родился этот, проблемы на филмах начинаются когда много юзеров грузят сервак. Но на форуме тоже немало юзеров сидит единовременно. так что примем, что нагрузка распределяется на эти два сервиса одинаково.
ДаркГрей писал, что тормоза возникают из-за запроса, определяющего непросмотренный фильмы и из-за запросов по фильтрам.
Объем базы я так прикидываю на форуме должен быть больше. и задача определения просмотренных тем тоже присутствует. Но решается она без каких-либо заметных задержек, даже когда на форуме сидит толпа юзеров.
Хотя бы из этого сравнения двух аналогичных задач можно прийти к выводу, что сервис фильмов гораздо тормознутее. Отсюда два варианта: либо галимая структура базы и запросов, либо изначально тормознутая связка IIS+asp.net
В обоих случаях приходим к выводу, что надо что то делать, причем желательно с нуля.
Что я и предлагал в том самом треде.
на мой взгляд все таки ASP.net тормозная...
Это исходя из того, что я уже написал, + из опыта использования forum.local и films.hackers.
Как даркгрей писал в треде из которого родился этот, проблемы на филмах начинаются когда много юзеров грузят сервак. Но на форуме тоже немало юзеров сидит единовременно. так что примем, что нагрузка распределяется на эти два сервиса одинаково.
ДаркГрей писал, что тормоза возникают из-за запроса, определяющего непросмотренный фильмы и из-за запросов по фильтрам.
Объем базы я так прикидываю на форуме должен быть больше. и задача определения просмотренных тем тоже присутствует. Но решается она без каких-либо заметных задержек, даже когда на форуме сидит толпа юзеров.
Хотя бы из этого сравнения двух аналогичных задач можно прийти к выводу, что сервис фильмов гораздо тормознутее. Отсюда два варианта: либо галимая структура базы и запросов, либо изначально тормознутая связка IIS+asp.net
В обоих случаях приходим к выводу, что надо что то делать, причем желательно с нуля.
Что я и предлагал в том самом треде.
Дык Даркгрей сказал же, что дело в базе. Думаю полно достаточно проворных движков форума на asp.net.
ну так а о чем тогда эта тема?
я просто привел аргументы здесь к моему высказыванию насчет тормознутости асп.
Но я не отрицаю того, что мое мнение может быть и неправильным, т.к. осонвывается на весьма непродолжительном знакомстве с субжем и отдельных наблюдениях.
я просто привел аргументы здесь к моему высказыванию насчет тормознутости асп.
Но я не отрицаю того, что мое мнение может быть и неправильным, т.к. осонвывается на весьма непродолжительном знакомстве с субжем и отдельных наблюдениях.
Оставить комментарий
bastii
Тут недавно сказал, что Кто нибудь может объяснить за счет чего asp.net медленнее?