Как избежать тыквы. Советы по "техническим" моментам

[Рожденный ползать]

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

[stas-kh]

Рожденный ползать, добро пожаловать в реальный мир. Скажу с точки зрения business value такого решения: держать постоянно всё это хозяйство - это надо каждый месяц по два БГМ делать. И то не окупится. А запускать такие мощности два раза в год... Ну в общем вы, думаю, поняли.

[Alexey_B]

держать постоянно всё это хозяйство - это надо каждый месяц по два БГМ делать. И то не окупится. А запускать такие мощности два раза в год... Ну в общем вы, думаю, поняли.

А брать в аренду можно? Пара недель на БГ, пара недель на БГМ. На остальных соревнованиях масштабной тыквы не бывает.

[Рожденный ползать]

Рожденный ползать, добро пожаловать в реальный мир. Скажу с точки зрения business value такого решения: держать постоянно всё это хозяйство - это надо каждый месяц по два БГМ делать. И то не окупится. А запускать такие мощности два раза в год... Ну в общем вы, думаю, поняли.

Боюсь, что это вы меня не поняли.
Есть два метода:
1) Красиво - "с блэкджеком и ..." с использованием монструозных фреймворков, некой фигни аля фейсбук/контактик и прочего.
2) Топорно, некрасиво но без тыквы.
Вот 1 метод, это то что орги уже лет 5 пытаются сделать, и без монструозных мощностей не осуществим. Они это просто понять не могут...
А второй делается на коленке, выглядит убого НО РАБОТАЕТ!!!

[stas-kh]

Рожденный ползать, в движке сайта нет ни одного монструозного фреймворка. Там вообще ни одного фреймворка нет. Инфа 100%.

[Рожденный ползать]

И еще, простой рассчет показывает, что при нормальном проектировании системы будет порядка 4 запросов к БД на регистрацию и активацию команды. Всего зарегилось меньше 1000 команд.
Так вот 4000 запросов за 1 час (у меня Тыква длилась именно столько) не могут свалить ни один SQL сервер. Значит реализация все-таки через Ж.

[Рожденный ползать]

Рожденный ползать, в движке сайта нет ни одного монструозного фреймворка. Там вообще ни одного фреймворка нет. Инфа 100%.

Сколько запросов идет к БД с момента обновления страницы профиля до окончания регистрации, включая все запросы использующиеся для генерации страниц?
Я не верю что отправка статических страниц может свалить нормальный сервер.

[stas-kh]

Рожденный ползать, эти рассчёты неверны. Тут как минимум не учтено общение с платёжной системой.
Считаем по-минимуму.
1. Регистрация пользователя = запись о его создании. Если мы не попали в PK - пытаемся заново.
2. Создание команды = запись о создании команды Если не попали в PK - пытаемся заново.
3. Оплата = получение подтверждения от ПС = запись об оплате
4. Выдача времени = проверка наличия временного интервала + попытка записи о фиксации этого интервала за командой. Если удалось - хорошо. Если нет - повторить.

Кроме того, вы не учитываете, что заваливаться может не SQL-сервер, а интерпретатор кода из-за, например, утекшей памяти.

[stas-kh]

Рожденный ползать, не верите - приходите к нам на тыкву :)

[Рожденный ползать]

Рожденный ползать, не верите - приходите к нам на тыкву :)

Зачем мне приходить, если я смотрю код сгенерированных страниц и в кажой вижу по 20-30 мест пораждающих эту тыкву, я вижу что с ней даже и не борятся. И что при таком подходе она будет, в этом  нет никаких сомнений.
И еще, вот у меня сейчас появилось 3 левых команды, а вот даже после оплаты теперь уже 4ой их небыло...

[MegaManiac]

Зачем мне приходить, если я смотрю код сгенерированных страниц и в кажой вижу по 20-30 мест пораждающих эту тыкву, я вижу что с ней даже и не борятся. И что при таком подходе она будет, в этом  нет никаких сомнений.

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

И еще, вот у меня сейчас появилось 3 левых команды, а вот даже после оплаты теперь уже 4ой их небыло...

Раздавайте. Людям надо.

[stas-kh]

MegaManiac, дело говоришь.
Рожденный ползать, если смотрите в код и видите проблемные места - расскажите нам о них. Кстати, многое мы не можем проверить, ибо тяжело создать такую бешенную нагрузку, какую создают участники, постоянно обновляющие страницы в ожидании регистрации и более быстрого отклика сервера.
Для всех остальных - проект поддерживается волонтёрами. Чем больше волонтёров - тем лучше. Например, приглашаю людей присоединиться к команде тестирования сайта.

[Рожденный ползать]

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

Да, подумываю. Нужно описать принцип регистрации без тыквы, вот только в новый дизайн сайта оно понятно не впишется, т.к. это дизайн (в плане подхода к построению страниц) это 50-70% текущей тыквы.

Раздавайте. Людям надо.

Лучше бы следали кнопку отказаться...

[MegaManiac]

Лучше бы следали кнопку отказаться...

Согласен. И даже сам предлагал это несколько часов назад. Но, думаю, сейчас делать точно не будут. Так что, за неимением гербовой, придется писать на простой.

[stas-kh]

Рожденный ползать, про кнопку "отказаться" - подумаем.

[Рожденный ползать]

Рожденный ползать, если смотрите в код и видите проблемные места - расскажите нам о них.

1) Выпилить все картинки.
2) Выпилить JavaScript помаксимуму, сейчас грузится порядка десятка файлов со скрптами, они при регистрации не нужны...
3) Количество свободных мест в каждой категории должно обновляться не по запросу клиентов (т.е. динамически при построении страницы) а раз в 30-60сек отдельный процессом на сервере. Например одельный процесс раз в 30 сек генерит статический файл со свободными местами, сразу по всем диапазонам времен. А клиенты только качают этот статический файл и JavaScript'ом на стороне клиента страница подстраивается под текущие показатели.
4) В страницу вставлено куча лишней информации, напрмер регистрационные данные, данные о соревновании, уверен они вставляются при генерации => отнимают время и возможно нагружают БД. Все это пользователь может хранить в куки после посещения профиля.
5) Чтоб получить страницу регистрации нужно обновить профиль, а это несколько соревнований +персональная информация, и еще у "бывалых" десяток другой архивных соревнований. Да да это куча процессорного времени на генерацию и еще уйма запросов в БД.
6) Подгрузка элементов со сторонних сайтов, как-то всякие банеры контактиков однокашников и прочей фигни, вот какую критическую роль они играют при регистрации команды???

И это только так, помелочи, перечислять можно бесконечно.

[Alexey_B]

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

P.S. Готов поучаствовать в тестировании сайта. Если, конечно, нужны тестеры без специальных знаний веб-технологий)

[Рожденный ползать]

Мое представление о безтыквенной регистрации:

1) При входе в профиль генерируется уникальный ключ (К1) по которому можно однозначно идентифицировать клиента и факт его логина.
2) В профиле есть ссылка на статическую страницу регистрации, которая лежит на сервере и выдается клиентам в первозданном виде (никакой динамики). До часа X там пустая страница, чтоб обновление страниц работало.
3) В час Х на место этой страницы выкладывается правильная. Которая содержит ключ (К2) для идентификации соревнований +подгружает только один файл, со свободными местами в категориях. JavaScript`ом на стороне !клиента! модифицируется, отключаются кнопки, скрываются категории без мест и т.д. Очень важно не делать это на сервере.
4) При нажатии кнопки зарегистрировать команду на сервер отправляются два ключа К1 и К2, от сервера приходит ключ К3 идентификатор поданной заявки.
5) На сервере крутится процесс который регистрирует заявки, выстраивает их в очередь и в фоне начинает добавлять их в БД попутно проверяя не кончились ли места. Заявки за последний час хранятся в оперативке и не ведут к обращению к БД. Этот же процесс отвечает HTTP серверу на статус заявки и все операции с ней.
6) Клиент должен получить страницу результатов регистрации, в которой единственный динамический элемент - статус заявки (в очереди, отклонена, зарегистрирована, готова к оплате, оплачена)
7) Если заявка зарегистрирована, то нужно ввести название команды и одного участника. Результат отправляется на сервер, где тот же процесс в фоне добавляет инфу о команде в БД, после добавления переводит в статус готова к оплате.
8) После чего заявка оплачивается.
9) Еще можно добавить страницу со списком заявок пользователя, их от того же процесса можно получить.

Т.е. основные момнты:
1) Минимизировать количество генерируемых страниц.
2) Развязать пользователей и БД.
3) Нужна программка/скрипт которая будет хранить историю за последний час в оперативке и выдавать ее HTTP серверу не нагружая БД.

[Zlatenika]

Ой, мальчики, какие же вы умные... :))))))

[Limper]

Еще вариант - запускать на время первого часа регистрации "упрощенную версию" сайта, с минимальным оформлением, где вообще всего по минимуму.

[Must_die]

Еще вариант - запускать на время первого часа регистрации "упрощенную версию" сайта, с минимальным оформлением, где вообще всего по минимуму.

Две огромные кнопки: "ЗАРЕГИСТРИРОВАТЬСЯ" и "ОПЛАТИТЬ".

[Рожденный ползать]

Две огромные кнопки: "ЗАРЕГИСТРИРОВАТЬСЯ" и "ОПЛАТИТЬ".

Нет, одна, "ЗАРЕГИСТРИРОВАТЬСЯ И ОПЛАТИТЬ" :)))

[Taruggin]

ЗачЭм кнопка, просто ссылка текстом по центру:


"ЗАРЕГИСТРИРОВАТЬСЯ И ОПЛАТИТЬ"


:)))

[Disailor]

А что такого Must_die если оплата будет приниматься раньше старта регистрации например за 5 дней до. Ведь о сумме оплаты вы пишете в положении заранее. Вот с выходом положения и открывать прием оплаты на личные счета. И хранить не деньги, а "купоны на активацию" нужного номинала.

Рожденный ползать а вот для того чтобы не кончались быстро и стоит вводить минимальное количество в команде и задержки регистрации с одного клиента.
Хотя лазейки конечно останутся и будут ли категоричны Орги если на старт придет 1 член команды, а не 2. "Мертвые души" никто не отменял.

[Рожденный ползать]

Рожденный ползать а вот для того чтобы не кончались быстро и стоит вводить минимальное количество в команде и задержки регистрации с одного клиента.
Хотя лазейки конечно останутся и будут ли категоричны Орги если на старт придет 1 член команды, а не 2. "Мертвые души" никто не отменял.

1) Ну тогда я предлагаю требовать еще и диплом вуза, с приоритетом красным дипломам... зачем ограничивать людей, не всем нравится ходить с левыми людьми в команде если правильных не оказалось.
2) Я уже писал не здесь, у меня сегодня была ситуация когда отрубили инет в отделе на работе, пришлось бежать выгонять коллегу из-за компа в другом. В итоге 2 человека не работали. Если бы инета небыло совсем, то пришлось бы просить знакомых, НО они все сами регятся, поэтому ограничивать количество команд зарегеных с одного аккаунта это не правильно. Многие регят на друзей, потому, что время время регистрации ОЧЕНЬ не удачное и друзья сами не могут зарегиться.