Хитрый способ сбора качественной пробиваемой базы для XRUMER. Как система профилей хранит данные

16.04.2019

Хитрый способ сбора качественной пробиваемой базы для XRUMER

Всем привет! Ни для кого не секрет, что каким бы замечательным не был софт для массовой регистрации/рассылки, без надлежащего качества баз он почти не имеет ценности. Базы можно добыть различными способами – спарсить самому /купить /найти в паблике/etc. Каждый вариант хорош по – своему и у каждого из них есть свои плюсы и минусы.

Паблик базы. Основной плюс это бесплатность. Часто в паблик сливаются и покупные базы, так что найти стоящие все-таки можно, другое дело что по этим базам будет работать сразу большое количество вебмастеров(как с лиц, так и с ломаным хрумом) и они быстро превратятся в помойку, а как известно, 1 трастовая ссылка зачастую лучше чем 1000 с гавносайтов.
Покупка базы. В основном это лотерея. Селлеров сейчас достаточное количество, но еще больше барыг, которые покупают и перепродают базы, выдавая за свои свежеспарсенные.Данный метод получения базы хорош в том случае если вы дорожите своим временем и покупаете базу у проверенного временем человека.
Самостоятельный парсинг. Самый лучший, но в тоже время затратный вариант. Для успешного парсинга нужно обладать словарем по тематике, признаками для парсинга + свежими прокси/соксами, если вы соберетесь парсить google, к примеру. Разумеется нужен и сам парсер, для хрумоводом все проще, так как с хрумером идет Hrefer, но все же я рекомендовал еще купить что-нибудь дополнительно. Лично я использую webparser, хотя многие хвалят a-parser, в общем кто на что горазд и у кого какие потребности.

База собранная собственноручно дает небольшое временное преимущество над другими вебмастерами, но не стоит думать, что собрав скажем базу форумов по хорошим признакам вы не обнаружите на доброй половине из них спам от «собратьев по оружию», но в любом случае свежеспаршенные (сырые) базы будут лучше паблик и зачастую лучше покупных, но как говорится этот вариант для тех у кого хорошие аппаратные мощности + есть время.

Есть конечно же еще варианты – утащить с чужого сервера, пропарсить интернет по примерно такому запросу

Пример лота в телдери:
_http://www.telderi.ru/ru/viewsite/67448
Как видим: “также прогонялся по профилям, прогон по профилям и каталогам был осуществлен 30 дней назад”, значит это “наш клиент”. Копируем урл сайта к себе в текстовый файл.

Таким нехитрым способом мы собираем БАЗУ сайтов, которые когда-либо прогонялись хрумером или ручками по трастовым сайтам. Отмечу тот факт, что большинство прогонщиков работают с дефолтным хрумером без измененного файла xas_AI.txt, что опять же нам на руку.

Буквально за час, можно собрать около 200 урлов сайтов, которые были «запачканы» прямым прогоном хрумером. Далее мы идем пополнять коллекцию на SEO форумы, там мы ищем темы с прогонами и смотрим на отзывы, форумов полно, для примера :
_http://www.maultalk.com/forum38.html
Далее идем по популярным веткам прогонщиков и смотрим в темах тех, кто оставлял отзывы об услуге. В 85% случаев, если у них заполнено поле сайт в профиле и подпись, то там находится их сайт, по которому они заказывали прогон, причем зачастую не один.

Работа по сбору таких урлов немного нудная, но зато эффект будет достойным(пока поверьте на слово).
После 2-3 часов работы, которую можно сбагрить на аутсорс толковому школьнику за 100-150 рублей с , мы получаем приличный список сайтов, теперь дело за малым – вытащить обратные ссылки.
Для начала идем в _ http://ahrefs.com и (можно воспользоватся другим софтом/сервисами) и извлекаем ВСЕ обратные ссылки .

Данную нудную работу тоже лучше поручить кому-то.
Вторым этапом будет подготовка урлов для парсинга, и тут опять следует небольшая хитрость.
Нужно составить запросы для ПАРСИНГА примерно такого вида, приведу пример для сайт
«Просмотр профиля» http://сайт/
«Профиль» http://сайт/
«Профиль пользователя» http://сайт/
«Пользователь» http://сайт/
«Сайт» http://сайт/
«Домашняя страница» http://сайт/

«user» http://сайт/

«member» http://сайт/

«profile» http://сайт/

Просто ввести название домена в кавычках «http://сайт»
Просто погуляйте по форумам и посмотрите как выглядят там профили.
Сделать список таких признаков и урлов вам поможет EXCEL и оператор &
В одной колонке у вас урлы, в другой наши простенькие “признаки”:

Наглядный пример:
>>>> <<<<

Что мы получается на выходе на выходе? База профилей в 100% индексе яндекса или гугла, большинство из которых пробивает дефолтный хрумер.

С такими нехитрыми признаками мы парсим ПС (я, обычно, ограничиваюсь Яшей и Гошей)

Безусловно, таким способом соберется много дублей, но база профилей получится достаточно качественная и индексируемая. Никогда не гонитесь за количеством, лучше купить/собрать базу базу из 1000 профилей которые попадают в индекс, чем из 40000 закрытых в индексации и тд.

Основная часть (2) : В статье про я упомянул про то, что с помощью этих 3 баз можно собрать неплохую базу под хрумер и я вам не врал.
Для начала стоит скачать все 3 базы – ru, su, РФ:

Https://partner.r01.ru/ru_domains.gz

Https://partner.r01.ru/su_domains.gz

Https://partner.r01.ru/rf_domains.gz

Далее скомпоновать из них 1 большой файл с урлами. ВНИМАНИЕ! Данная операция требует больших аппаратных мощностей, если вы ими не обладаете, поделите базы на куски с помощью KeyWordKeeper (скачать можно по ссылке – _) и продолжайте.

После создания большой базы, нам в любом случае придется прибегнуть к помощи KeyWordKeeper, так как всеми нами любимый EXCEL плохо работает с файлами, где больше 1 000 000 строк, поэтому делим нашу базу на куски по 900 000. Получится достаточно много файлов.

Теперь нужно включить голову и подумать, какие конструкции наиболее часто применимы для форумов.

В базе уже содержится приличное количество форумов, но часто форумы создаются на поддоменах основного сайта и не попадают в базу.
Как в основном выглядят поддомены?
Сайт.ру/forum
Сайт.ру/talk
Forum. Сайт.ру
Talk. сайт.ру
+ другие вариации . Соответственно нам нужно добавить talk и forum к существующим URL, делает это все тем же экселевским оператором & + сочетанием клавиш CTRL + ENTER для применения формулы ко всему списку.

Теперь самое вкусное, в конце рабочего дня мы все что сделали компонуем в 1 большой файл, перемешиваем и запускаем хрумер в режиме «только регистрация».

Учитывая, что база сырая + многих ресурсов просто не существует, мы ведь только предполагаем что там есть поддомены с форумами, при 100 потоках и 6 мегабитном канале скорость будет составлять около 1200-1600 ссылок (+ многое зависит от железа), те у кого с железом и с каналом дела обстоят лучше прогонят эту базу за пару дней, у остальных же примерно это займет около недели с небольшим. Вторым этапом запускаем редактирование профиля.

В итоге вы получаете на ~65% русскоязычную базу профилей, состоящую из ~8000-9000 ресурсов (у меня вышло примерно столько), где просто проставлена ссылка вида «http://сайт/», активных и не закрытых к индексации ссылок будет в 3-4 раза меньше. Данным способом собираются не только форумные профили, но и профили на движке DLE и тд. Если подойти к делу основательно – найти много сайтов + делать прогоны в несколько раз, чтобы выжать из базы максимум – то можно выжать еще сверху 15-20% ресурсов.

Cпособ можно модернизировать и собирать с помощью него ресурсы любого типа. Статья в первую очередь предназначена для новичков, которые только учатся собирать базы и позволяет за 1 день подготовки собрать базу, которой можно пользоваться несколько месяцев.

Для тех кто не хочет с этим делом заморачиваться, может купить у меня личную базу из 13 000 профилей, собранную данным методом с добавлением ресурсов из ЯК и DMOZ + другие источники (с ценником пока не определился, но если будет спрос, то думаю, 20-25 WMZ вполне адекватная цена).

Надеюсь статья оказалась для вас полезной. Заранее извиняюсь за плохое превью скриншотов + отсутствие видео материала, со временем постараюсь поправить.

Всем хорошего дня!

20th Фев 2013

Профили

Ранее вы ознакомились с широким диапазоном средств безопасности ASP.NET. Многие из этих средств связаны с идентификацией индивидуальных пользователей (аутентификацией) и последующим определением действий, которые им разрешено выполнять (авторизацией). Однако уникально идентифицировать и аутентифицировать пользователей важно еще и по другой причине, а именно - чтобы отслеживать специфическую для конкретного пользователя информацию.

В ASP.NET 1.x единственная практическая возможность сохранять специфичную для пользователя информацию состояла в создании собственных компонентов доступа к данным. Веб-страница может вызывать методы этого компонента доступа к данным, чтобы получать данные текущего пользователя и затем сохранять любые изменения в них. Этот подход по-прежнему имеет смысл во многих сценариях. Однако в ASP.NET 2.0 появилось другое средство, называемое профилями, которое в ASP.NET 4 осталось неизменным. Когда используются профили, ASP.NET автоматически управляет извлечением специфичных для пользователя данных, обращаясь за ними к источнику данных заднего плана (обычно - к базе данных).

Концептуально средство профилей очень похоже на создание собственных компонентов базы данных. Однако в нем имеется ряд удобств. Наиболее впечатляет то, что это средство интегрировано с моделью аутентификации ASP.NET так, что информация о пользователе автоматически извлекается для текущего пользователя, когда это необходимо, и (если эта информация изменяется) записывается в базу данных в конце текущего запроса. Важнее всего то, что код веб-страницы обращается к данным профиля текущего пользователя с применением строго типизированных свойств.

Одним из наиболее существенных отличий между профилями и другими типами управления состоянием является то, что профили предназначены для постоянного хранения информации с использованием источников данных заднего плана, таких как база данных. Большинство других типов управления состоянием предназначено для поддержки информации для последовательности запросов, поступающих за относительно короткое время (вроде непостоянных cookie-наборов и состояния представления), или для передачи информации от одной страницы к другой (такой как межстраничная отправка и строки запросов). Если нужно хранить информацию более длительное время в базе данных, то профили предоставляют для этого удобную модель, которая управляет хранением и извлечением информации.

Прежде чем начать применять профили, необходимо тщательно оценить их возможности. Этому посвящается несколько последующих разделов.

Производительность профилей

Назначение средства профилей ASP.NET заключается в обеспечении прозрачного способа управления специфичной для пользователя информацией без необходимости писать специальный код доступа к данным с применением классов данных ADO.NET.

К сожалению, многие средства, которые выглядят удобными, страдают от недостаточной производительности или масштабируемости. Это, в частности, касается профилей, поскольку они предполагают доступ к данным, а обращение к базам данных может легко превратиться в узкое место любого распределенного приложения.

Итак, испытывают ли профили проблемы масштабируемости? На этот вопрос не существует простого ответа. Все зависит от того, какой объем данных нужно хранить и как часто к ним необходимо обращаться. Чтобы принять взвешенное решение, понадобится узнать немного больше о том, как работают профили.

Профили подключаются к жизненному циклу страницы двумя способами:

При первом обращении к объекту Profile в коде ASP.NET извлекает всю информацию профиля текущего пользователя из базы данных. С этого момента информацией профиля можно манипулировать в коде без какой-либо нагрузки на базу данных (до следующей обратной отправки).

Если в данные профиля вносятся изменения, обновление откладывается до окончания обработки страницы. В этот момент (после того как на странице произойдут события PreRender, PreRenderComplete и Unload) профиль записывается обратно в базу данных. Таким образом, множественные изменения собираются в одну операцию. Если профиль не изменяется, никакой дополнительной работы базы данных не требуется.

Таким образом, средство профилей может дважды обращаться к базе данных при каждом запросе (в сценарии чтения-записи) или же всего один раз (если данные профиля просто читаются). Средство профилей не интегрировано с кэшированием, поэтому каждый запрос к данным профиля требует соединения с базой данных. Чтение и сохранение профилей реализовано специальным модулем ProfileModule , который запускается при каждом запросе.

С точки зрения производительности профили лучше работают, когда удовлетворяются следующие условия:

Есть относительно немного страниц, которые обращаются к данным профиля.

Сохраняется небольшой объем данных.

Хуже они работают при таких условиях:

Есть много страниц, которые нуждаются в использовании информации профиля.

Сохраняются большие объемы данных. Особенно низкая эффективность будет, когда необходимо использовать лишь некоторые из запрошенных данных (поскольку модель профилей всегда извлекает блок данных профиля целиком).

Конечно, профили можно комбинировать с другими типами управления состоянием. Например, предположим, что веб-сайт включает мастер заказов, который проводит пользователя через несколько шагов. В начале этого процесса информацию профиля можно извлечь и сохранить в состоянии сеанса. В остальной части процесса можно использовать коллекцию Session. Предполагая, что применяется модель хранения состояния сеанса на уровне серверного процесса или вне его, этот подход более эффективен, поскольку избавляет от необходимости периодически повторно подключаться к базе данных.

Как система профилей хранит данные

Наиболее существенное ограничение, касающееся профилей, никак не связано с производительностью - речь идет об ограничении сериализации профилей. Поставщик профилей по умолчанию, входящий в состав ASP.NET, сериализует информацию профилей в блок данных, который сохраняется в одном поле записи базы данных. Например, если сериализуется информация об адресе, в результате получается нечто вроде такого:

Alex ErohinЛенинский проспект 68Москва119296Россия

Другое поле указывает, где начинается и заканчивается каждое значение, с использованием формата вроде следующего:

Name:S:0:11:Street:S:11:21:City:S:32:6:ZipCode:S:38:6:Country:S:44:6

Хотя такой подход обеспечивает достаточную гибкость, чтобы хранить данные почти любого типа, он существенно затрудняет их применение в других приложениях. Можно написать специальный код для разбора данных профиля, чтобы найти нужную информацию, но в зависимости от объема данных и их типов этот процесс может оказаться весьма утомительным. И даже если сделать это, все же останется ограничение в способах использования такой информации.

Например, предположим, что профиль применяется дня хранения адреса заказчика. Из-за специфического формата не получится генерировать списки заказчиков в таких приложениях, как Microsoft Word, или выполнять запросы, которые фильтруют или сортируют записи с использованием данных профиля. (Например, выполнить запрос для получения всех заказчиков, живущих в определенном городе, не получится.)

Эта проблема имеет два решения:

Использовать специальные компоненты доступа к данным вместо профилей, чтобы сохранять данные в базе и извлекать их оттуда.

Использовать собственный поставщик профилей, спроектированный специально для хранения информации с применением схемы базы данных.

Из этих двух вариантов разработка собственного компонента доступа к данным проще и обеспечивает большую гибкость. Свой компонент данных можно спроектировать так, чтобы он имел любой желаемый интерфейс, и затем его можно многократно использовать в других приложениях.NET. В настоящее время разработчики ASP.NET предпочитают именно этот подход, потому что он отработан со времен.NET 1.0 и хорошо понятен.

Второй вариант интересен тем, что позволяет странице продолжать пользоваться моделью профилей. Фактически можно создать приложение, использующее стандартную сериализацию профилей с помощью SqlProfileProvider, а позднее переключиться на применение специального поставщика. Для такого переключения изменять код не понадобится. Нужно просто модифицировать настройки профиля в файле web.config. По мере того как веб-сайты будут шире применять профили, привлекательность специальных поставщиков профилей возрастет.

Также важно правильно выбрать тип данных, который лучше работает с профилями. Как и со многими другими способами управления состоянием, в профиле можно сохранять любые сериализуемые типы, включая простые типы и пользовательские классы.

Профили и аутентификация

Одно существенное отличие профилей от других типов управления состоянием состоит в том, что профили сохраняются в индивидуальных записях, каждая из которых уникально идентифицирована именем пользователя. Это значит, что профили требуют применения систем аутентификации определенного рода. Не важно, какой конкретно тип аутентификации используется (аутентификация Windows, с помощью форм или специальная) - единственное требование состоит в том, что аутентифицируемому пользователю должно быть назначено уникальное имя. Это имя пользователя применяется для нахождения соответствующей записи профиля в базе данных.

Сравнение профилей и специальных компонентов данных

Профили - естественный конкурент специальных компонентов данных, вроде тех, которые строили в статье «Компонент доступа к данным» . Ясно, что компоненты данных обладают большей гибкостью. Они позволяют не только поддерживать специфичную для пользователя информацию, но также сохраняют информацию и другого рода, а также позволяют решать сложные бизнес-задачи.

Например, веб-сайт электронной коммерции может использовать профили для сопровождения информации об адресах заказчиков (с ограничениями, описанными в предыдущем разделе). Однако вы не должны применять профили для хранения информации о ранее размещенных заказах. И не только потому, что объем этой информации слишком велик, чтобы сохранять ее эффективно, но еще и потому, что ею трудно манипулировать.

Стандартный поставщик профилей, входящий в ASP.NET - SqlProfileProvider , не предоставляет многих дополнительных средств помимо сохранения в базе данных и извлечения оттуда. В следующем списке перечислены некоторые средства, которые можно легко добавить через специальный компонент базы данных, но которые не доступны SqlProfileProvider. Если требуется любое из этих средств, следует отказаться от профилей и создать собственный компонент доступа к данным или же разработать собственный поставщик профилей:

Шифрование

Данные профилей могут быть сериализованы в строку, XML-разметку либо двоичное представление. Но независимо от выбора, вы всегда в конечном итоге сохраняете низкоуровневый текст. Если есть чувствительная информация, то единственным выбором будет зашифровать ее перед сохранением, что потребует нежелательного размещения логики шифрования в интерфейсном коде.

Проверка достоверности

Вы не можете ограничить тип информации, которая помещается в профиль. Для предотвращения появления недопустимых данных необходимо использовать дополнительные инструменты (такие как элементы управления проверкой достоверности и специальные классы данных).

Кэширование

Если информация профиля используется на странице, она всегда извлекается из базы данных. Информацию из профиля нельзя хранить в памяти. Хотя можно скопировать информацию профиля в кэш, это сильно затруднит ее отслеживание.

Диагностика

При проектировании пользовательского компонента базы данных имеется возможность добавлять любой необходимый код протоколирования и отслеживания. Его можно использовать для диагностики неожиданных ошибок или мониторинга производительности веб-приложения. Однако чтобы применять эти средства с профилями, придется построить собственный поставщик профилей, который включает необходимый код протоколирования.

Теперь, когда известны все подробности профилей, можно приступать к их использованию.

В прошлом году мне пришлось отсобеседовать около 10-15 кандидатов на должность веб-программиста на ASP.NET средней квалификации. В качестве вопросов «на засыпку», или «со звёздочкой», я просил рассказать, что происходит с HTTP-запросом от момента его поступления на 80-й порт сервера до передачи управления коду aspx-страницы. Статистика была удручающей: ни один из кандидатов не смог выдать хоть что-нибудь внятное. И этому есть своё объяснение: ни в MSDN с technet, ни на специализированном ресурсе iis.net, ни в книгах a-la «ASP.NET для профессионалов», ни в блогах данной теме не уделяется должного внимания – информацию приходится собирать чуть ли не по крупицам. Я даже знаю людей, которые решили написать свой собственный веб-сервер (Игорь, Георгий, привет!), чтобы не разбираться в работе IIS. Единственная толковая статья – «Introduction to IIS Architectures » Риган Темплин (Reagan Templin). Но и она остаётся на периферии интересов аспнетчиков.

Хотя мне лично уже не так интересны чисто технические вопросы, я решил собрать в кучу свой накопленный опыт, раскопать на просторах Сети любопытные детали и передать сие сакральное знание массам, пока оно ещё не устарело. Сразу оговорюсь, что статья ориентирована в большей степени на IIS 7.x, иногда будут ответвления про 6-ку. С 8-й версией в работе не сталкивался, поэтому решил обойти её в этой статье стороной. Но, уверен, читатель без труда разберётся с восьмёркой, освоив изложенный ниже материал.

1. Общий план

Итак, начнём с конца, а потом рассмотрим отдельные аспекты чуть более пристально.
В англоязычной литературе процесс обработки запроса в IIS называется «request processing pipeline» - что-то вроде «конвейера обработки запроса». В общих чертах он представлен на рисунке ниже для http-запроса.

Рис. 1. HTTP request processing pipeline (IIS 7.x).

Таким образом, http-запрос проходит по «сборочной ленте конвейера» через следующее:

1. Браузер обращается к веб-серверу по определённому URL, на стороне сервера запрос перехватывает драйвер HTTP.SYS .
2. HTTP.SYS стучится к WAS для получения информации из хранилища конфигурации.
3. Служба WAS запрашивает конфигурацию из хранилища - из файла в папке IIS (applicationHost.config).
4. Поскольку данный запрос получен по протоколу HTTP конфигурационную информацию получает служба W3SVC (она же WWW Service на картинке), эта информация содержит в себе данные о пуле приложений (application pool) и прочих параметрах сайта.
5. Служба W3SVC использует эту информацию для кофигурации HTTP.SYS .
6. Служба WAS запускает процесс W3WP.exe для пула приложений, если он ещё не был запущен.
7. В процессе W3WP.exe работает приложение веб-сайта, которое, собственно, формирует и возвращает ответ драйверу HTTP.SYS .
8. HTTP.SYS отправляет ответ браузеру.

В принципе уже этой схемы достаточно для прохождения интервью в большинстве компаний и получения общего представления об архитектуре IIS. Но если вы не для галочки сюда зашли, то прошу следовать далее.

2. Крупный план

Теперь остановимся чуть поподробнее на каждом из упомянутых компонентов.

2.1. HTTP.SYS

На транспортном уровне IIS использует прослушивателей протоколов (protocol listeners), которые располагаются поверх стека TCP/IP. Наиболее интересный нам такой компонент – это системный драйвер HTTP.sys, который встроен в ядро ОС и работает с протоколами HTTP и HTTPS, регистрирующийся самостоятельно на прослушку всех портов, на которые будут приходить запросы к сайтам в IIS.

Встроенный в ядро HTTP.sys стал нововведением в IIS 6, заместив собой Windows Socket API – компонент перехвата HTTP- и HTTPS-запросов на пользовательском уровне в IIS более ранних версий. Вероятно, интеграция драйвера в ядро является той самой причиной, по которой версия IIS жёстко привязана к версии Windows.

Драйвер принимает все входящие запросы и перенаправляет их в нужный пул приложений. Если по какой-то причине рабочий процесс, в коем хостится требуемый пул, остановлен (сбой, таймаут простоя, смена конфигурации и т.п.) или ещё запускается, то HTTP.sys сохраняет входящие запросы в специально отведённой для каждого пула очереди. Таким образом, запросы пользователей никуда не пропадают, и они вообще не замечают каких-то перебоев в работе сайтов под управлением IIS.

Ещё HTTP.sys умеет кешировать ответы (более подробно - Instances in which HTTP.sys does not cache content), поэтому некоторые запросы обрабатываются без передачи на уровень приложения, а также проводит первичный разбор URI запроса и его валидацию в соответствии с RFC 2396 (кое-что можно почерпнуть отсюда - Use of special characters like "%" ‘.’ and ‘:’ in an IIS URL) и журналирование запросов/ответов.

Некоторые настройки HTTP.sys вынесены в системный реестр Windows (более подробно - Http.sys registry settings for Windows). Кстати, там же – в реестре – можно подсмотреть обычное место прописки нашего гражданина: %SystemRoot%\system32\drivers\http.sys.

Признаться, в процессе написания данной статьи я сам открыл для себя некоторые детали. Например, кэширование ответов на уровне драйвера HTTP.sys. Это помогло мне объяснить один случай странного, как мне тогда казалось, феномена в поведении IIS. Маркетологи выложили на сайт swf-открытку перед очередным праздником, но потом им что-то не понравилось в названии файла и они его переименовали. Однако сайт продолжал выдавать открытку по старому URL и даже очистка браузерного кэша не помогала. Тут уже подключился я, но ни перезапуск веб-сайта и всего пула приложений, ни обращение к сайту в обход корпоративного прокси-сервера не дали ожидаемого результата. Но теперь-то мы знаем, кто виноват.

2.2. World Wide Web Publishing Service (W3SVC)

Данная служба (сокращённо именуемя в спецификациях WWW service) была представлена в IIS 6 в качестве отдельного компонента для работы с протоколами HTTP/HTTPS и управления рабочими процессами приложений и выполняла следующие функции:

Администрирование драйвера HTTP.sys.
Управление рабочими процессами.
Мониторинг показателей производительности веб-сайтов.

Эта служба функционирует в Windows Server 2003 в контексте процесса Svchost.exe (настройки можно посмотреть в реестре HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3Svc ) в отличие от всех остальных служб IIS, которые исполняются в контексте процесса Inetinfo.exe, и реализована в Iisw3adm.dll.

В IIS 7.x функция управления процессами была вынесена в отдельную службу – WAS (см. п.2.3) в целях универсализации архитектуры. Теперь WWW-служба стала по своей сути одним из адаптеров, специализируясь на протоколах HTTP/HTTPS – работа поверх драйвера HTTP.sys. Однако WWW-служба остаётся краеугольным компонентом IIS, поэтому её настройка отличается от настройки адаптеров к другим протоколам (чуть подобнее здесь); она функционирует в том же рабочем процессе, что и WAS, и реализована в той же самой библиотеке (рис. 2).

Рис.2. Рабочий процесс со службами W3SVC и WAS.

Раз уж зашла речь об адаптерах к прослушивателям протоколов (protocol listener adpater), то давайте чуть задержимся и посмотрим, какие они бывают. В принципе IIS 7.x можно настроить для обработки запросов по любым протоколам помимо типовых HTTP и FTP, например, POP3, SMTP, Gopher. Вы даже вольны придумать свой протокол для своей веб- или WCF-службы и реализовать для него все нужные компоненты, если не жалко своего времени. Скорее всего, адаптеры и прослушиватели для наиболее распространённых протоколов доступны для свободного и коммерческого скачивания – этого я не проверял. Но прежде всего стоить обратить внимание на стандартные службы (рис. 3), поставляемые с.NET Framework и интегрированные с IIS:

NetTcpActivator для протокола TCP;
NetPipeActivator для Named Pipes;
NetMsmqActivator для Message Queuing (ака MSMQ).

Рис. 3. Перечень стандартных не-HTTP-адаптеров в оснастке Служб Windows.

Но всё-таки наиболее важным для нас адаптером является именно WWW-служба, т.ч. остановимся чуть подробнее на двух оставшихся от IIS 6 функциях.

Администрирование и конфигурирование HTTP(S). В момент обновления конфигурации веб-сайтов, служба WAS передаёт эту информацию WWW-службе, а та уже, в свою очередь, настраивает HTTP.sys на прослушку конкретных портов, разбор IP и заголовка запрашиваемого сайта и, возможно, других параметров драйвера. В обратную сторону W3SVC обращается к WAS, когда в очередь запросов в HTTP.sys поступает новый, – для получения рабочего процесса-обработчика данного запроса.

Отслеживание показателей производительности. WWW-служба ведёт счётчики производительности, используя для этого драйвер HTTP.sys, и предоставляет их показатели веб-сайтами и кэшу IIS. Более подробной информации по этому вопросу мне найти не удалось.

2.3. Windows Process Activation Service (WAS)

Итак, WWW-служба в IIS 7.x, как и в IIS 6, продолжает выполнять задачи по администрированию HTTP.sys и управлению показателями производительности веб-сайтов. А вот задача управления рабочими процессами вынесена в отдельную службу – WAS. Она запускается системой в единственном экземпляре, считывает конфигурацию из файла %SystemRoot%\System32\inetsrv\Config\ApplicationHost.config и настраивает через соответствующие адаптеры прослушивателей протоколов в соответствии с указанной в нём информации. Напомним, что для протоколов HTTP/HTTPS адаптером является служба W3SVC, а прослушивателем – драйвер HTTP.sys. При перехвате прослушивателем запроса он через свой адаптер обращается к службе WAS для получения рабочего процесса приложения, которому будет передан запрос для обработки и формирования ответа клиенту.

При активации нужного для обработки пользовательского запроса приложения задействуются следующие компоненты:

Адаптеры прослушивателей (Listener adapters) – специальные службы Windows, работающие с конкретным протоколом и взаимодействующие с WAS для направления запросов к правильному рабочему процессу.
Собственно WAS. Она ответственна за создание рабочих процессов и управление их временем жизни.
Исполняемый файл w3wp.exe – шаблон рабочего процесса.
Менеджер приложений управляет созданием и утилизацией доменов приложений (application domains), которые хостятся внутри рабочего процесса.
Обработчики протоколов – протоколозависимые компоненты внутри рабочего процесса, ответственные за обмен данными между конкретным адаптером и рабочим процессом. Есть 2 типа обработчиков протоколов: у процесса (process protocol handler - PPH) и у домена приложения (AppDomain protocol handlers - ADPH).

Ниже на рисунке представлен пример схемы компонентов внутри некоего экземпляра рабочего процесса приложения. Когда служба WAS запускает рабочий процесс, она загружает в него согласно конфигурации приложения требуемые обработчики протоколов процессов (PPH) и посредством менеджера приложений создаёт внутри рабочего процесса домен приложения, в котором будет хоститься приложение. Менеджер приложений загружает код приложения в домен приложения и требуемые обработчики протоколов уровня приложения (ADPH) для обработки сообщений по соответствующим сетевым протоколам.

Рис. 4. Компоненты w3wp.exe для взаимодействия с внешними компонентами.

Как отмечалось выше, .NET Framework несёт в себе реализацию компонент для протоколов HTTP/HTTPS (наш любимый ASP.NET), net.tcp, net.pipe и MSMQ. Стеки протоколов HTTP/HTTPS и FTP всё-таки более тесно интегрированы в IIS и ОС, поэтому настройку для нового протокола лучше продемонстрировать на примере менее популярных дотнетовских протоколов. Итак, после установки фреймворка в файле конфигурации IIS ApplicationHost.config появляется записи:

А соответствующие компоненты PPH и ADPH настраиваются в дотнетовском machine.config:

В конфигурационном файле веб-сервера ApplicationHost.config вместе с настройками приложений хранятся связки (bindings), определяющие параметры входящих запросов, которые будут направляться данному приложению. Такими параметрами являются название сетевого протокола, IP-адрес сервера, доменное имя и порт сайта. Эти параметры должны быть уникальными среди работающих приложений для однозначной идентификации целевого приложения. Служба WAS отслеживает это ограничение и не даст вам запустить сайт, у которого это условие не соблюдено, либо предложит остановить сайт с такой же связкой.

Обратите внимание, что в стандартном режиме эксплуатации IIS служба WAS, служба-адаптер для каждого прослушивателя протокола (в т.ч. W3SVC) и сами драйверы/прослушиватели каждого из протоколов (в т.ч. HTTP.sys) запущены в ОС в единственном экземпляре. Но отдельные запросы могут направляться разным приложениям в разных рабочих процессах. С другой стороны, отдельно взятому приложению могут направляться запросы по разным протоколам через соответствующие адаптеры. Видимо, для корректной реализации такого поведения и была придумана архитектурная связка драйвер протокола – адаптер драйвера протокола – служба активации (своеобразный регулировщик, точнее - маршрутизатор) – рабочий процесс.

2.4. Пул приложений

При конфигурации веб-приложения помимо привязок (binding) к параметрам запросов и прочих настроек указывается принадлежность к пулу приложений. Пул приложений стал нововведением в IIS 6 и был призван обеспечить изоляцию веб-приложений друг от друго и тем самым повысить стабильность работы веб-сервера в целом. Суть заключается в том, что код приложения выполняется внутри специального процесса Windows – w3wp.exe. Поэтому исключение внутри веб-приложения приведёт к краху только этого процесса и никак не повлияет на доступность веб-приложений в других пулах и работу служб IIS. Более того, служба WAS попытается заново запустить упавший сайт, и внешние клиенты могут даже не заметить проблем в работе сервера.

Для управления некоторыми параметрами отдельно взятого рабочего процесса w3wp.exe в IIS используется пул приложений. Наиболее часто используемыми из них являются учётная запись, под которой будет запущен процесс, ограничения для очереди запросов, различные таймеры и счетчики для автоматического перезапуска процесса, архитектура x86/x64 (в IIS 7.x) и некоторые другие (рис. 5), о чём любопытный читатель может с лёгкостью прочесть в MSDN и любимом поисковике. Т.о. можно говорить (с определёнными оговорками, см. тж. последний абзац в 2.5) о тождественности процесса w3wp.exe и пула приложений.

Рис. 5 Дополнительные настройки пула приложений

Ключевым нововведением в концепции пулов приложений в IIS 7.x стал новый параметр – модель управления контейнером, который может принимать 2 значения: классическая (Classic mode) и встраиваемая модель (Integrated mode).
Чтобы объяснить разницу между этими режимами работы, потребуется знакомство с понятием «модуль» (Module) в IIS 6/7.x и событийной моделью обработки запросов в связке IIS + ASP.NET. Тема эта достойна отдельной статьи, но меня на неё уже, увы, не хватит, судя по всему. Здесь же представлю вашему вниманию лишь общие, ключевые моменты.

Итак, IIS при обработке запроса пропускает его внутри рабочего процесса через последовательность специальных компонент – модулей. Например фильтрация, перенаправление, кэширование, аутентификация, авторизация. Каждый такой модуль ассоциируется с определённым событием, а их последовательность составляют событийную модель обработки запросов. Модули делятся на нативные (Native) и управляемые (Managed). Нативные модули поставляются вместе с IIS, а управляемые – в составе.NET Framework (ASP.NET). В общем-то, вы можете управлять ими в определённой степени на уровне конфигурации веб-приложения, но взаимодействовать из кода своего ASP.NET-сайта вы можете только с управляемыми модулями.

Рис. 6. Идеология модулей в IIS.

Классическая модель управления контейнером обеспечивает обратную совместимость с режимом изоляции рабочих процессов в IIS 6 – запросы к ASP.NET-сайту сначала проходят через нативные модули, а затем передаются в Aspnet_isapi.dll для обработки модулями в управляемой среде. Такое разделение между IIS и ASP.NET приводит к дублированию некоторых функций, например, аутентификации и авторизации. И вы не имеете возможности управлять программно поведением нативных модулей (пример хоть и не самый животрепещущий, но всё же – раздел «Убираем заголовок Server» в ).

Встраиваемая модель предполагает более тесное взаимодействие между IIS и ASP.NET. Запрос в такой архитектуре обработки пропускается через установленную последовательность событий, в каждом из которых запрос пропускается через нативный и управляемые модули. В таком режиме модели обработки запросов IIS и ASP.NET объединены в единую модель, что позволяет избежать дублирования функций и получить больший контроль над обработкой запроса.

На практике самое важное, что необходимо учитывать при разработке и развёртывании веб-приложений, – это частичная несовместимость этих двух режимов. Т.е. при переводе сайта (точнее пула приложений, в котором работает сайт) из классической модели во встраиваемую практически всегда потребуется корректировка кода (хоть, возможно, и не значительная), а также тщательное тестирование.

2.5. Домен приложения, приложение

Непосредственными контейнерами веб-приложения являются приложение и домен приложения (Application Domain, AppDomain). Зачастую эти два понятия отождествляются, но всё-таки это немного разные вещи. Приложение – это понятие IIS, а домен приложения – из ASP.NET. Причём в общем случае в приложении может быть несколько доменов. Приложением вы можете управлять из консоли IIS, а доменом приложения – в основном программно. Так, например, перезапускается приложение из консоли. А когда мы пересохраняем web.config, то перезагружается именно домен приложения, не трогая IIS-приложение.

Более важным с практической точки зрения является то, что приложение/домен приложения является sandbox-ом для кода вашего ASP.NET-сайта (не с такой надёжной изоляцией, как в случае с пулом, но всё же). Приведу один из моих любимых вопросов, которые я задавал соискателям на собеседованиях. Пусть имеются веб-сайт-1 и веб-сайт-2, а также некая библиотека MyLib.dll, в которой определён класс MyClass1 со статическим полем Field1. Итак, оба сайта работают под управлением одного пула приложений и используют одну и ту же библиотеку MyLib.dll. Веб-сайт-1 записывает в MyClass1.Field1 = 16 (рис. 7). Вопрос: увидит ли веб-сайт-2 сделанные изменения? Напрашивается ответ «Нет». Но почему? Потому что, для IIS-приложений выделяются непересекающиеся адресные пространства, даже если они работают внутри единого рабочего процесса, поэтому в память веб-приложений загружаются свои копии сборок (прошу не придираться к возможным неточностям в терминах работы с памятью в.NET Framework).

Рис. 7. Рисунок для задачки.

Ещё один важный момент, который хотелось бы здесь отметить. По умолчанию каждый отдельный рабочий процесс может использовать все имеющиеся на сервере процессоры/ядра, а пул приложений работает на одном рабочем процессе и, следовательно, веб-приложение работает внутри одного IIS-приложения. Тем не менее, вы можете настроить web garden, увеличив кол-во рабочих процессов на пул и, следовательно, число IIS-приложений на одно веб-приложение. Вы без труда сможете найти на просторах интернета информацию о web garden, поэтому опускаю здесь подробности. Единственное, хотелось бы предупредить, что данное средство не является инструментом увеличения производительности, т.к. по умолчанию и так используются все вычислительные мощности сервера. Наоборот, на синхронизацию работы 2+ рабочих процессов уходил «лишнее» время CPU. Делается это в основном для увеличения доступности веб-приложения. Нельзя здесь также не упомянуть о веб-ферме (web farm), как о простейшем средстве балансировки нагрузки в IIS – об этом тоже достаточно статей в Сети. Это другой пример распределённого веб-приложения. Впрочем, с тем же nginx встроенная балансировка нагрузки в IIS конкуренции не выдерживает, и в реальных высоконагрузочных системах вам придётся изобретать свой велосипед или задействовать продукты сторонних производителей.

3. Что дальше?

Дальше нужно разбираться в работе модулей (в терминах IIS) и событийной модели, в которых уже происходит собственно обработка запроса, о чем упоминалось в разделе 2.4. Вообще говоря, эта тема заслуживает отдельной статьи, на которую, боюсь, меня уже не хватит. Но без этого нельзя сказать, что мы рассмотрели весь конвейер обработки запросов. Поэтому кратко пройдёмся здесь по основным моментам, которые любопытствующий читатель может проработать самостоятельно.

Как отмечалось выше в разделе 2.4 модули IIS содержатся внутри рабочего процесса. Через них последовательно пропускается запрос (в отличие от HttpHandler-ов). Их набор и порядок определяется конфигурацией сервера и/или конкретного веб-приложения. Модули предназначены для отдельных, узконаправленных задач, таких как авторизация, кэширование, кастомное логгирование, сжатие, возврат статического контента и, конечно же, формирование HTML-страниц по заданному URL.

Как мы уже знаем, модули в IIS бывают 2 типов: нативные и управляемые. Точный список модулей вы можете почерпнуть в MSDN-е или в статье Риган Темплин. Вы всегда можете написать свой модуль, например, для редиректов. Чаще всего, конечно, делают управляемые модули, т.к. их проще всего реализовать. К слову, ASP.NET WebForms и MVC работают в виде таких вот управляемых модулей. Т.ч. лично у меня холивары WebForms vs. MVC вызывают улыбку и трудно сдерживаемое желание потроллить. Зная принципы работы IIS и ASP.NET, вы сами сможете реализовать любой понравившийся вам паттерн.

На следующем уровне рассмотрения мы столкнёмся уже с составляющими ASP.NET, такими как HttpHandler-ы и события обработки страницы. Про это написана масса статей, т.ч. не вижу смысла сколько-нибудь задерживаться на этом. Единственное, позволю себе посоветовать идущим на собеседования забить в поисковике «ASP.NET page lifecycle» перед встречей – этого уж точно по моему глубокому убеждению стыдно не знать специалистам, считающих себя разработчиками на ASP.NET.

Пример дефолтных настроек нативных модулей в applicationHost.config

Пример дефолтных настроек управляемых модулей в applicationHost.config

***

Пример дефолтных настроек HTTP-обработчиков в applicationHost.config

*** ***
application pool

WAS

W3SCV

HTTP.sys

Добавить метки
Что мы ждём от профайлера? Нам нужна абсолютная (время) и относительная (проценты) статистика выполнения отдельных участков кода (если возможно, с точностью до строки). После оптимизации каких-то критичных участков кода нужно запустить профайлинг ещё раз и сравнить результаты.

Так как по роду деятельности я связан с разработкой под web, то в качестве подопытного будет выступать ASP.NET приложение (скачать):

public partial class Default: System.Web.UI.Page

protected void Page_Load(object sender, EventArgs e)

SampleBadMethod1();

SampleBadMethod2();

private void SampleBadMethod1()

for (int i = 0; i < 100; i++)

SampleBadSubMethod1();

private void SampleBadSubMethod1()

Thread.Sleep(10);

private void SampleBadMethod2()

for (int i = 0; i < 10000; i++)

SampleBadSubMethod2();

private void SampleBadSubMethod2()

Thread.Sleep(1);

* This source code was highlighted with Source Code Highlighter .

Небольшое лирическое отступление. Сначала хотел выбрать реальное приложение для профайлинга. Выбор пал на Tailspin Spyworks , которое используется в качестве steb-by-step руководства. Казалось бы, руководство для новичков должно быть так отполировано, чтобы сразу заинтересовать разработчика, научить каким-то правильным вещам. И что я там увидел? Кривоватую вёрстку, смесь бизнес-логики и разметки, неоптимальные запросы к БД, select * даже если тянутся 1-2 поля… Выполнять все оптимизации 4 раза (для 4-х профайлеров) оказалось очень трудоёмко, поэтому за 3 минуты было написано используемое в тестах приложение. Если кому-то интересно, в будущих статьях можно будет разобрать по косточкам Tailspin Spyworks.

Довольно лирики, запускаем профайлеры.

Visual Studio Perfomance Profiler

Запуск производится из VS через меню Analyze -> Launch Perfomance Wizard.
С помощью нескольких простых шагов выбираем тип профайлинга (я выбрал Instrumentation, т.к. в CPU sampling не показывается время выполнения, только в процентах), исследуемые проекты и нужно ли профилировать запросы к БД через ADO.NET.
После нажатия кнопки Finish запускается браузер, при этом в студии будет висеть заставка с кнопками Pause и Stop.

После окончания загрузки страницы в браузере, нажимаем Stop и получаем результат:

Вот как выглядит экран статистики по методам:

Теперь нужно оптимизировать критичные участки кода SampleBadMethod1 и SampleBadMethod2. В качестве «оптимизации» сокращаем количество итераций в цикле (например, со 100 до 50 и c 10000 до 1000).
Получаем ещё раз результат и через пункт меню Analyze->Compare Perfomance Reports сравниваем результат:

Ну что же, мы молодцы, получилось ускорить наше приложение.

Повторим те же действия с другими профайлерами.

ANTS Profiler

При создании новой сессии профайлинга появляется следующее окно:

Здесь можно выбрать тип приложения, опции профайлинга и ввести данные приложения, например, для ASP.NET application на dev-сервере это путь до приложения, версия.net, номер порта и т.п.
После нажатия кнопки Start Profiling запускается браузер, в ANTS Profiler в это время рисуется график загрузки процессора по оси времени.
Нажимаем кнопку Stop Profiling и получаем результат:

Подробно рассматривать назначение и функции областей экрана сейчас не буду (это тема отдельной статьи), кратко скажу, что в верхней части видно временную шкалу с загрузкой ЦП (или любым другим показателем, который вы можете выбрать сами), в центре дерево методов со статистикой выполнения по времени и количеству вызовов, в нижней части просмотр исходного кода методов (если код доступен).
Здесь есть некоторая странность: мы видим, что суммарное время выполнения метода SampleBadSubMethod2 равно 14 мс, хотя внутри него задержка на 1 мс и он вызывается 10000 раз. Возможно, ANTS как-то некорректно обрабатывает метод Thread.Sleep.

Теперь снова «оптимизируем» приложение, запускаем профайлер, получаем результат и… не можем сравнить средствами ANTS… В FAQ на сайте предлагают запустить ещё один профайлер и переключаться между ними, сравнивая результат. Ну, спасибо, что ещё сказать:)

В бой вступает

dotTrace

При выборе File->Profile появляется окно:

Выбираем тип приложения, задаём настройки и Run!
После запуска профайлинга появляется небольшое окно, с помощью которого можно получить результат (Get Snapshot) или завершить профайлинг.

После получения результата увидим следующее окно:

Здесь видим дерево методов с процентами и временем выполнения. В правой части можно посмотреть исходник того или иного метода.
Оптимизируем приложение, получаем результат и сравниваем с первоначальным:

Ну что ж, оптимизация удалась.

И напоследок

EQATEC Profiler

Запускаем профайлер, видим окно:

Здесь нужно выбрать путь до папки bin приложения, выбрать сборки, которые хотим исследовать на нажать Build.

Затем запускаем свой любимый браузер и загружаем страницу приложения. Если всё нормально, то в логе появится надпись Profiled appication xxx started и станут активными кнопки «Take snapshot» и «Reset counters»

А вот и наш snapshot:

Видим статистику вызовов, а также представление методов в виде блоков (в нижней части). Эти блоки кликабельны, т.е. можно переходить по иерархии вызовов вниз/вверх.
Теперь в очередной раз оптимизируем приложение и сравниваем результат:

Мы опять молодцы, ускорили приложение во много раз.

На этом всё, посмотрим на сводную таблицу возможностей представленных профайлеров

Summary

	VS Profiler	ANTS	dotTrace	EQATEC
Показ относительных результатов выполнения методов (в %)
Показ абсолютных результатов выполнения методов (в секундах, мс и т.п.)
Показ числа вызовов методов
Просмотр исходников методов
Сравнение результатов двух замеров
Цена	> 5000$ 1)	от 395$ 2)	от 199$ 3)	бесплатно 4)

1) в составе VS Premium и выше
2) зависит от редакции
3) для open source проектов бесплатен
4) ограничение на 10 одновременно загружаемых dll, за $ с меньшими ограничениями

Теперь рассмотрим замеченные мной достоинства и недостатки каждого профайлера в отдельности, не указанные в сравнительной таблице.

VS Profiler

встроен в VS (правда, в premium и ultimate)
взаимодействие с ADO.NET
капризный, иногда профайлинг не запускается без объяснения причин
секция appSettings должна быть в web.config, а не вынесена в отдельный файл, т.к. туда пишутся какие-то служебные настройки, а разработчики видимо не предусмотрели расположение данной секции во внешнем файле
на большом проекте и не очень мощной машине заметно подтормаживает

ANTS Profiler

самая подробная информация по вызовам методов, куча счетчиков производительности
в режиме профайла SQL думает, что кроме./SQLEXPRESS серверов больше не существует:)
нет сравнения двух результатов замеров

dotTrace

больше всех понравилась документация
в режиме просмотра дерева какая-то каша из цифр, названий методов, сборок
не запустился в режиме IIS Application, хотя всё делал по хорошей документации.

EQATEC

маленький и быстрый, подходит, если не нужно смотреть производительность построчно и не нужны исходники
данный минус - следствие плюса: меньше, чем у других конкурентов, возможностей.

Итак, сделаю, возможно, субъективный вывод. Мой выбор - EQATEC Profiler, для многих задач оценки производительности его более чем достаточно. Если у вас есть возможность использования VS Premium или Ultimate, встроенный профайлер достаточно неплохой продукт. В этом случае необходимость в покупке других профайлеров отпадёт. Из оставшихся двух профайлеров своей мощью поражает ANTS профайлер, хотя, конечно, почему нет сравнения результатов - непонятно. У dotTrace обилие вариантов приобретения с большим количеством возможностей самого профайлера.

Спасибо, что дочитали этот обзор! Надеюсь, он поможет вам сделать выбор.

P.S. Предложения по подробному обзору каждого профайлера принимаются.