Это модный баззворд, означающий системы, которые хранят нафиг никому не нужные данные, но зато обладают впечатляющей масштабируемостью.

Ты каждую неделю будешь это вопрос задавать?

масштабируемость хоть на лету или только возможность?

вчера задал, перечитал, сам не понял и удалил. вас это смущает?

Нет, меня это удивляет.

Щито такое «хоть на лету» - горячее добавление узлов в систему?

горячее добавление как-то автоматизированное на основании текущей и прогнозируемой нагрузки

Горячее добавление есть (естественно), фраза про нагрузку глубокомысленна до бессмысленности %)

ну какая-то система, которая мониторит нагрузку и говорит «тут добавить места, там мозгов, а там база скоро колом встанет». хз как ее описать правильно

ну какая-то система, которая мониторит нагрузку и говорит «тут добавить места, там мозгов, а там база скоро колом встанет»

Думаю, система мониторинга нагрузки есть в любом серьезном проекте - это как бы само собой разумеется. Но пойнт хайлоада - не в системе мониторинга, которая говорит, где затыкать дыры, а в стиле проектирования.

Еще добавлю вопрос

Вот мне часто встречается (чаще всего в вакансиях) словосочетание «требуется опыт с highload в PHP». Я вот задумываюсь, а что это за зверь, и не является ли «оксюморон» вторым именем этого зверя?

Скастую на всякий KRoN73, он что-то наверняка знает.

не является ли «оксюморон» вторым именем этого зверя?

нет :). Даже на пыхе можно писать большие сайты, фэйсбук (я знаю про hiphop, оно появилось позже) и вконтактик это доказали.

Ну хорошо, а оно как-то систематизируется, или «отдавать статику энджайниксом» уже типа хайлоад среди пыхкодеров? А распределение нагрузки, фейловер и горячая замена — через такую-то мать и соединенные соплями костыли и подпорки?

Даже на пыхе можно писать большие сайты, фэйсбук

Ты бы видел, какое оно глюкавистое было в 2008 году, когда у них хипхопа не было.

Ну и к тому же, у него и сейчас то и дело отваливаются части CDN — то CSS приехать не может, то картинки, то одни и те же нотификации внезапно объявляются непрочитанными.

Скастую на всякий KRoN73, он что-то наверняка знает.

Да всё просто. Высоконагруженные сайты не часто лимитируются не ЯП. А в случае динамики — чаще БД, в случае статики — собственно, http-сервером.

Когда я утыкался в производительность (ещё на стареньких P3-500 и Xeon-1800), я просто переводил всё на статику. Даже форумные топики были статическими html-страницами. И тут уже пофиг, чем они генерятся. Сейчас проблем нагрузки нет, так что я не заморачиваюсь задачей связей объектов для автоматических сбросов кешей при модификациях. На будущее, если вылезет, то ещё подумаю, то ли переводить нагруженные куски на PlayFramefork с реализацией BORS на Java (всё равно сейчас 90% частей сайтов пишу на YAML/HAML), то ли включить статику :)

А распределение нагрузки, фейловер и горячая замена

Эти вещи связаны с ЯП точно также, как и «отдача статики энжиниксом» :)

Что мешает использовать на PHP распределение нагрузки, фейловер и горячую замену?

задумайся о facebook

уже типа хайлоад среди пыхкодеров?

eaccelerator забыл.

А распределение нагрузки, фейловер и горячая замена — через такую-то мать и соединенные соплями костыли и подпорки?

Это высший пилотаж, я живьём не видел таких проектов вообще. Везде оно работало только в воображении архитектора, реально в случае сбоя много ручной работы требовалось. Хотя щас, наверно, сделать проще т.к. всякие сетевые фс появились, БД сильно улучшились в плане репликации и бэкапов итп.

Делал как-то через CARP и slony дублирующие сервера, но в случае сбоя всё равно обратное переключение руками и разгребание проблем потому что для скорости всё работало асинхронно со всеми вытекающими. В таком случае или смириться с некоторой некосистентностью данных, или жить с каким-нить kemari.

В общем, прозрачный failover должен быть частью архитектуры а не внешняя примочка типа ping+cron+rsync.

какое оно глюкавистое было в 2008 году

то и дело отваливаются части CDN

во всём пых виноват, да :)

Java

растёшь :)

что такое этот ваш highload?

Это «хайскалабилити хайаваилабилити энтерпрайз продакшн платформ»

растёшь :)

Или откатываюсь. Я с Java много работал в 2006..2007 гг :)

во всём пых виноват, да :)

Конечно, у него же нормального FastCGI отродясь не было. И сейчас нет. То, что есть — это, простите меня, фекальная масса. В нормальном FastCGI инициализация вынесена вне цикла обработки запросов, а в случае с пыхом она внутри. Если это не фекальная масса, то я затрудняюсь насчет определения фекальной массы как таковой.

Что мешает использовать на PHP распределение нагрузки, фейловер и горячую замену?

Вопрос не в том, можно ли. Вопрос в том, как и какой ценой. Можно и из буханки бородинского троллейбус замутить.

eaccelerator забыл.

Он утонул. (ц) XCache — все равно костыль. Persistent connections в MySQL — костыль. Почему у перла нет никакого JIT, никакого opcode cache, а он на сходных задачах делает пхп как тузик грелку?

Вопрос в том, как и какой ценой

Да. Но это задача не языковая. Или у нас той же репликацией БД языки стали заниматься? o_O

Скажем так — имеется в виду базовая платформа, среда, если угодно. ПХП же не язык в вакууме, там инфраструктурка имеется.

Почему у перла нет никакого JIT, никакого opcode cache, а он на сходных задачах делает пхп как тузик грелку?

Только на числодробилках или cgi (не fast-cgi). Когда-то я на PHP перелез с Perl'а из-за того, что на практической работе с MySQL PHP со своими mysql_* выдавал страницы в 9(!) раз быстрее, чем Perl DBI. Насколько я знаю, с тех пор ситуация сильно не менялась. Иначе бы об этом сильно трубили всюду. Хотя, может, и не расслышал из-за того, что Perl нынче мёртв лишь чуть менее, чем полностью :)

ПХП же не язык в вакууме, там инфраструктурка имеется.

Именно, что язык в вакууме. Как и Python или Ruby. Если нужно сравнивать инфраструктуру, то нужно сравнивать конкретные решения. Тут, правда, не советчик. У меня пока задачи распределения нагрузки не возникало, хотя под свои задачи прикидывал — реализуется легко. При чём в рамках фреймворка даже бэкенд не обязан поддерживать репликацию, репликацию легко обеспечит фреймворк. Но пока только теория, на практике современного железа хватает под мои задачи.

Только на числодробилках

Кстати, был не прав. На числодробилках, похоже, PHP несколько поправился:

http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=php&am...

Хотя на это, на самом деле, пофиг. Всё равно, числодробилки ни на PHP, ни на Perl делать смысла нет.

Только на числодробилках или cgi (не fast-cgi).

Именно, у перла FastCGI правильный. И рвет PHP. :)

Именно, что язык в вакууме. Как и Python или Ruby.

Давай учтем, что в свободном плавании hiphop вне фейсбука не наблюдается особо, а кроме него, у пхп аж одна реализация. Так что язык от среды хрен оторвешь. Говорим PHP — подразумеваем чудище с php.net.

Именно, у перла FastCGI правильный. И рвет PHP. :)

См. что такое этот ваш highload? (комментарий) первый абзац.

Ну и что такое этот ваш highload? (комментарий) — второе предложение :)

а кроме него, у пхп аж одна реализация

Как и одна реализация Perl'а, «почти одна» реализация у Python и Ruby. И?

Так что язык от среды хрен оторвешь

Речь не о среде/реализации же шла, а об инфраструктуре. Читай — фреймворках и готовых решениях.

XCache — все равно костыль.

да это то же самое что eaccelerator. Если не ошибаюсь, форк.

Почему у перла нет никакого JIT

так и у пыха нет

никакого opcode cache

есть, скрипты загружаются апачом только один раз, потом всё в памяти. А вот пых каждый раз всё с диска забирает.

А по скорости php, perl и python примерно одинаковы.

А по скорости php, perl и python примерно одинаковы.

Python значительно быстрее. Но в реальных web-приложениях на реальных фреймворках разница практически нивелируется.

Python значительно быстрее

таки разогнали :).

Да, вроде, с тех пор, как я им заинтересовался, а было это что-то около 2.4, уже был много быстрее.

Вот Jython, всё то время, пока с ним работал, был страшным тормозом. Потом, вроде, говорили, что разогнали, но я уже не застал :)

Вот что реально разогнали — это Ruby. Когда-то был страшным тормозом, сливающим вчистую PHP, а сегодня он по скорости жёсткий конкурент Python'а.

требуется опыт с highload в PHP

Можешь читать это как «умение писать оптимизированный PHP код». Суть хайлоада очень проста: посмотри на свой код, а затем представь, что он должен обслуживать 95% запросов пользователей за 20-80 миллисекунд (чем меньше, тем лучше) при том, что таких запросов летит от нескольких тысяч (диванный хайлоад) до сотен тысяч в секунду.

Потом вернись к реалиям, где типичный похапешный быдлокод наполнен кривыми запросами, хреновыми структурами данных, и в лучшем случае укладывается в десятые доли секунды при двух одновременно работающих пользователях.

Вот, собственно, что означает этот баззворд: умение писать код и поддерживать архитектуру, которая быстро обслуживает «от нескольких десятков тысяч» одновременно работающих пользователй.

Python значительно быстрее

Неверное утверждение. Кое-где педон быстрее, кое где — медленнее.

Неверное утверждение. Кое-где педон быстрее, кое где — медленнее.

_Как правило_ — заметно быстрее. На объектах — _значительно_ быстрее. Так точнее.

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

Connected to 8.8.8.8...
C: /static/images/linux.png
S: <binary data>
Connection closed by remote server.

Connected to 8.8.4.4...
C: /static/images/debian-logo.png;/static/images/gentoo-logo.png;/static/images/lor-new.png
S: <size1><image1><size2><image2><size3><image3>
Connection closed by remote server.

Или оно того не стоит, а http-серверы для статики загружаются не на разборе HTTP-заголовков/тела?

Ну так HTTP, считай, так и работает.
<connect to linux.org.ru>
GET /tango/img/money-logo.png
<connect to linux.org.ru>
POST /path/to/recipient
<data>
...

Специально проверил: http://img59.imageshack.us/img59/9717/screencqw.png. Вижу, конечно, что ~1/3 - это заголовки от домашней прокси, но остальные 2/3 никто не отменял. А еще и сервер, к тому же, должен ожидать во входном потоке еще больше заголовков, возможно, ошибочных, так что оверхед мне кажется ну уж совсем неприличным. Собственно по этому поводу я и полез спрашивать про этот придуманный недопротокол с парсером и обработчиком ошибок на один экран :)

а объектах — _значительно_ быстрее

Почто тебе в вебе объекты? Для модных маппингов на базы данных чтоли? Это дальше personal home pages или ынтерпрайза не нужно не применяется, ибо ТОРМОЗА

Почто тебе в вебе объекты?

В Вебе — не обязательно. Но в XXI веке — обязательно. Не люблю делать ненужную рутинную работу.

ибо ТОРМОЗА

Не знаю, пока не видел.

Не мне ответ, похоже :) А жаль.