Я сегодня вдруг осознал, что неприметный http://alltests.yandex.ru/ стал первым публичным приложеньицем Яндекса, написанным на Django. Проект, прямо скажем, не отличается широкой функциональностью, однако даже он имеет ценность не только историческую, но и практическую.
История этой тестилки, вообще, интересная :-). Так вышло, что пару недель назад я узнал о том, что нам для новой школьной морды нужен простенький движок для прикольного теста на знание школьниками интернета, и сваять его надо быстро. Не смогши удержать язык за зубами, я сказал, что Django для таких задачек подходит прямо-таки замечательно. Инициатива мгновенно трансформировалась в наказание: на меня повесилось программирование этого проектика, учитывая, что разработчик из моей группы, который уже делал что-то похожее, был в отпуске.
Но в итоге я не пожалел. Именно на этом простом проекте мы неплохо обкатали процесс публикации джанговских приложений в Яндексе.
Итак, 20 августа я получил от менеджера проекта письмо с описанием и характеристиками, а вчера, 30 августа, проект был установлен на боевом кластере, протестирован на нагрузку и спокойно ждал сегодняшнего открытия. 10 дней могут показаться довольно большим сроком для такой мелкой задачки, однако надо понимать, что это не разработка заняла 10 дней, а весь процесс целиком от описания задачи письмом до боевого внедрения. Насколько я знаю, у нас обычно идея внедрения проекта за срок типа двух недель считается смехотворной, независимо от того, насколько проста сама идея. Просто сама схема внедрения включает много административной работы: организация разработки и верстки, раздачу доступа, оформление пакетов, тестирование и т.д. Но мы успели, причем не особенно напрягаясь, если честно :-).
Что еще интересно лично мне — это скоростные характеристики. Эта штучка при нагрузочном тестировании выдает 500 запросов в секунду. Да, она очень тупая, не требует авторизации, работает на кластере из двух машин и весь контент закеширован. Но все равно — сама цифра мне очень нравится, особенно учитывая, что программировалось это полтора дня :-). И у нас был еще бэкапный план, исключающий обращения в базу для сохранения результатов, где она теоретически была бы еще быстрее, но, как видно — не понадобилось.
Для полноты картины немножко спецификаций:
Железо на фронтенде | Кластер из двух машин (CPU Xeon, по 4 ядра на 2.3 ГГц на каждой) |
---|---|
Веб-сервер | lighttpd |
Сервер приложений | Питоний FastCGI-сервер flup |
БД | MySQL 5.0, один сервер |
Масштабирование нагрузки | Сервер memcached на обеих фронтенд-машинах |
В заключении хочу поблагодарить основных участников процесса: Сашу Ермолаева за верстку, Пашу Пушкарева за отлов проблем с конфигом lighttpd, Тимура Хайруллина за нагрузочное тестирование и менеджера Рому Михайлова за всего одну просьбу "поменять и подвинуть" после запуска :-).
Комментарии: 49
изотерическую ценность?
Поздравляю с рождением нового "ребенка"!:)
Эмммм.. сделано конечно отлично (кто бы сомневался) :)) - только вот хотябы варианты ответов при каждой загрузке вопроса местами менять... - а то как-то совсем некошерно
Вопросы классные. Кто придумывал?
Картинки тоже за 10 дней нарисовали?
База тестов будет расширяться?
Там SQLObject или SQLAlchemy?
Мне кажется что использованное оборудование избыточно раза в три если не более, или это Джанго так много кушает?
Класс - у меня черный пояс по интернету :-)
А вообще - молодцы - хоть сам я не питонер, больше нравится руби, но приятно видеть, как серьезные компании начинают использовать такие языки вместо пхп.
Apropo... А как у вас публикация устроена? У меня два веб сервера - один с MaxRequestPerChild 1, другой life. Загружаю через FTP на тестовый сервер, если приложение нормально работает, то прошу администратора толкнуть всё разом на life сервер и перезапустить apache.
Спасибо за отзывы, несколько ответов:
"Историческую" :-). Опечатался. Поправил, спасибо.
Изначально все очень беспокоились, что "как бы оно не тормозило", потому что "все эти фреймворки сначала вроде все хорошо, а потом приходится все переделывать". Поэтому был выбран вариант с жестким порядком, потому что его проще закешировать раз и навсегда. Да и честно говоря, в чем смысл перемешивания, что это меняет?
Про вопросы и базу тестов ничего не знаю... А вот нарисовано все было заранее, если не ошибаюсь, в Студии Лебедева.
Ни то, ни другое, конечно. Джанговский ORM.
Проект этот не кушает "виртуально ничего" на самом деле. Это просто один из рабочих миникластеров, на который сейчас вывешиваются джанговские вещи. В основном по той причине, что там наружу lighttpd стоит, а не обычный яндексовый веб-сервер, который традиционно используется. Эти же машины и еще подо что-то активно используются.
Проект заворачивается в deb-пакет, публикуется в репозиторий и выкладывается apt-get'ом на серверы. Я недавно про это писал.
это меняет то, что надо запоминать не как обезъяна - на такой-то вопрос ответ номер 3, а всё-таки думать - ну это вообщем-то не к вам, а к постановщику задачи ))
А... Ну это ж не серьезный экзамен, это прежде всего для развлечения самого участника делается.
кстати чувак на картинке с черным поясом похож на путина
Смешной вопрос номер 8. Откуда я знаю как сегодня называется RSS, если их уже версий семь, а то и девять? (Об этом Марк Пилгрим писал.)
Примечание: у меня есть страничка на одной машине с теми же характеристиками, безо всякого кеширования (еще не релизнута) выдается на скорости 600 запросов в секунду. Только на ней в базу ничего не пишется. Ruby, Rails. Если закешировать, будет медленнее? =)
Примечание-2: можно еще ускорить работу тестилки, если промежуточные результаты хранить к мемкеше или куках (с подписью, разумеется) и сохранять в базе только конечный результат. Или это уже сделано?
В смысле, только читается. Из нескольких таблиц.
Получил коричневый пояс, правда на доску почета не поставили :(
Интересный сервис, на счет скорости очень обрадовал :)
Ты же понимаешь, что именно база тормозит больше всего в той системе. Возможно оно было бы быстрее в 3, 4, 5 раз, если бы результаты писались в куки, но кого это волнует, если она и так с головой перекрывает все, что нужно?
Кстати, Олег, а нагрузка у тебя как меряется? Методика измерений, в принципе, может влиять на результаты очень сильно.
URL-ы типично джанговские... /2/1. IMHO, лучше бы тесту дали имя, чем порядковый номер.
Ну и чувствуется недостаток тестирования: можно скакать по вопросам и пять раз отвечать на один и тот же вопрос, меняя URL; можно случайно попасть на чужой результат, убрав ID из URLа.
А вообще, с почином ;)
Юрий, как ни странно, каждый из этих вопросов рассматривался и задуман именно так как сделан :-)
IDшки вместо slug'ов решил завести просто для того, чтобы не объяснять контент-менеджерам, что это такое, зачем нужно, и почему писать туда "naskolko-horosho-vy-znaete-internet" — ужасно :-).
То, что можно "подогнать" ответ или смотреть на другие ответы просто меняя цифры URL'а, совершенно конкретно было объявлено неважным. Во-первых, если кому-то очень хочется — пусть так сделает, порадуется. Во-вторых, даже если придумать авторизацию и хранить результат для каждого юзера, это не помешает людям просто скопипейстить результат из дневника друга, у которого черный пояс. Зато такая простая схема позволяет не грузить базу лишними проверками.
Кстати про контент-менеджеров. Судя по срокам разработки, используется джанговская автоадминка. Каковая реакция контент-менеджеров на нее? Есть ли замечания/нарекания?
Приведу диалог по памяти между мной и менеджером:
Собственно, задачка простая, ничего особенного там нет, и админка там действительно справляется почти идеально.
А можно ли получить черный пояс? Я несколько раз отвечал и не уверен только в вопросе про RSS (мне кажется что RDF Site Summary).
Получаю только коричневый
Mikhail Kashkin, попробуй воспользовать гуглом, ой, яндексом :-).
Иван, маленькая, но приятная работа.
..bw
10 дней — реально круто для компании!
Практически подумал — сделал.
С почином!
:)
Во первых поздравляю и дебютом Django на Yandex.
Интересно будет насколько нагрузочное тестирование совпало с реальным использованием (т е не получилось ли так что реальная нагрузка была намного выше).
Мы однажды поддерживали систему тестов для школ (HTML). Проблема проявилась в виде высоких пиковых нагрузок. Все школы начинают работать в одинаковое время. И представим себе день, когда по программе тесты. Так вот всего несколько десятков школ способны были положить наш сервер на 10 минут стабильно... (несколько тысяч студентов ломиться в секунду на одну и ту же страницу).
Мы поменяли технологию. Вместо того, чтобы показывать тесты по страницам, мы сделали Flash который получает шифрованный XML с вопросами/ответами, тестирует, отсылает ответы на сервер. Уже около пятисот тысяч студентов, пока простенький сервер даже на 10% не подгружен...
Я запускал ab на соседней машине. Расстояние — один свич.
Не, какой конкретно программой это делать — не так интересно. Интересно — это количество параллельных потоков, какие конкретно запросы (GET'ы, POST'ы) и насколько они близко соответствуют реальной нагрузке, которую пользователи создают. Понятно, что если посадить базу и делать всегда один и тот же select милион раз подряд, то она сама его закеширует и будет отдавать ну очень быстро. А если начать перемежать эти select'ы insert'ами, которые будут перестраивать индексы, то это будет совсем другое дело.
В частности alltests тестировался так: я руками в Firefox'е включил livehttpheaders, зашел на сайт и прошел один раз весь тест. Все содержимое запросов (31 штука, в перемешку POST'ы и GET'ы) сдампил в файл, слегка причесал и размножил 10000 раз. После этого эту ленту прогоняли тестовым скриптом на серверах. Вот там подробностей, насколько сильно она была распараллелена, и насколько сама тестирующая машина способна выдать нагрузки, я не знаю, к сожалению.
Но на самом деле, это все не очень интересно, потому что сервис "никакой" :-). Вот когда выйдет наш нормальный джанговский проект, тогда это будет иметь смысл.
иван, только что секунд 15 наблюдася 500 - Internal Server Error в стандартном некрасивом lighttpd-шном оформлении.
Наверное администраторы что-то перезапускали, теперь это уже их епархия :-). То есть, если это было 15 секунд, наверняка что-то контролируемое, а не само вдруг упало.
Жаль, не смог оценить :-)
500 - Internal Server Error
500 - Internal Server Error
http://alltests.yandex.ru/2/1/
500 - Internal Server Error
Забавно.
а что этот простой тест так колбасит? аж на кластере! :) боюсь представить, что будет с ним, если его положить на обычный сервак :)
битый час потратил на этот тест в надежде дойти до последнего вопроса - "500 - Internal Server Error", причем на разных местах. Плохое мнение популизируете, товарищ, о джанго.
постоянно сыпятся 500-е ошибки :-/
похоже всё-таки проблема с софтом
Позвольте все же пресечь злорадство по поводу Джанго и "аж на кластере" :-). Сутки оно работало совершенно без проблем, а что там случилось вчера вечером, будем выяснять.
О! Заработало! Черный пояс :).
Если не секрет, в чем была проблема?
Осмелюсь предположить что была проблема связи lighttpd и python'а - обычно lighttpd имеено так отвечает когда не может до аппликашн-сервера достучаться.
Да, примерно так. Судя по логам, lighty сначала долго останавливали и стартовали, а потом он стал жаловаться на соединение с FastCGI-сервером. Причем, происходило это только на одном сервере кластера, что объясняет, почему часть запросов обрабатывалась, а часть нет.
По опыту скрещивания Апача и Рельсы через FCGI, знаю что FCGI склонен выпадать в случайные моменты времени и на выходе будет 500. Кстати, почему лайти, а не nginx?
За совет с дампом и livehttpheaders — спасибо, очень разумный метод.
Почему лайти — точно не знаю, я к решению его использовать был не причастен. С другой стороны, он всем в целом нравится, поэтому вполне могло быть так, что он появился первым, а потом просто не было смысла искать что-то другое.
А касаемо выпаданий тут сравнивать наверное нельзя. Питоновский FastCGI делается нативной библиотекой flup, которая как раз известна своей надежностью. У нас он в итоге, отвалился-то не сам по себе, а "вручную" (хоть и не специально).
Хм.. интересная истина ;)
Как можно! nginx делался Сысоевым для Рамблера! :)
в nginx нет cgi
это кеширущий сервер и сервер для статики. а лайти просто лёгкий сервер. хотя в данном случае можно хоть IIS ставить :)
Да нет, в nginx есть fastcgi, и Джанго-проекты довольно часто за ним работают.
aim, покажите того, кто использует CGI при нагрузке больше одного запроса в секунду :)
Интересно иногда узнать о том, как что делается на таких крупных проектах, статья хотя и самохвалебная, но и познавательная, особенно в обсуждении.
в конце теста:
Увы, пройти все есты так и не удалось..ошибка сервера на саамом интересном месте). А почему бы не оповещать тестируемого в правильности ответов?