В жизни одного из выдающихся сайтов современности Blackball произошло очень важное событие. Он стал намного лучше.

Когда проект был небольшим, не было никаких проблем с его развитием и обновлением всех тематических разделов. Но со временем возникла ситуация когда цикл разработки подпроектов стал слишком долгим и обновление сайта стало тяжёлой заботой. А это неправильно, работа над этим проектом должна приносить только радость. Взял себя в руки, подумал два раза и решил разделить один большой проект (/music, /video, /cinema, /games, /magazine  и т. д.) на отдельные части.

Некоторые мне говорили, с явно выраженным подъё..., скажем так с иронией и сокрушающим сарказмом, «Несколько веб-сайтов в одном солюшене? Да ты мозг! И когда ты это придумал? Мы такое уже давно используем.» Ну понятное дело что держать в одном солюшене несколько разных веб-проектов для разных доменных имён это само собой разумеющееся решение.

В случае с Blackball получилось решение когда каждый тематический раздел являет собой отдельное веб-приложение, но все живут под одним доменным именем, используют один Application Pool, и теперь цикл разработки каждого подпроекта может быть сколь угодно долгим и никак не мешает всему порталу. Круто? Не то слово. 

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

1. Поставить ещё более мощный сервер.
2. Распараллелить web приложение.
3. Распараллелить чтоб аж Google «завидовал» - построить Web Farm.

2-й способ является наиболее оптимальным, потому что просто более мощный сервер может решить проблему лишь на некоторое время, а построить Web Farm - уже слишком дорого покупать несколько серверов. К тому же 2-й способ является очень простым и не требует дополнительных ресурсов и растрат.

Web Garden (веб-сад) это web приложение в котором количество рабочих процессов больше 1. Этот механизм появился в IIS 6, в котором также появилась возможность создавать N пулов под N сайтов (max 2000 pools). Каждый пул в IIS по умолчанию работает в режиме isolation mode, это значит, что каждый пул будет иметь свою память, свой контекст и свои границы приложения. Также это значит, что если сайт «упадёт», то упадёт только этот пул, с сайтами которые в нём существуют, но не весь сервер, как было раньше в IIS 5). Поскольку пул может работать изолированно, мы можем дать ему возможность создавать ещё процессы для того, чтобы приложение могло выдерживать больше подключений. Тем самым мы его распараллеливаем, снижая блокировки на ресурсы, используемые приложением. Все запросы, которые приходят в конкретный пул, разделяются между процессами web сада. Таким образом, используя Web Garden на Blackball.LV удалось решить проблему постоянного перезапуска IIS 7.0 Application Pool из-за чрезмерно высокой нагрузки.

Примущества Web Garden:

• Легко настраивается;
• Надежная и устойчивая обработка запросов. Если один из процессов в пуле будет работать не стабильно или «упадёт» по неизвестным причинам, то его сразу подменит другой процесс из пула;
• Меньше блокировок на ресурсы. Когда web garden доходит до состоянии «сейчас лопну», то каждое новое подключение к серверу распределяется между процессами по карусельному принципу.

Глубокое исследование вопроса как в ASP.NET разумнее всего обращаться с объектами Session, Response и Request дало свои положительные результаты. Неправильное и нерациональное использование этих объектов может быть довольно дорогостоящим по затрачиваемым ресурсам, особенно если проект является достаточно высоконагруженным. Полный рефакторинг Blackball.LV решил проблему хронического зависания Application Pool и общей тормознутости сайта.

Очень интересным остаётся вопрос как реализовать общий доступ к объекту Session из разных приложений ASP.NET, даже находящихся на одной физической машине, и судя по всему придётся написать какой-то server-side handler.

Для Blackball.LV готов аудиоплеер собственной выпечки. Play, Pause, Stop, Playlist, Shuffle - всё как в лучших домах. Просмотрев кучу готовых проигрывателей, в очередной раз стало понятно одно: если хочешь получить хороший результат - сделай это сам.

Послушать Halford - Resurrection (2000)

Захотелось вывести свои проекты на новый уровень, и в рамках этого возник интерес научиться использовать SignalR 2. Начать решил с создания чата для Blackball.LV. Не знаю кому он может там понадобиться и кто им будет пользоваться, но чат уже почти готов, осталось довести его до ума. Можно будет создавать каналы, комнаты, разграничивать уровни доступа (публичный, приватный, публичный только для участников сайта и т. п.), обмениваться файлами, создавать временные комнаты (создали, поговорили, все вышли - комната улетела в космос). Пока планируется что полнофункциональный чат откроется 01.07.2015.

NuGet Gallery | Microsoft ASP.NET SignalR 2.2.0

Наконец-то нашлось время избавить свои проекты от монструозного ASP.NET AJAX Control Toolkit. Для административного сайта эта библиотека может быть и полезна, но для публичных проектов, особенно тех которые бомбят своими набегами поисковые роботы - это просто какой-то тихий ужас.

На дворе уже какой год идёт 21 век, а на многих сайтах URL всё ещё представлен в архаичном виде типа http://[domain]/shop/cat.aspx?id=54356&product=related&view=specs. На Blackball.lv уже начата работа по приведению URL в современный вид, кстати более дружественный к поисковым системам, потом наведём порядок здесь.

Learn how to use LINQ in your applications with these code samples, covering the entire range of LINQ functionality and demonstrating LINQ with SQL, DataSets, and XML. https://code.msdn.microsoft.com/101-LINQ-Samples-3fb9811b

На собеседованиях в разрезе поиска работы заметил интересный момент. Могут задать вопрос, на который ожидается развёрнутый грамотный ответ. Это нормально, ведь о тебе нужно узнать на что ты способен, что умеешь, что знаешь и т.д.. Не знаю как в других сферах, но в IT возможных вопросов много, их тысячи. Каких вопросов ожидать - неизвестно, к чему готовиться - неизвестно, надо быть готовым ко всему. Коварность собеседования заключается в том что вопрос может быть совершенно из разных областей (особенно если обозначил их в CV), и понимая что у тебя есть всего минут 15-30 чтобы создать свой профессиональный портрет, от волнения можно слегка растеряться, накосячить... Самое обидное что если во время ответа где-то ошибёшься, чуть напутаешь, а интервьюер уже составит впечатление, а потом после интервью минут через 20 уже в свободном полёте осознаёшь что ведь ответить надо же было так, чего ты там так разволновался?

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

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

Поставил новый сервер, казалось бы всё отлично. Так и было, по сравнению со старым сервером сайты заработали молниеносно, пока не выяснилось что объект Session в .NET - оказывается довольно неприятная штука, и в высоконагруженных проектах его использование нужно всячески избегать - сайт просто зависает. Для небольших проектов это не критично, а вот для добротного портала придётся писать свой механизм сессии.