Бегущий Город
Соревнования => Бегущий Город в столицах => Архив => БГМ-2о12 => Тема начата: Рожденный ползать от 21.03.2012, 14:57:00
-
Все как всегда, каждый год хотят сделать как лучше, а получается еще хуже чем было...
Господа орги, мне ли вас учить что под большие нагрузки или десяток серверов с распределенными БД или НИКАКИХ фреймворков использующих БД и динамическую генерацию страниц.
Чтож вы каждый год по одним и тем же граблям ходите?...
-
Рожденный ползать, добро пожаловать в реальный мир. Скажу с точки зрения business value такого решения: держать постоянно всё это хозяйство - это надо каждый месяц по два БГМ делать. И то не окупится. А запускать такие мощности два раза в год... Ну в общем вы, думаю, поняли.
-
держать постоянно всё это хозяйство - это надо каждый месяц по два БГМ делать. И то не окупится. А запускать такие мощности два раза в год... Ну в общем вы, думаю, поняли.
А брать в аренду можно? Пара недель на БГ, пара недель на БГМ. На остальных соревнованиях масштабной тыквы не бывает.
-
Рожденный ползать, добро пожаловать в реальный мир. Скажу с точки зрения business value такого решения: держать постоянно всё это хозяйство - это надо каждый месяц по два БГМ делать. И то не окупится. А запускать такие мощности два раза в год... Ну в общем вы, думаю, поняли.
Боюсь, что это вы меня не поняли.
Есть два метода:
1) Красиво - "с блэкджеком и ..." с использованием монструозных фреймворков, некой фигни аля фейсбук/контактик и прочего.
2) Топорно, некрасиво но без тыквы.
Вот 1 метод, это то что орги уже лет 5 пытаются сделать, и без монструозных мощностей не осуществим. Они это просто понять не могут...
А второй делается на коленке, выглядит убого НО РАБОТАЕТ!!!
-
Рожденный ползать, в движке сайта нет ни одного монструозного фреймворка. Там вообще ни одного фреймворка нет. Инфа 100%.
-
И еще, простой рассчет показывает, что при нормальном проектировании системы будет порядка 4 запросов к БД на регистрацию и активацию команды. Всего зарегилось меньше 1000 команд.
Так вот 4000 запросов за 1 час (у меня Тыква длилась именно столько) не могут свалить ни один SQL сервер. Значит реализация все-таки через Ж.
-
Рожденный ползать, в движке сайта нет ни одного монструозного фреймворка. Там вообще ни одного фреймворка нет. Инфа 100%.
Сколько запросов идет к БД с момента обновления страницы профиля до окончания регистрации, включая все запросы использующиеся для генерации страниц?
Я не верю что отправка статических страниц может свалить нормальный сервер.
-
Рожденный ползать, эти рассчёты неверны. Тут как минимум не учтено общение с платёжной системой.
Считаем по-минимуму.
1. Регистрация пользователя = запись о его создании. Если мы не попали в PK - пытаемся заново.
2. Создание команды = запись о создании команды Если не попали в PK - пытаемся заново.
3. Оплата = получение подтверждения от ПС = запись об оплате
4. Выдача времени = проверка наличия временного интервала + попытка записи о фиксации этого интервала за командой. Если удалось - хорошо. Если нет - повторить.
Кроме того, вы не учитываете, что заваливаться может не SQL-сервер, а интерпретатор кода из-за, например, утекшей памяти.
-
Рожденный ползать, не верите - приходите к нам на тыкву :)
-
Рожденный ползать, не верите - приходите к нам на тыкву :)
Зачем мне приходить, если я смотрю код сгенерированных страниц и в кажой вижу по 20-30 мест пораждающих эту тыкву, я вижу что с ней даже и не борятся. И что при таком подходе она будет, в этом нет никаких сомнений.
И еще, вот у меня сейчас появилось 3 левых команды, а вот даже после оплаты теперь уже 4ой их небыло...
-
Зачем мне приходить, если я смотрю код сгенерированных страниц и в кажой вижу по 20-30 мест пораждающих эту тыкву, я вижу что с ней даже и не борятся. И что при таком подходе она будет, в этом нет никаких сомнений.
Присоединяйтесь к команде разработчиков. Или хотя бы закидайте им багтрекер рацпредложениями.
И еще, вот у меня сейчас появилось 3 левых команды, а вот даже после оплаты теперь уже 4ой их небыло...
Раздавайте. Людям надо.
-
MegaManiac, дело говоришь.
Рожденный ползать, если смотрите в код и видите проблемные места - расскажите нам о них. Кстати, многое мы не можем проверить, ибо тяжело создать такую бешенную нагрузку, какую создают участники, постоянно обновляющие страницы в ожидании регистрации и более быстрого отклика сервера.
Для всех остальных - проект поддерживается волонтёрами. Чем больше волонтёров - тем лучше. Например, приглашаю людей присоединиться к команде тестирования сайта.
-
Присоединяйтесь к команде разработчиков. Или хотя бы закидайте им багтрекер рацпредложениями.
Да, подумываю. Нужно описать принцип регистрации без тыквы, вот только в новый дизайн сайта оно понятно не впишется, т.к. это дизайн (в плане подхода к построению страниц) это 50-70% текущей тыквы.
Раздавайте. Людям надо.
Лучше бы следали кнопку отказаться...
-
Лучше бы следали кнопку отказаться...
Согласен. И даже сам предлагал это несколько часов назад. Но, думаю, сейчас делать точно не будут. Так что, за неимением гербовой, придется писать на простой.
-
Рожденный ползать, про кнопку "отказаться" - подумаем.
-
Рожденный ползать, если смотрите в код и видите проблемные места - расскажите нам о них.
1) Выпилить все картинки.
2) Выпилить JavaScript помаксимуму, сейчас грузится порядка десятка файлов со скрптами, они при регистрации не нужны...
3) Количество свободных мест в каждой категории должно обновляться не по запросу клиентов (т.е. динамически при построении страницы) а раз в 30-60сек отдельный процессом на сервере. Например одельный процесс раз в 30 сек генерит статический файл со свободными местами, сразу по всем диапазонам времен. А клиенты только качают этот статический файл и JavaScript'ом на стороне клиента страница подстраивается под текущие показатели.
4) В страницу вставлено куча лишней информации, напрмер регистрационные данные, данные о соревновании, уверен они вставляются при генерации => отнимают время и возможно нагружают БД. Все это пользователь может хранить в куки после посещения профиля.
5) Чтоб получить страницу регистрации нужно обновить профиль, а это несколько соревнований +персональная информация, и еще у "бывалых" десяток другой архивных соревнований. Да да это куча процессорного времени на генерацию и еще уйма запросов в БД.
6) Подгрузка элементов со сторонних сайтов, как-то всякие банеры контактиков однокашников и прочей фигни, вот какую критическую роль они играют при регистрации команды???
И это только так, помелочи, перечислять можно бесконечно.
-
В серверах и прочем подобном разбираюсь плохо. Я немного в другой области инженер. Но с общетехнической и общечеловеческой точки зрения видно, что если сервер будут доставать в три раза меньше человек, то ему станет в три раза легче. Может, всё-таки вернуть раздельную регистрацию? Львов в один день, сфинксов в другой, всех остальных в третий. Можно без разнесения времени приёма заявок и оплаты. Но я могу и ошибаться, конечно. С этой стороны не видно внутреннюю кухню.
P.S. Готов поучаствовать в тестировании сайта. Если, конечно, нужны тестеры без специальных знаний веб-технологий)
-
Мое представление о безтыквенной регистрации:
1) При входе в профиль генерируется уникальный ключ (К1) по которому можно однозначно идентифицировать клиента и факт его логина.
2) В профиле есть ссылка на статическую страницу регистрации, которая лежит на сервере и выдается клиентам в первозданном виде (никакой динамики). До часа X там пустая страница, чтоб обновление страниц работало.
3) В час Х на место этой страницы выкладывается правильная. Которая содержит ключ (К2) для идентификации соревнований +подгружает только один файл, со свободными местами в категориях. JavaScript`ом на стороне !клиента! модифицируется, отключаются кнопки, скрываются категории без мест и т.д. Очень важно не делать это на сервере.
4) При нажатии кнопки зарегистрировать команду на сервер отправляются два ключа К1 и К2, от сервера приходит ключ К3 идентификатор поданной заявки.
5) На сервере крутится процесс который регистрирует заявки, выстраивает их в очередь и в фоне начинает добавлять их в БД попутно проверяя не кончились ли места. Заявки за последний час хранятся в оперативке и не ведут к обращению к БД. Этот же процесс отвечает HTTP серверу на статус заявки и все операции с ней.
6) Клиент должен получить страницу результатов регистрации, в которой единственный динамический элемент - статус заявки (в очереди, отклонена, зарегистрирована, готова к оплате, оплачена)
7) Если заявка зарегистрирована, то нужно ввести название команды и одного участника. Результат отправляется на сервер, где тот же процесс в фоне добавляет инфу о команде в БД, после добавления переводит в статус готова к оплате.
8) После чего заявка оплачивается.
9) Еще можно добавить страницу со списком заявок пользователя, их от того же процесса можно получить.
Т.е. основные момнты:
1) Минимизировать количество генерируемых страниц.
2) Развязать пользователей и БД.
3) Нужна программка/скрипт которая будет хранить историю за последний час в оперативке и выдавать ее HTTP серверу не нагружая БД.
-
Ой, мальчики, какие же вы умные... :))))))
-
Еще вариант - запускать на время первого часа регистрации "упрощенную версию" сайта, с минимальным оформлением, где вообще всего по минимуму.
-
Еще вариант - запускать на время первого часа регистрации "упрощенную версию" сайта, с минимальным оформлением, где вообще всего по минимуму.
Две огромные кнопки: "ЗАРЕГИСТРИРОВАТЬСЯ" и "ОПЛАТИТЬ".
-
Две огромные кнопки: "ЗАРЕГИСТРИРОВАТЬСЯ" и "ОПЛАТИТЬ".
Нет, одна, "ЗАРЕГИСТРИРОВАТЬСЯ И ОПЛАТИТЬ" :)))
-
ЗачЭм кнопка, просто ссылка текстом по центру:
"ЗАРЕГИСТРИРОВАТЬСЯ И ОПЛАТИТЬ"
:)))
-
А что такого Must_die если оплата будет приниматься раньше старта регистрации например за 5 дней до. Ведь о сумме оплаты вы пишете в положении заранее. Вот с выходом положения и открывать прием оплаты на личные счета. И хранить не деньги, а "купоны на активацию" нужного номинала.
Рожденный ползать а вот для того чтобы не кончались быстро и стоит вводить минимальное количество в команде и задержки регистрации с одного клиента.
Хотя лазейки конечно останутся и будут ли категоричны Орги если на старт придет 1 член команды, а не 2. "Мертвые души" никто не отменял.
-
Рожденный ползать а вот для того чтобы не кончались быстро и стоит вводить минимальное количество в команде и задержки регистрации с одного клиента.
Хотя лазейки конечно останутся и будут ли категоричны Орги если на старт придет 1 член команды, а не 2. "Мертвые души" никто не отменял.
1) Ну тогда я предлагаю требовать еще и диплом вуза, с приоритетом красным дипломам... зачем ограничивать людей, не всем нравится ходить с левыми людьми в команде если правильных не оказалось.
2) Я уже писал не здесь, у меня сегодня была ситуация когда отрубили инет в отделе на работе, пришлось бежать выгонять коллегу из-за компа в другом. В итоге 2 человека не работали. Если бы инета небыло совсем, то пришлось бы просить знакомых, НО они все сами регятся, поэтому ограничивать количество команд зарегеных с одного аккаунта это не правильно. Многие регят на друзей, потому, что время время регистрации ОЧЕНЬ не удачное и друзья сами не могут зарегиться.
-
Позволю себе тоже порассуждать на технические темы.
Мне было интересно - а по какой причине нельзя было создать команду, введя разную информацию об участниках и контактах, заранее?
1. Человек создает ее, затем входит в личный кабинет, напротив команды у него ссылка "Оплатить". Пока нет часа Х, ссылка неактивна (там разные реализации можно придумать, дело не особо хитрое).
2. После наступления часа Х человек (не перезагружая страницу, не вводя разные данные - ведь это все лишний POST - а, соответственно, пролезает на backend) кликает на ссылку - и улетает на сайт платежной системы. Там тыквы нет, все платит спокойно.
3. Остается только одно узкое место - оповещение сайта со стороны платежной системы. Там можно делать такие оптимизации: отдельная key-value база (не реляционная) на оплату такой-то командой суммы. Скрипт оплаты - минимальный, без всего лишнего. Теоретически (раз пошла такая пьянка) его вообще можно написать не на скриптовом, а на компилируемом языке - чтобы быстрее работал. Сохраняет данные в эту базу, база реплицируется куда-нибудь раз в n секунд. После оплаты человек улетает на страницу, на которой написано, что все хорошо и замечательно (а не на список команд), а также его время старта. Список команд обновляется раз в минуту, кэшируется с помощью nginx.
4. Остальные страницы сайта на время тыквы кэшировать в nginx.
5. Форум отключать нафиг (если он на том же сервере). Не определил, какой движок у этого форума (моджет, и самописный), но все форумы на php, которые видел, весьма прожорливы. Через полчаса-час, когда тыква рассасывается, вполне можно включать.
Конечно, описание сумбурное, но вдруг полезные мысли есть. Или команда проекта поучит меня уму-разуму :).
-
2. После наступления часа Х человек (не перезагружая страницу, не вводя разные данные - ведь это все лишний POST - а, соответственно, пролезает на backend) кликает на ссылку - и улетает на сайт платежной системы. Там тыквы нет, все платит спокойно.
4. Остальные страницы сайта на время тыквы кэшировать в nginx.
2. Сразу появится следующая ситуация, когда оплатили больше чем есть мест => нужно возвращать деньги, что в условиях современного законодательства больший гемор чем Тыква.
4. Нельзя кэшировать динамические страницы... они налету под конкретного пользователя генерятся.
-
Ну и если про облачные моменты говорили - приведу пример с Amazon-ом. Не знаю, конечно, какое сейчас используется железо и во сколько оно обходится, но, судя по http://aws.amazon.com/ec2/#pricing, (http://aws.amazon.com/ec2/#pricing,) вполне можно взять за 69 баксов в год мелкий сервер. А под две тыквы раз в год арендовать большой сервер на 2-3 часика.
-
2. Сразу появится следующая ситуация, когда оплатили больше чем есть мест => нужно возвращать деньги, что в условиях современного законодательства больший гемор чем Тыква.
Да, согласен, не подумал. Тогда перед улетом на страницу оплаты придется проверять (например, кидать на локальную ссылку), что места еще есть. Впрочем, а как сейчас обрабатывается такой момент: если я перешел на страницу платежной системы, но долго там сидел и в результате, когда оплатил и вернулся на сайт, там уже закончились места в категории? Тоже деньги возвращаются?
4. Нельзя кэшировать динамические страницы... они налету под конкретного пользователя генерятся.
Целиком - нельзя, а вот ssi никто не отменял - пусть отдельные участки только генерятся. Да и вообще, можно все эти участки разные свести к минимуму. Можно даже не всегда иметь такой вариант, а только в тыквенное время.
Вообще не вижу преступления в том, чтобы отключать часть функционала на тыквы - все равно потерпеть пару часов можно, а ресурсы высвобождаются. Все лучше, чем полчаса страницу открывать.
-
Рожденный ползать я говорил не о принудительном объединении, а о тех случаях, когда знакомые по каким то причинам(в основном по причине вероятности схода "слабого звена") регятся на отдельные команды,хотя могут ехать\идти вместе.
Можно найти ещё кучу причин, по которым одиночки регятся, но сейчас речь о тех кто из за них не попадают на соревнования вообще. Или вынуждены идти в другой категории.
По поводу тех. проблем, я в этот раз пытался с разных(Акадо и Ёта) - результат был одинаковый. Дома жена пробилась вообще с домашнего тоже как все - спустя 40 минут.
Судя по тому что мест в всадниках лайт уже не было - кто то пробивался и работал с сайтом.
Осталось выяснить как это было возможно, чтобы это могли все проделать, чтобы соблюсти хоть какие то равные условия доступа к регистрации.
-
ЗачЭм кнопка, просто ссылка текстом по центру:
"ЗАРЕГИСТРИРОВАТЬСЯ И ОПЛАТИТЬ"
:)))
Ненене!
ЗачЭм ссылка?
Просто текст: "Пазваныть Ашоту, решыть вапрос!"