[trolls and penartur inside]
---
...Я работаю...
ну ээ мм майкрософт.ком? =)
http://asus.com/ ппц долгий.
---
"Всякая революция лишь тогда чего-нибудь стоит,
если она умеет защищаться..."
А на счет asp.net складывается именно такое мнение.
Да хоть о синих и зелёных, мозг включи, да?
---
<<Давай, рассказывай, как и что работает. Предупреждаю,
не сможешь объяснить --- будешь прибит к позорному столбу "соткой".>>
Doppelganger
вот только одному мне кажется что сайты на asp.net тормознутые?Да, тебе одному.
Тормознутые - сайты, разработанные долбоёбами, а какое они средство при этом использовали - не так уж важно. А ещё, тормознутые - сайты с завышенным соотношением посетители/мощность сервера (т.е. херово спланированные а какие при разработке были использованы средства - опять же, не так важно.
Например, санрайз (когда у них там сеть не падала, или что это было) вполне шустро работал, а прайс у них именно на asp.net был, судя по всему.
ЗЫ: Лично у меня сильное ощущение, что грамотно написанный ASP.NET сайт под IIS будет уступать по производительности только написанному вручную сишному приложению с интегрированным http-сервером.
Да, это маркетинговый промах Microsoft: они создают слишком удобные инструменты, поэтому появляется слишком много быдлокодеров, что в некотором роде дискредитирует средства в глазах конечных пользователей.
Лично у меня сильное ощущениеЭто только на уровне ощущений или подтверждено практикой?
Акстись, если кажется, пока не поздно.
У меня не было практики с ASP.NET, это на уровне теории.
Например, санрайз (когда у них там сеть не падала, или что это было) вполне шустро работал, а прайс у них именно на asp.net был, судя по всему.картинки очень медленно загружались.
Да, забыл написать чтобы ты не входил, у тебя и виста на 512Мб ноуте не тормозила.
картинки очень медленно загружались.Ну да, конечно, как же я мог забыть, картинки у них генерились по запросу, в базе лежали raw-данные о пикселях, а специальный скрипт на ASP.NET делал из этого jpeg-картинку и тормозил.
На сайте асуса тормозит даже при выдаче текстовой информации, что на иных сайтах, написанных на php и иже подобных не ощущается совершенно.
Написанное на иных скриптовых языках почему-то не тормозитТолсто.
Написанное на иных скриптовых языках почему-то не тормозит, но asp конечно хорош, но вот подтормаживает немногоА что-нибудь более конкретное, чем "я зашёл на такой-то сайт, и он открывался медленно; а потом зашёл на такой-то сайт, и он открылся быстро" будет?
Может быть, те тормозящие сайты тормозят не потому, что ASP, а потому, что находятся в америке? Там напряжение в розетке 110 вольт, в два раза меньше, чем в нормальных странах - вот и сайты в два раза медленнее открываются.
На сайте асуса тормозит даже при выдаче текстовой информации.Ещё раз. Причин этому может быть миллион - начиная от криворуких разработчиков, и заканчивая тем, что у них один сервер на первом пне обслуживает миллион хитов в секунду.
В одном городе происходит десять автомобильных аварий в сутки, а в другом - сто. В первом городе губернатор по воскресеньям ест на обед говядину, а в другом - свинину. Вывод - из-за свинины количество автомобильных аварий увеличивается в десять раз, запретить свинину!
Для других языков это скорее исключение, но вот по отношению к asp - правило.
Там напряжение в розетке 110 вольт, в два раза меньше, чем в нормальных странахХорошо, определи понятие "нормальной страны", а то лезешь куда-то, а суть разговора неясна и неоднозначна получается.
А на напряжение можешь больше не ссылаться, придумай доводы по умнее, так как напряжение питания проца и иного оборудования, работающего в системе далеко не 220 и даже не 110, проходит преобразование в блоке питания и при этом еще и стабилизируется, прежде чем поступить в шину питания мат платы, оно определяется общемировыми стандартами, и соответственно напряжение питания проца в Африке ни сколько не отличается от того же Uип в России или Америке.
Веди конструктивную беседу.
Довод не принят!
так как напряжение питания проца и иного оборудования, работающего в системе далеко не 220 и даже не 110, и приходит преобразование в блоке питания и при этом еще и стабилизируется,Работающее на серверах, подключенных к иным розеткам, почему-то не тормозит, но 110V конечно хороши, но вот подтормаживает немного, но это ничего, главное что считает его лучшим.
Заговариваешься
Я просто сказал, что, исходя из того, что я знаю о ASP.NET, у меня сильное ощущение, что он самый быстрый из подобных решений. И вообще, это был оффтоп; если бы я не написал ту фразу - что бы ты делал?
Полгода назад переделывал такую поделку с сей (CGIC) на "иной
скриптовый язык," так как сёвая программа _оооочень_медленно_
отдавала страницы. Текстовые, никакой графики.
> На сайте асуса тормозит даже при выдаче текстовой информации,
> что на иных сайтах, написанных на php и иже подобных не
> ощущается совершенно.
Найди пример, мы про него на /. напишем. Посмотрим, что будет
быстрее работать.
---
"Студенту надо всё повторять три раза, Ганс, три раза.
Запомни, Ганс: три раза."
А что остается делать - только жить дальше
Да капитан, есть капитан!
исходя из того, что я знаю о ASP.NET, у меня сильное ощущение, что он самый быстрый из подобных решений.покажи пример.
Пример того, что я знаю?
или знания теоретические?
модель архитектуры платформы асп.нет изначально заточена по десктопноподобные сайты, ну там выбрал значение в комбобоксе - и можешь повесит на это обработчик. (КО моуд: достигается это использование VS и перезагрузками страницы) Кроме того, такой подход позволяет на одну страницу напихать кучу контролов с общим инициализирующим кодом (читай: огромный sql запрос будет вызываться на каждый чих). Ну вот. Собственно программеры на асп.нет (особенно китайскио/корейские, которые прогают асус.ком) активно этими удобствами пользуются. А почему бы и нет? У них локально все работает со скоростью света.
Если у программера асп.нет нет хорошего бэкграунда/понимая внутренней кухни, он практически неизбежно наступит на какие-н грабли которые отольются конечному пользователю перезагрузками страницы/длинным временем инициализации и т.п.
Т.е. мое имхо: такие "десктопные" приложения имеет смысл писать только для интранета. Для интернета лучше делать или старые добрые "одна страница-одна функция" приложения или оптимизированные аякснутые на чем-н типа ГВТ.
ЗЫ почему такого не происходит с пхп: на пхп нет такого мощного стека, поддерживающего десктопную модель (если не использовать PRADO поэтому там прогеры вынуждены использовать подход "одна страница - одна функция", который в случае интернета оказывается достаточно успешным.
хм, интересно, спасибо.
> десктопноподобные сайты
Мысль интересная, mplayer по X11/ssh проигрывает фильмы вполне
ничего, даже при небольшой нагрузке на обоих концах соединения.
Но --- только если это FastEthernet, поверх 802.11g оно уже не тянет.
---
A44: Ламеры в гамаке пусть в тапках трахаются --- это их проблемы.
Я в своём гамаке хочу полноценно трахаться на лыжах.
Сравнивать ASP.NET с PHP вообще как-то глупо; у PHP никто исходно о быстродействии не думал (лишь бы работало а всякие "ускорители" и разделяемая память появились уже как отдельные костыли.
Но это так, к слову, с чего ты взял, что на php сложнее и дольше писать, опыт и примеры в студию.
Или ты думаешь, что подключение к серверу исполняемого файла PHP в виде CGI-приложения - это уже ниибаццо быстро?
как правило, пряморукий разработчик может написать адекватное приложение абсолютно на любой платформе с примерно равными затратами усилий (ну мб за исключением перла ) =)
А вообще, речь в этом треде, напомню, идёт не о "написать адекватное приложение", а о "заставить адекватное приложение работать очень быстро под очень большой нагрузкой и обслуживать больше девяти тысяч пользователей в секунду".
О да, напиши мне вот то простенькое веб-приложеньице на ассемблере (без каких-либо библиотек, естественно - ты же о "платформах" говоришь) с такими же затратами усилий!не придирайся к словам - не конструктивно
А вообще, речь в этом треде, напомню, идёт не о "написать адекватное приложение", а о "заставить адекватное приложение работать очень быстро под очень большой нагрузкой и обслуживать больше девяти тысяч пользователей в секунду".пусть меня поправит топикстартер, но ни про большие нагрузки, ни про большое кол-во пользователей в начальном посте ничего нет
речь идет о тенденции асп приложений казаться не responsive
алгоритмическая часть - хоть функциональный стиль, хоть даже объектный пишется относительно легко. вывод на stdout и обращение к переменным окружения - тоже ничего сложного.
не придирайся к словам - не конструктивноЯ не придираюсь к словам.
Ты сказал "на любой платформе одинаково"; а сейчас выясняется, что некоторые платформы равнее других, и на PHP против ASP.NET более одинаково, чем на PHP против ассемблера. Ну так и напиши тогшда _нормальное_ утверждение, а потом уже его обосновывай.
пусть меня поправит топикстартер, но ни про большие нагрузки, ни про большое кол-во пользователей в начальном посте ничего нетАга, а на asus.com (да, знаю, это уже не первый пост поди, заглядывает всего-то пара человек в сутки.
(КО моуд: достигается это использование VS и перезагрузками страницы)что такое VS тут?
> на асме будет геморой только с обращениями к базе.Ну я знаю, что это одно из твоих любимых утверждений, однако, с чем ты тут не согласен?
Наглая ложь.
Ты думаешь что геморой будет _не только_ с обращениями к базе?
Или ты думаешь, что с обращениями тоже гемороя не будет?
Или ты от балды написал это?
на асме будет геморой только с обращениями к базе.И с тем, чтобы преобразовать строку в lowercase.
И с тем, чтобы md5 посчитать.
И с тем, чтобы обработать строку HTTP-запроса, и понять, что она вообще означает.
Напомню, я писал о "голом" ассемблере; никаких библиотек у тебя нет. Пустая платформа, без всего.
хоть функциональный стиль, хоть даже объектный пишется относительно легкоДа ради бога, только реализуй сначала там нужные функции. К тому времени, как ты выполнишь это хотя бы на 10%, у студента, сидящего рядом, уже будет работающий средних тормозов сайт на *подставь сюда имя любой быдлоплатформы*. А к тому времени, как ты выполнишь это на 50%, мощность серверов вырастет настолько, что сайт того студента станет не средней тормознутости, а просто реактивным.
view state
имя поля _VS кажется =)
Неужели к 2009 году туда ещё не прикрутили AJAX?
ничем не отличаются от того же на сях, libpq одна и та же.
---
"Narrowness of experience leads to narrowness of imagination."
И с тем, чтобы обработать строку HTTP-запроса, и понять, что она вообще означает.мы ж не веб-сервер пишем?
я говорю о cgi на асме.
или так уже не честно?
ну в данном случае я имел ввиду что лично для меня обращение к MySQL из асма - вообще непонятно как делать, без того чтобы что-то гуглить и я не могу навскидку оценить сколько кода надо будет написать для хотя бы реализации вызова mysql_query.
я говорю о cgi на асме.Нечестно, потому что речь шла о платформах.
или так уже не честно?
Но даже cgi тебе не поможет сделать strtolower и кучу других полезных вещей. Пока студент рядом клепает говнокод, ты будешь реализовывать весь тот базовый функционал, на реализацию и вылизывание которого в том же PHP была потрачена не одна сотня человеколет.
У тебя больше нет аргументов и за их отсутствием ты решил изменить условия по своему усмотрению.
Не уходи от тематики.
к сожалению (или к счастью) я уже несколько лет не прогаю на асп.нет, поэтому не знаю, как именно они заимплементили аякс
пусть меня поправит топикстартер, но ни про большие нагрузки, ни про большое кол-во пользователей в начальном посте ничего нетугу, именно это
речь идет о тенденции асп приложений казаться не responsive
пример быстрого сайта на asp.nethttp://rsdn.ru
пример быстрого сайта на asp.netесли стандартный ответ про большие сайты на asp.net, то это
myspace.com, dell.com, match.com, monster.com, costco.com, newegg.com, lego.com, stackoverflow.com
кстати orkut.com (который вроде как google-овский) тоже на asp.net
Сейчас тебе скажут, что по ощущениям они помедленнее сайтов на PHP (например, вконтакте).
Сейчас тебе скажут, что по ощущениям они помедленнее сайтов на PHP (например, вконтакте).имхо, скорость сайта от языка обычно слабо зависит.
узкое место у сайтов - это запросы к базе, особенно когда на одной странице сводится куча инфы из разных мест базы - соответственно вся дальнейшая оптимизация сводится к организации кэшей - которые сводят информацию в такой вид, чтобы страницы уже ее забирали из "одного" места
в самом жестком варианте кэширования - страница целиком строится заранее, и при запросе отдается как единое целое.
ps
если брать "любительские" asp.net-овские сайты, то их "ответчивость" подкашивает viewstate (как уже ранее заметил sardukar а также то, что в 6-ом iis-е зипование страниц по умолчанию не включено, и включается достаточно нетривиально.
узкое место у сайтов - это запросы к базе, особенно когда на одной странице сводится куча инфы из разных мест базы - соответственно вся дальнейшая оптимизация сводится к организации кэшей - которые сводят информацию в такой вид, чтобы страницы уже ее забирали из "одного" местатормоза браузера на рендеринге и js ещё часто заметны
к вопросу об аяксе
тормоза браузера на рендеринге и js ещё часто заметныпример сайта дай пожалуйста, чтобы это было заметно.
к вопросу об аяксе
а вообще от браузера это зависит, у них разные проблемы
на этом форуме был режим дерева такой, пока не зарезали еготак это уже сверхбольшие html-и, которые по хорошему целиком в браузер тащить не надо, а надо делать как например карты - через виртуальный режим
но наблюдал нередко, мозилла - отстой, потормозить любит
может тупо памяти не хватает?
пример сайта дай пожалуйста, чтобы это было заметно.Paypal где-то с месяц (или два) назад начал адски тормозить в ИЕ7; весь браузер довольно надолго подвисал на каждой странице (уж хз почему). В ИЕ8, ФФ, хроме - всё нормально.
имхо, скорость сайта от языка обычно слабо зависит.Ты забыл, что от платформы зависят накладные расходы на запуск скрипта (сколько времени пройдёт от получения http-запроса до первого запроса к базе). Насколько я понимаю, в ASP.NET это время мизерно; а вот в PHP уже надо хачить со способом подключения среды PHP к веб-серверу, с кэшированием байт-кода (что делается отдельными костылями) итд.
узкое место у сайтов - это запросы к базе
если брать "любительские" asp.net-овские сайты, то их "ответчивость" подкашивает viewstateТак неужели в последнем asp.net это всё ещё через перезагрузку страницы делается, а не через ajax? Странно как-то.
Ты забыл, что от платформы зависят накладные расходы на запуск скрипта (сколько времени пройдёт от получения http-запроса до первого запроса к базе). Насколько я понимаю, в ASP.NET это время мизерно; а вот в PHP уже надо хачить со способом подключения среды PHP к веб-серверу, с кэшированием байт-кода (что делается отдельными костылями) итд.но это же все в памяти делается - значит очень быстро, а база она на диск лезет - и это уже очень медленно получается.
а, ещё раздражают сайты, на которых скрипты не начинают работать, пока банеры не догрузятся
но это же все в памяти делается - значит очень быстроНе факт, что в памяти. Попробуй PHP подключить как CGI и посмотри на скорость работы - там при каждом запросе будет запускаться с увинчестера .exe-файл, парсить .ini-файл, подгружать оттуда же всякие .dll-библиотеки, читать .php-файл... потом парсить его, мб ещё как-то обрабатывать - это действительно уже в памяти, но не факт, что быстро.
Ну и ещё грамотно надо с тредами продумать.
ЗЫ: А ещё у PHP ну очень медленно работает код, интенсивно использующий ООП. Такой код может оказаться на порядок быстрее, написанный на любом языке со статической типизацией; это уже следствие того, что ООП в PHP - тоже такая "дополнительная" фича.
Так неужели в последнем asp.net это всё ещё через перезагрузку страницы делается, а не через ajax? Странно как-то.на последнем asp.net (т.е. на 3.0-3.5) массово сайты пойдут через год-два, пока везде asp.net 2, который вышел еще 4 года назад
там при каждом запросе будет запускаться с увинчестера .exe-файл, парсить .ini-файл, подгружать оттуда же всякие .dll-библиотеки, читать .php-файл...но это же максимум несколько десятков МБ, причем не меняющиеся, поэтому оно успешно влезет в ОС-овый кэш диска, а вот база лезть в кэш часто не хочет, потому что, во-первых, она здоровая, во-вторых, еще и меняться любит.
но это же максимум несколько десятков МБ, причем не меняющиеся, поэтому оно успешно влезет в ОС-овый кэш диска,А не выпадет ли оно потом оттуда?
В любом случае, запуск приложения - это, кажется, не только его чтение с винчестера? Когда даже сотые доли секунды имеют значение - всё это становится совершенно неприемлемым; а ничего приемлемого PHP предложить не может.
ЗЫ: Насчёт ООП могу сказать, что у нас запросы к базе - это очень небольшая доля от времени выполнения самого скрипта (это без учёта времени инициализации).
Paypal где-то с месяц (или два) назад начал адски тормозить в ИЕ7; весь браузер довольно надолго подвисал на каждой странице (уж хз почему).потому что при некоторых значениях doctype скорость исполнения javascript в ie7 падает в десятки раз. вот уж действительно хз почему
пример сайта дай пожалуйста, чтобы это было заметно.http://brainstorm.ubuntu.com
на геках правый сайдбар появляется только через заметный промежуток времени, на оперке и вебкитах всё ок
myspace.com, dell.com, match.com, monster.com, costco.com, newegg.com, lego.com, stackoverflow.com
специально посмотрел. Не один из них не является реально быстрым, т.е. responsive в терминологии юзера . У всех какие-то проблемы - то сайдбар отрисуется медленно, то ещё что-то сделается не сразу, а по просшествии некоторого количества времени после загрузки страницы.
вот только одному мне кажется что сайты на asp.net тормознутые?всем, кроме пенартура)
Нечестно, потому что речь шла о платформах.а с каких пор ассемблер стал платформой? Я вот всегда считал, что это просто самый низкоуровневый язык, он может быть свой для каждой из платформ, но практически всегда есть возможность использовать более высокоуровневое средство.
Пенартур как обычно продолжает нести ересь, не учитывая других мнений.
потому что при некоторых значениях doctype скорость исполнения javascript в ie7 падает в десятки разТы не понял - не тормозить, а _адски_ тормозить. Где-то на минуту (если не больше) ИЕ (ну или Sleipnir, если в системе ИЕ7) полностью зависает; при любой попытке что-то сделать (даже переключиться на соседнюю табу) винда закрашивает всё окно серым и говорит "приложение не отвечает, давайте я его убью".
а с каких пор ассемблер стал платформой?
но практически всегда есть возможность использовать более высокоуровневое средство.А в моей придуманной платформе такой возможности нет, ебись как хочешь.
PHP рассматривают не сам по себе, а с его стандартными библиотеками; ASP.NET - не сам по себе, а со стандартными библиотеками .NET (которые гораздо обширнее PHP-шных); тут было сказано, что от платформы (с учётом этих библиотек) ничего не зависит, т.е. нет разницы между BCL и стандартными PHP-шными библиотеками - вот я и привёл пример с полным отсутствием библиотек.
Ты не понял - не тормозить, а _адски_ тормозить. Где-то на минуту (если не больше) ИЕ (ну или Sleipnir, если в системе ИЕ7) полностью зависает; при любой попытке что-то сделать (даже переключиться на соседнюю табу) винда закрашивает всё окно серым и говорит "приложение не отвечает, давайте я его убью".да всё я понял, сам кодил и имел те же проблемы. Чтобы превратить тормоза в адские тормоза достаточно 100 раз использовать тормоза.
на
специально посмотрел. Не один из них не является реально быстрым, т.е. responsive в терминологии юзера . У всех какие-то проблемы - то сайдбар отрисуется медленно, то ещё что-то сделается не сразу, а по просшествии некоторого количества времени после загрузки страницы.а какие есть быстрые?
на последнем asp.net (т.е. на 3.0-3.5) массово сайты пойдут через год-два, пока везде asp.net 2, который вышел еще 4 года назад
Разве какие-то существенные изменения по аяксу там есть по сравнению с 2.0 (кроме того библиотеки аякса встроены в асп 3.5).
Делают с перезагрузкой потому что проще, тем более что дизайнер студии половину кода сам сгенерит такого.
Разве какие-то существенные изменения по аяксу там есть по сравнению с 2.0 (кроме того библиотеки аякса встроены в асп 3.5).если считать, что в 2.0 ajax-а не было, то существенное изменение лишь одно - появился ajax.
ps
то, что он был внешней либой я знаю, но его не было в mainstream-а - а это главное.
Делают с перезагрузкой потому что проще, тем более что дизайнер студии половину кода сам сгенерит такого.В этом и вопрос - почему генерится код с перезагрузками, а не с аяксом? Как-то с трудом верится в такое, если учесть, что на дворе 2009 год.
а какие есть быстрые?www.php.net летает.
В этом и вопрос - почему генерится код с перезагрузками, а не с аяксом? Как-то с трудом верится в такое, если учесть, что на дворе 2009 год.
Для разработки так намного проще.
www.php.net летает.он без базы, чисто статический
Для разработки так намного проще.Насколько я себе представляю возможности по написанию быдлосайта на ASP.NET, для разработки нет никакой разницы; разработчику (напомню, это я о быдлосайтах, а не о быстрых и качественно сделанных) вообще не должно быть никакой разницы, где выполняется код - на сервере или на клиенте.
> качественно сделанных) вообще не должно быть никакой разницы
Мне лень объяснять, почему это не так.
---
"И, зная топографию,
он топает по гравию."
Объясни. Только конкретнее, без обращений к тому, что абстракции всегда протекают.
Насколько я себе представляю возможности по написанию быдлосайта на ASP.NET, для разработки нет никакой разницы; разработчику (напомню, это я о быдлосайтах, а не о быстрых и качественно сделанных) вообще не должно быть никакой разницы, где выполняется код - на сервере или на клиенте.Разница как между тонким клиентом и толстым.
если брать "любительские" asp.net-овские сайты, то их "ответчивость" подкашивает viewstate (как уже ранее заметил sardukar а также то, что в 6-ом iis-е зипование страниц по умолчанию не включено, и включается достаточно нетривиально.viewstate это когда сессия сериализуется и отправляется на клиент? Но без этого же не обойтись независимо от того на какой технологии сайт сделан.
а какие есть быстрые?этот форум обычно такой. gmail после загрузки, nhl.com (java djangoproject.com
классически медленный - для меня это asus.com и rsdn.ru
этот форум обычно такойа это не из-за того, что он локальный для тебя?
этот форум обычно такойна админке он кстати сильно тормозит
для меня он нелокальный, и обычно очень быстрый
для меня он нелокальный, и обычно очень быстрыйсейчас специально проверил.
первый заход из чистого браузера в этот тред - 12с
открытые этого треда (последующие) - 1с
открытие раздела hard&soft - 260 мс
дело ведь не в миллисекундах, а в том, что в среднем при клике по ссылке форум имеет тенденцию быстро открывать страницу, это субъективное ощущение. мне кажется тут дело даже не столько в технологии-движке-посещаемости-[вставьте нужное], а в отсутствии флеш банеров, которые задалбывают на большинстве других страниц.
у меня флэш поэтому не стоит в основном браузере - и все быстро открывается.
а это не из-за того, что он локальный для тебя?год как уже нет
viewstate это когда сессия сериализуется и отправляется на клиент? Но без этого же не обойтись независимо от того на какой технологии сайт сделан.отправляется не сессия, отправляется текущее состояние страницы.
а обычно у страницы никакого состояния и нету, а asp.net - его все равно пихает.
Давай следующее переименование треда: [trolls and penarturs inside]
Оставить комментарий
sergeikozyr
вот только одному мне кажется что сайты на asp.net тормознутые?всякие пыхпыхи джавы или джанги бывают всякие, но почему-то на asp.net все субъективно как-то тормозят. Ну ещё рубейные сайты тоже тормозные.