На Blackball появилась страница с планом развития сайта. Очень хотелось бы его придерживаться.

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

Контента на Blackball с каждым часом становится всё больше, и одним из важнейших вопросов становится поиск, фильтрация и подборка по интересам сосайтников. Для кино сегодня открылась возможность копить избранное и заграбастать фильм в список отложенного просмотра. Потом появится для всего остального, вот тогда заживём!

Неожиданно для самого себя, метнулся кабанчиком и сделал ультрамегаклассную штуку - список топ-проектов на главной странице Blackball. Со спадающими списками подробностей, всё как в лучших домах. На главной же странице есть закладка «Разделы», но там может быть over 9000 разных проектов различной степени важности, интересности и адекватности, они нам тут не всегда могут быть интересны. А вот топ-проекты это те ради которых мне стоит тратить время, деньги и вообще гробить бесценное здоровье.

Получилось ли это неплохо... Это получилось божественно.

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

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

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

И когда на сайте есть и то, и другое, и пятое, и десятое, и везде пользователь уже оставил следы - без анализа что и как удалять, и удалять ли вообще, просто не обойтись.

Сегодня день рождения Blackball \m/ !!! 16 лет назад проект появился в Сети! Первая версия была по-своему хороша, но надо было что-то менять. Ура! Ура! Ура!

Начата кампания по сбору средств на новый сервер для Blackball.LV Измени мир к лучшему, задонать проект.  Спасибо ^_^

В жизни одного из выдающихся сайтов современности 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.