У нас они тоже льются на отдельный сервак из WebForms, WCF, WinForms, WinCE приложений.
Но проблема с паникой. Т.к. разработчикам СМС приходят, когда приложение полностью отвалилось. Но появилась, скажем, плавающая ошибка. Т.е. приложение начинает проявлять в логах подозрительную активность. И на глаз, на графике, это увидеть можно, но вот настроить так монитор, чтобы он отслеживал не только повышение активности приложения, но и учитывал повышения активности клиентов оказалось не так-то и просто…
Не совсем понимаю, зачем вам сжимать HTML в Asp.Net?
Люблю копаться в HTML коде понравившихся сайтов.
Особенно интересно было копаться в коде сайтов сони, пока их не поломали. Теперь комментариев в коде стало значительно меньше. :(
А тут, как-то залез в код титульной страницы гугля и прям там мне их компактный код понравился, что пришла в голову мысль поизучать эту проблему поподробнее.
Пример должен показывать реальную проблему. Тогда уж лучше ничего не приводить.
Это был тонкий троллинг того, что в 4.5 типизированный репитер наконец то появился в коробке от M$'а.
Даже год, автора и источник появления этого репитера указал. :)
Ещё в начале 2010 года Я в M$ про него писал, при миграции на .NET 4.
Простите, что сразу про это не написал…
Компиляцию — да. Выполнение — нет.
Т.е. проблема была не в том, что разработчик использовал вложенность репитеров?
Это уже радует. Т.к. Я предпочитаю весь код иметь в одном месте, а не разбросанным по проекту.
А вот мой верстальщик почему-то громко ругается на большие шаблоны и дублирование верстки.
Я полностью согласен с Вашим верстальщиком. Дублирование вёрстки недопустимо.
А вот с большими шаблонами — не знаю. Лимит на размер методов, как известно, давно опубликовали специалисты из patterns & practice.
А вот по поводу больших шаблонов рекомендаций Я не встречал. У Вас есть какие-то ограничения?
Я и не уговариваю. Если кому-то будет полезно, то Я рад.
Ну а лимиты времени выполнения, или лимиты на размер результатирующего кода — это дело лично (или не лично) каждого.
А у Вас есть лимиты на время выполнения и на размер результатирующего кода?
Нет. А что, надо быть обязательно MSNом чтобы писать компактный код?
А во-вторых — откуда вы знаете, как у них происходит сжатие?
Не знаю. Вы можете подождать пару итераций, может, как и с типизированным репитером, сотрудники M$ включат что-то подобное в очередную версию студии. ;)
У нас админы за кодом не следят. Максимум на что можно уговорить, так на переключение IISов.
Есть несколько систем мониторинга, которые пытаются связаться с разработчиками, при фатальных проблемах. В разработке система мониторинга потока ошибок со всех приложений, которая при достижении определённого лимита определённых исключений в отрезок времени поднимала панику. CEP работает, а вот настройка пока не удаётся…
Это инструмент развертывания приложения.
Спасибо за позитивную критику. :)
У Нас ещё паралельно логируются все деплои: кто, куда, когда.
И отправляются сообщения всем сотрудникам, создавшим таски и ожидающие их завершения.
Посмотрите, для примера, код страниц гугля, яндекса, бинга.
Весь первичный контент сжат. И наверняка сжатие происходит не в рантайме.
Им тоже стоит уничтожить лишние сущности?
MS явно заявляет, что позиционирует WebDeploy как the инструмент для развертывания решений на базе asp.net. У меня нет причин им не верить.
У M$ — основная задача продавать свои продукты, а не решать проблемы разработчиков.
Перегнать возможности вебдеплоя Я не стремлюсь, предоставленное мной решение необходимо совершенно для других целей.
Если Вы покажете мне инструмент, который на этапе выкладки сжимает код на aspx страницах и пользовательских элементах управлениях, то моим решением пользоваться бессмысленно.
Но существующие инструменты, позволяют сжимать только вторичный код.
Если код на страницах достаточно динамичный, то в результате, даже с сжатием на уровне протокола, может получиться достаточно хороший процент паразитного трафика.
Если вспомнить историю, то фейлы с 2-3 Mb вьюстейтами, на сегодняшний день, заменили фейлы с 2-3 Mb jQuery + плагины. И в большинстве своём, разработчикам всё равно, насколько распухает код в финальной отдаче конечному клиенту страницы…
У Вас, к примеру, какой лимит на, скажем, титульную страницу со всем вторичым трафиком на фронтенде?
Не? На somee хостинге мне никто не позволит ставить вебдеплой.
А решение нужно универсальное.
Да и статик-сервера никто не отменял, о которых Я писал выше.
Ну и ещё одна проблема, которая уже несколько раз спасала мой ночной сон:
Если в 2-4 часа ночи вылезла ошибка, когда кеш-сервера обновились, то у админов есть шанс переключиться на предыдущую версию.
А уже потом, звонить и спрашивать «что делать»…
Такой код половину статьи займёт… Я-ж его в качестве примера привёл, а не как основное на что стоит заострять внимание…
на предмет оптимизации производительности
А Вы по трассировке смотрели результатирующую производительность?
Готов поспорить, что вынос контроллов в отдельные файлы, в качественно написанном коде, только замедлит выполнение.
3. Вместо размножения рипитеров выбирал бы нужный контрол во время привязки данных.
Если код вторично используемый, то есть смысл его выводить во вторичные элементы управления, а если код используется только в одном месте, то выносить его со страницы просто усложнит дальнейшую поддержку верстальщикам и программистам.
АппДомены для CDN (они на IIS'е, т.к. там часть кода БЛ поднимается).
Вебдеплой плохо работает, когда необходимо размазать одно решение по нескольким доменам приложений. Там уже костылить приходится…
У нас они тоже льются на отдельный сервак из WebForms, WCF, WinForms, WinCE приложений.
Но проблема с паникой. Т.к. разработчикам СМС приходят, когда приложение полностью отвалилось. Но появилась, скажем, плавающая ошибка. Т.е. приложение начинает проявлять в логах подозрительную активность. И на глаз, на графике, это увидеть можно, но вот настроить так монитор, чтобы он отслеживал не только повышение активности приложения, но и учитывал повышения активности клиентов оказалось не так-то и просто…
Люблю копаться в HTML коде понравившихся сайтов.
Особенно интересно было копаться в коде сайтов сони, пока их не поломали. Теперь комментариев в коде стало значительно меньше. :(
А тут, как-то залез в код титульной страницы гугля и прям там мне их компактный код понравился, что пришла в голову мысль поизучать эту проблему поподробнее.
Это был тонкий троллинг того, что в 4.5 типизированный репитер наконец то появился в коробке от M$'а.
Даже год, автора и источник появления этого репитера указал. :)
Ещё в начале 2010 года Я в M$ про него писал, при миграции на .NET 4.
Простите, что сразу про это не написал…
Т.е. проблема была не в том, что разработчик использовал вложенность репитеров?
Это уже радует. Т.к. Я предпочитаю весь код иметь в одном месте, а не разбросанным по проекту.
Я полностью согласен с Вашим верстальщиком. Дублирование вёрстки недопустимо.
А вот с большими шаблонами — не знаю. Лимит на размер методов, как известно, давно опубликовали специалисты из patterns & practice.
А вот по поводу больших шаблонов рекомендаций Я не встречал. У Вас есть какие-то ограничения?
В нашем случае, рантайм отдаётся под клиента, его так просто не закешировать…
А по регионам обслуживаемой области, полную скорость загрузки содержимого Вы считали?
Ну а лимиты времени выполнения, или лимиты на размер результатирующего кода — это дело лично (или не лично) каждого.
А у Вас есть лимиты на время выполнения и на размер результатирующего кода?
Нет. А что, надо быть обязательно MSNом чтобы писать компактный код?
Не знаю. Вы можете подождать пару итераций, может, как и с типизированным репитером, сотрудники M$ включат что-то подобное в очередную версию студии. ;)
У нас админы за кодом не следят. Максимум на что можно уговорить, так на переключение IISов.
Есть несколько систем мониторинга, которые пытаются связаться с разработчиками, при фатальных проблемах. В разработке система мониторинга потока ошибок со всех приложений, которая при достижении определённого лимита определённых исключений в отрезок времени поднимала панику. CEP работает, а вот настройка пока не удаётся…
Спасибо за позитивную критику. :)
У Нас ещё паралельно логируются все деплои: кто, куда, когда.
И отправляются сообщения всем сотрудникам, создавшим таски и ожидающие их завершения.
Посмотрите, для примера, код страниц гугля, яндекса, бинга.
Весь первичный контент сжат. И наверняка сжатие происходит не в рантайме.
Им тоже стоит уничтожить лишние сущности?
А какую Вы преследуете цель в Нашей дискуссии?
Фронтенда? Тогда вообще проблем нет :)
На бекенде Мы тоже всякий код тестируем и условия пользования ставим :)
Вы
Где там HTML сжатие? (Я просмотрел только IL...)
У M$ — основная задача продавать свои продукты, а не решать проблемы разработчиков.
Перегнать возможности вебдеплоя Я не стремлюсь, предоставленное мной решение необходимо совершенно для других целей.
Если Вы покажете мне инструмент, который на этапе выкладки сжимает код на aspx страницах и пользовательских элементах управлениях, то моим решением пользоваться бессмысленно.
Но существующие инструменты, позволяют сжимать только вторичный код.
Если код на страницах достаточно динамичный, то в результате, даже с сжатием на уровне протокола, может получиться достаточно хороший процент паразитного трафика.
Если вспомнить историю, то фейлы с 2-3 Mb вьюстейтами, на сегодняшний день, заменили фейлы с 2-3 Mb jQuery + плагины. И в большинстве своём, разработчикам всё равно, насколько распухает код в финальной отдаче конечному клиенту страницы…
У Вас, к примеру, какой лимит на, скажем, титульную страницу со всем вторичым трафиком на фронтенде?
У Вас этим админы занимаются? 0_o
Что не удобно-то?
Весь функионал в одном месте:
Ограничив любое звено, получаем функционирующий и масштабируемый код.
Не? На somee хостинге мне никто не позволит ставить вебдеплой.
А решение нужно универсальное.
Да и статик-сервера никто не отменял, о которых Я писал выше.
Ну и ещё одна проблема, которая уже несколько раз спасала мой ночной сон:
Если в 2-4 часа ночи вылезла ошибка, когда кеш-сервера обновились, то у админов есть шанс переключиться на предыдущую версию.
А уже потом, звонить и спрашивать «что делать»…
Такой код половину статьи займёт… Я-ж его в качестве примера привёл, а не как основное на что стоит заострять внимание…
А Вы по трассировке смотрели результатирующую производительность?
Готов поспорить, что вынос контроллов в отдельные файлы, в качественно написанном коде, только замедлит выполнение.
Если код вторично используемый, то есть смысл его выводить во вторичные элементы управления, а если код используется только в одном месте, то выносить его со страницы просто усложнит дальнейшую поддержку верстальщикам и программистам.
Ух, тыкните, пожалуйста, где-ж они первичный трафик сжимают.
А то по этой ссылке опять Я только про оптимизацию вторичного трафика расказывается…