Несколько мелких признаков. Если lighttpd работает как прокси/балансировщик, он возвращает Server бэкенда. У вас же он идентичен фронтэнду. Одно из двух:
У вас в бэкендах те же lighttpd c server.tag = lighttpd / Pony Powered!, a сам lighttpd кроме fastcgi для django больше ни на что не годен
Затерт Server на фронтэнде, похачен Server для Apache, но я не думаю, что вы занимались такой ерундой:)
Несколько мелких признаков. Если lighttpd работает как
прокси/балансировщик, он возвращает Server бэкенда. У вас же он
идентичен фронтэнду.
Все не совсем так. Балансировщик у нас не lighttpd, а LSB. За ним действительно стоят lighttpd, которые можно считать фронтендами. В бэкендах — да, flup'овские процессы через FastCGI. Но с тем же успехом в бэкенде мог быть например Apache через HTTP. То, что lighttpd проставляет Server с проксируемых серверов, я не знал :-).
Насчет же "почему FastCGI"... А почему нет? Решение из коробки Джанго. Работает. На таких нагрузках, когда flup начинает тормозить, Афиша сейчас не работает (по большей части от того, что там серверов немало). Других нареканий к нему не было.
В целом, да. Мы исходили из неверных предположений о том, как это хранилось раньше, и заметили уже после выкладки. Впрочем, кажется там ничего не пропало физически, и мы собираемся эти данные в итоге достать.
А почему так много маленьких js файлов?
This page has 25 external Javascript scripts.
Ведь это не так уж и хорошо для front-end performance-a, даже плагин Yslow сильно ругается.
Это джанго так генерит или что-то ещё?
Не, Джанго к javascript'у отношения не имеет. Это то, до чего еще руки просто не дошли. Верстка нынешней afisha.yandex.ru — это имитация верстки предыдущего движка с реализацией некоторых новых фишек через jquery. Поэтому там сейчас много всего намешано.
Это очень странный вопрос. Javascript'овый фреймворк с серверным никак не связан, поэтому с одной стороны ответ — "нет, они вообще не интегрируются", а с другой — "да, ничто не мешает их использовать".
В частности, для jquery есть плагин, который подменяет сабмит форм на ajax-запросы. Серверную часть, на чем бы она ни была написана, для этого менять никак не надо.
Ok, не совсем так. Серверная часть должна, конечно, уметь отдавать ответы в виде, который будет удобен javascript-приложению. Все средства для этого в Питоне есть.
Я просто недавно работал с JSF(Rich Faces), и он при генерации форм очень много своего javascript-a генерировал, который конфликтовал с другими библиотеками, и это создало нам много проблем.
Спасибо за ответы.
Комментарии: 18
16.03.09 17:40
Поздравляю. Еще один шаг Django по планете. Вопрос: 1. Почему fastcgi? 2. Будут сорцы на djangosites?:)
P.S. Я когда-то оставлял X-Powered-By: Magic Pony =) Но потом убрал, так как он отдавался для всего в том числе и для статики
16.03.09 18:17
Поздравляю. Как раз сегодня днем заходил на «куда все идут» и заметил афишу :)
16.03.09 19:40
М-м... А где видно, что там FastCGI?
Это вряд ли... Но отдельные компоненты будут.
Статика у нас тоже в каком-то смысле Pony Powered :-)
На КВИ, кстати, тоже парочка изменений заметна должна быть.
16.03.09 21:26
Несколько мелких признаков. Если lighttpd работает как прокси/балансировщик, он возвращает Server бэкенда. У вас же он идентичен фронтэнду. Одно из двух:
PS/Не сработал openid
16.03.09 23:17
оффтоп
Привет. Скажи, пожалуйста, о чем будет будет твой доклад на эксепшне в конце марта?
17.03.09 00:50
Я, к сожалению, не смогу приехать на этот Exception :-(. Конец марта у меня будет убийственно загружен.
17.03.09 12:17
Все не совсем так. Балансировщик у нас не lighttpd, а LSB. За ним действительно стоят lighttpd, которые можно считать фронтендами. В бэкендах — да, flup'овские процессы через FastCGI. Но с тем же успехом в бэкенде мог быть например Apache через HTTP. То, что lighttpd проставляет Server с проксируемых серверов, я не знал :-).
Насчет же "почему FastCGI"... А почему нет? Решение из коробки Джанго. Работает. На таких нагрузках, когда flup начинает тормозить, Афиша сейчас не работает (по большей части от того, что там серверов немало). Других нареканий к нему не было.
22.03.09 16:03
по этой причине у меня пропали все сохранённые любимые места?
22.03.09 17:07
В целом, да. Мы исходили из неверных предположений о том, как это хранилось раньше, и заметили уже после выкладки. Впрочем, кажется там ничего не пропало физически, и мы собираемся эти данные в итоге достать.
27.03.09 14:59
Поздравляю Яндекс с движением в правильном направлении )))
И конечно, Вас, Иван.
А вот наше руководство никак не хочет понимать, что Django экономит время и деньги... Эх...
2.04.09 02:08
А теперь по запросу выдается такое:
Кто это такой второй?
2.04.09 02:15
http://starship.python.net/~ewalstad/django_critter.html
22.05.09 16:13
А почему так много маленьких js файлов?
This page has 25 external Javascript scripts.
Ведь это не так уж и хорошо для front-end performance-a, даже плагин Yslow сильно ругается.
Это джанго так генерит или что-то ещё?
22.05.09 16:19
Не, Джанго к javascript'у отношения не имеет. Это то, до чего еще руки просто не дошли. Верстка нынешней afisha.yandex.ru — это имитация верстки предыдущего движка с реализацией некоторых новых фишек через jquery. Поэтому там сейчас много всего намешано.
22.05.09 16:58
Кстати, а Джанго лекго интегрируется с jquery, в частности интересует submit форм через Ajax и прочие Ajax запросы.
23.05.09 16:22
Это очень странный вопрос. Javascript'овый фреймворк с серверным никак не связан, поэтому с одной стороны ответ — "нет, они вообще не интегрируются", а с другой — "да, ничто не мешает их использовать".
В частности, для jquery есть плагин, который подменяет сабмит форм на ajax-запросы. Серверную часть, на чем бы она ни была написана, для этого менять никак не надо.
23.05.09 16:23
Ok, не совсем так. Серверная часть должна, конечно, уметь отдавать ответы в виде, который будет удобен javascript-приложению. Все средства для этого в Питоне есть.
26.05.09 12:19
Я просто недавно работал с JSF(Rich Faces), и он при генерации форм очень много своего javascript-a генерировал, который конфликтовал с другими библиотеками, и это создало нам много проблем.
Спасибо за ответы.