7015 читателей, 1303 поста
Администрация
Модераторы
Полезности для web-разработчиков.
Web-разработка whois
- индекс
- 184,85
Делаем правильную платформу или Как повторить Google
Введение
Сегодня я расскажу о проектировании высоко-нагруженных отказоустойчивых систем. Акцент будет поставлен практическую разработку и жареные факты, а не на сухую теорию. После прочтения вы не испугаетесь разработки сервиса с миллиардом пользователей, если у вас будет достаточное количество серверов. Тема весьма обширна, но я постараюсь быть кратким и лаконичным.Что мы хотим получить?
Начнем с тезисной постановки задачи и требований к системе, их немного.- Система должна автоматически разделять задачи между доступными ей серверами.
- Одновременный физический отказ (выключение) любых двух серверов никак не повлияет на целостность системы.
- Физический отказ любого оборудования не влечет за собой отказ целой системы.
- Включение нового сервера не требует никакой ручной настройки.
- Клиент может взаимодействовать с любым frontend-сервером равнозначно.
Два пути.
Существуют два пути. Первый — путь Microsoft — каждый сервис разрабатывается независимо, при этом каждая группа разработчиков делает собственные решения.Второй путь — путь Google — существует единая платформа и единая система, в которой живут приложения (поисковик, почтовик, группы, и т.д.).
Второй путь заметно выигрывает, поскольку при оптимизации любой части системы, улучшается работа сразу всех сервисов, и при разработке не нужно думать о том, как всё это будет в действительности работать. Первый же очень напоминает басню Крылова про лебедя, рака, и щуку.
Основные компоненты платформы.
На каждом сервере может быть запущен любой набор компонентов, количество серверов для каждого компонента определяется автоматически.- Хранилище данных. Состояние системы хранится только в нем.
- Кеш подсистема. Используется для временного хранения горячих данных в памяти.
- Сервис блокировок. Используется для предотвращения одновременного вызова последовательных процедур.
- Сервис приложений. В нем живут все конечные сервисы.
- Сервис взаимодействия с клиентом. Включает в себя Веб-сервер и DNS-сервер.
Хранилище данных.
Состояние системы хранится только в нем, никакие другие хранилища для приложений недоступны. Я выбираю MongoDB. Для того чтобы понять как к ней подойти, рекомендую ознакомиться с моей предыдущей статьей — MongoDB — варим хороший кофе, уделите кластеризации особое внимание. Также важен MapReduce.Кеш подсистема.
Необходима для снижения нагрузки на базу данных как на простой выборке объектов, так и на сложных выборках. Я выбираю memcached. Про то как подружить MongoDB и memcached сказано в статье о MongoDB, советую обратить внимание.Сервис блокировок.
Используется для предотвращения одновременного вызова последовательных процедур. Перед тем как выполнить процедуру, которая требует последовательности действий, приложение отправляет запрос сервису блокировок. В ответ оно получает либо согласие на выполнение, либо отказ. Я выбираю phpDaemon::LockServer. В случае падения одного узла, все ведомые им клиенты переключаются на другой узел.Сервис приложений.
В нем живут конечные сервисы. В качестве сервиса приложений может выступать OpenVZ. Приложения также могут быть асинхронными модулями phpDaemon. При разработке приложений нужно перекладывать в очередь любые тяжелые операции.Сервис взаимодействия с клиентом.
Включает в себя Веб-сервер (nginx), DNS-сервер (bind9) и firewall, через который идут запросы напрямую к приложениям. Отказоустойчивость и распределение нагрузки обеспечивается либо через DNS round-robin, либо по BGP с получением статуса AS.Хранение файлов.
Файлы хранятся в базе данных по методологии GridFS, существует реализация в виде FUSE-модуля.Пример использования. Описание работы сервиса Веб-поиска.
Данный сервис делится на несколько составляющих:1. Хранение информации о документах.
Для этого используем коллекцию documents с документами содержащими свойства url, host, type, size, mtime, atime, title, text, description, indexed и др. Шардинг полю по url.
2. Crawler'ы, сохраняющие содержимое страниц в базу.
Crawler запрашивает documents.find({host: ..., indexed: 0}), получая блокировку на этот host. Запрашивает каждый документ по сети и складывает его в базу, выставляя при этом indexed: 1.
3. Полнотекстовый поиск.
Для эффективного поиска по тексту нужен специальный механизм, который позволит быстро находить документы по заданным словам.
3.1. Приведение слова к «нормальной» форме. Слова могут записываться в разных словоформах, их все необходимо привести к одной нормальной форме, для этого нужно воспользоваться словарями (см. spelldump из Sphinx), и эвристическими стеммерами для слов отсутствующих в словарях.
3.2. Хранение индекса.
Существует два подхода.
Первый подход чаще используется в поисковых системах со сравнительно небольшим количеством поисковых запросов. Он подразумевает дробление единого поискового индекса на несколько, и параллелизм работы всех узлов при запросе. То есть, когда подается поисковый запрос, опрашиваются все узлы и их ответы склеиваются. В этом подходе для увеличения производительности добавляют зеркала узлов, и балансируют нагрузку между этими узлами-зеркалами. Но это весьма неэффективно, т.к. чем больше индекс, тем больше серверов требуется, при этом вовсе не учитывается популярность слов. Многие слова вообще никогда не будут запрошены.
Второй подход подразумевает распределение по словам, таким образом при запросе «hot girls», мы сначала узнаем какие сервера отвечают за каждое из этих слов, затем запрашиваем их, и склеиваем результаты. Сервера, которые не отвечают за эти слова мы вообще никак не нагружаем. Это дает огромный выигрыш в производительности.
Поэтому, мы выбираем второй вариант. При индексации документ разбивается на слова, они приводятся к нормальной форме, и для каждого слова вызывается words.upsert({word: ...,{"$push": {«docs»: ...}}})
3.3. Поиск.
При простом поиске «hot girls» подается запрос words.find({word: «hot»}) и words.find({word: «girl»), заметьте что «girl», а не «girls». Затем выявляются пересечения между ними и выполняется ранжирование.
Для эффективного ранжирования необходимо хранить расстояния между всеми парами слов в документе. Коллекция wordpairs с объектами вида {docid: ..., word1: «hot», word2: «girl», distance: 1}. Таким образом, можно быстро узнать в каких документах hot и girl расположены ближе всего.
Ссылки на используемое ПО.
- Nginx — Веб-сервер
- MongoDB — База данных
- phpDaemon — сервер включающий в себя сервер блокировок и другие модули
Заключение
В действительности, сделать такую систему вовсе не сложно. Тем более, я работаю над соответствующим фреймворком для простого создания подобных систем.Очень сложно уместить в статью такой огромный объем информации, но надеюсь мне удалось передать суть. Мне интересно какие аспекты покажутся вам особенно интересными, и я напишу о них в следующий раз.
Главное, поймите и осознайте, если вы сталкиваетесь с проблемой работая с более простым инструментом, а не используя вместо этого готовое решение, позволяющее абстрагироваться от таких проблем — это вовсе не означает, что проблема решена, скорее всего эта проблема решена настолько через одно место, что вы даже себе не представляете. Вообще, я с подозрением отношусь к продуктам, которые не исповедуют принцип Keep It Simple, Stupid. Когда я не могу проконтролировать что будет происходить на элементарном уровне, я понимаю что не удастся сделать всё правильно, поскольку всякие автоматически оптимизаторы (SQL-запросов, кода, и т.д.) очень часто ошибаются.
Например, в комментариях к одной из статей, человек спросил возможно ли в MongoDB выполнить аналог SQL-запроса «SELECT * FROM table ORDER BY RAND()*hosts LIMIT 5». Это конечно здорово и удобно, но с тем же успехом мы можем выбрать всю табличку, а затем в скрипте выбрать что нам нужно, это будет не намного сильнее тормозить, поскольку MySQL в этом случае выполняет RAND()*hosts для каждого ряда, сортирует все эти ряды в памяти, и отрезает 5 первых результатов. Само собой, чем больше табличка, тем больше тормоза. Так что надо всегда думать что в действительности происходит в результате ваших действий, иначе вы никогда не научитесь делать высоко-нагруженные системы.
Спасибо за внимание!
комментарии (298)
А по поводу Google — почитайте доступные Papers.
Конкретнее, с технической точки зрения ценность каждого второго предложения минимальна, а в целом весь пост выглядит крайне сумбурно, будто ведро с гайками на пол вывалил — нате, собирайте. Скачете с темы на тему, по разным уровням — тут же и про OpenVZ, и про SQL-select-ы.
>> Через какое-то время фреймворк опубликую
Я вас за язык не тянул, оповестите, пожалуйста, как появится.
А то, что его много — ничего страшного, говорю же.
Сразу вспомнил как мой преподаватель когда-то сказал: «Это как взять кучу дерьма, бросить на мозги и смотреть как оно впитается».
набирайся у него житейской мудрости, пока есть возможность
слишком много вопросов возникает.
Патчи можно использовать, но это спичечные оптимизации, а не архитектурные.
Фиксы можно использовать, но они относятся к спичечной оптимизации, а не к архитектуре. Если бы я затронул все спичечные оптимизации каждого из продуктов, надо было бы писать книгу, а не статью, которая призвана дать верное направление для размышления.
Можно конкретные примеры чем он удобнее к примеру python, perl, java
Вам не кажется что технология слишком тяжела для такой простой вещи? Чем хуже запуск сервиса от отдельного пользователя?
Можно конкретные примеры где «наоборот»?
один — автор этого чуда
значить я был не прав, кроме автора им пользется еще один чудак
Для всех фреймворков и buzzwords явы жизнь слишком коротка.
Если ты знаешь все тонкости явы, то конечно резона нет, но если в команде никто толком не видел эту яву, какой смысл её выбирать?
Прям из коробки есть только в 5.3. В остальных только расширениями.
А строить велосипеды на php не коротка? Вы вот посмотрите Spring.
А какой смысл выбирать php?
Ява: Map [String, Int ] m = new map [String, Int]; — сказывается уродливый Си++ подобный синтаксис
PHP: $m = array(); — тоже не очень
Руби: m = [] — самое то!
А уж если мы коснемся таких вещей, как замыкания, анонимные блоки кода, тут у Руби нет конкурентов, на нем просто писать приятней же. Плюс все объекты выглядят как объекты, например можно сделать print 'yes' if somestring.startsWith(); Плюс с массивами удобно работать, через методы типа map: new_array = old_array.map { |x| x*x; }
p.s Мануал по Руби читал давно, мог и напутать немного :)
Сказывается статическая типизация. Не путайте теплое с мягким.
Я уже спрашивал, но все же как с производительностью?
Перефразируя его скажу:
-Когда php по производительности догонит java вот тогда и приходите.
Насчет лаконичности это сильно зависит от того что вы там писать будете.
Другой пример, например мы хотим сделать объект БД для выполнения операций в рамках транзакции. Процедурный (уродливый) подход:
$db->startTransaction();
try {
$db-->doSomething(1);
$db-->doSomethingOther(2):
…
}
catch (Exception $e)
{
$db->rollback();
throw $e;
}
$db->commit();
А вот функциональный подход:
db->transaction { |db|
db->doSomething();
db->doSomethingElse();
…
}
Надо ли говорить, какой подход лучше? А если завтра вам понадобится поменять что-то в обработке исключений, к примеру, с первым подходом — вам придется лазать по всему коду. Дублирование кода — зло, а именно оно и и меет место в первом случае.
Также, очевидно, что читать и ориентироваться в лаконичном коде общем проще, да и на экран его помещается больше.
И ведь самое главное, ничто в общем-то не мешает сделать хороший синтаксис в Яве/PHP или даже старичке Си, но почему-то никто этим не занимается, значит ни кому не нужно?
Также, очевидно, что читать и ориентироваться в лаконичном коде общем проще, да и на экран его помещается больше.
> Насчет лаконичности это сильно зависит от того что вы там писать будете.
Не лукавьте, что ни пиши — все на Руби проще получается.
Кстати, что касается Явы — она у меня почему-то ассоциируется с огромными полотнами кода, страшными (в плане дизайна) западными корпоративными сайтами, нечитаемыми XML-конфигами, и дурацкими УРЛ типа /UnReadableServiceName.jsp?someparameter=1&someotherparameter=2. Или может сейчас что-то поменялось, но раньше было так.
Хотите совсем Java-вого Ruby — попробуйте Groovy, он практически так же лаконичен, как и subj.
Еще один вариант — Scala, но там другие правила, и риск заработать ФП головного мозга.
Да, посмотрю, хотя мне уже этап installation не нравится — как-то все заморочно, непортабельно, и криво:
> There is currently an issue where you cannot have spaces in the path where Groovy is installed under windows.
Позор. Не обрабатывать пробелы в именах файлов в 21 веке —это позор.
Есть еще какой-то Jruby, тоже гляну.
Но если вы будете писать на нем слишком лаконично, то никто из вашей команды не поймет, а через полгода и сами забудете, что написали.
На мой взгляд золотая середина лаконичности — Python — такст очень короткий, но читается идеально.
Лаконичность — это когда массив создается таой строкой: array = []; (в ср-и с другими языками), это описано в правилах языка, так что не представляю как об этом можн забыть.
echo "test... test... test..." | perl -e '$??s:;s:s;;$?::s;;=]=>%-{<-|}<&|`{;;y; -/:-@[-`{-};`-{/" -;;s;;$_;see'Пока не выполнишь не поймешь, что это такое. Да уже поздно будет.
Это, конечно, гипербола. Но близкий к такому код в вашем проекте — это кошмар для команды, потому что при смене разработчика, новому придется долго вникать.
Вот за это я не люблю перл, что так каждый пишет как хочет, в итоге — горы нечитаемого и трудноподдерживаемого говна.
Но для себя идеалом считаю Питон — программа читается легко и просто прямо как тект на английском.
if x is None: print "undefined"Особенно по сравнению с
Хотя хороший Java программист, к коим я себя никак отнести не могу, может найти много минусов в этой технологии. Но как-то там все логичнее, стройнее и красивее. И меньше былокодеров из-за более высокого уровня вхождения.
Старенькая цитата:
«Это одно из наиболее сбивающих с толку неправильных применений статистики. Только то, что высока вероятность попасть в C++ программиста, кинув камень в толпу, не означает более высокую вероятность его способности заменить Вашего C++ программиста, нежели поиск подходящей замены для Eiffel или Smalltalk программиста. Оттого, что Вы вынуждены просеять толпы идиотов, которые заявляют, что они знают C++, усилия, необходимые для поиска настоящей замены могут быть значительно меньше в случае Eiffel и Smalltalk. Кроме того, если вы можете найти хорошего программиста, высок шанс, что он сможет в достаточной мере выучить любой язык программирования, который вы используете, за время поиска хорошего C++ программиста. И, в общем случае, обучение по исходным текстам предыдущего программиста намного проще, чем изучение языка с нуля. „
А на PHP написать средненький сайт пытается и новичок со стажем один месяц. Когда я начинал писать на нем, у меня не возникало ощущения катастрофической нехватки знаний.
И проблема тут отнюдь не в том, что я вырос как разработчик.
Для «чайника» пхп дает простую возможность сделать
и не более. Мы же все понимаем, что от числа таких «сайтов» по миру php не страдает ну никак.
Вы бы видели какой недавно сайт сделал один сотрудник. Внешне — нормально, но внутри такой ужас… И он даже ни разу не задумался о том, что лучше отказаться от разработки, чем плодить кучу говна.
Понимаю, язык тут не причем. Но из-за легкости освоения, такие вот «кадры», уворовав в легкость разработки, оседают именно в нем.
Кстати, заметьте, проблему тупых разработчиков я обозначил только как одну из.
Хотя вру, работал пол года в конторе, которая занималась системами управления предприятиями на PHP. Я к сожалению ушел, т.к. к тому времени я совсем слез с PHP4 (они только новые системы делали на PHP5), да и ездить приходилось далеко. Но делали толково и очень серьёзно, некоторые Java/.NET девелоперы позавидовали бы тем системам, которые они создали. А их фреймворк хочется до сих пор повторить, да вот только сил не хватит :)
Вообще любой программист без ВО по компьютерным наукам в любой области — это кодер. У нас к примеру в стране официально по законам программистом является лицо имеющее ВО по компьютерным наукам или его получающее. Остальное кодеры — низкоквалифицированная профессия. И правильно, хотя конечно в реальности каждый второй лобзик себя считает программистом, а как начинаешь спрашивать базовые вещи — сдуваются, потому что дальше CMS'ок не лазили.
Проблема в том, что неважно для чего создавался язык. Главное — что получилось. А в случае с PHP получился слабый язык с кривой и нелогичной стандартной библиотекой.
Если уж на то пошло, изначально PHP — PersonalHomePage, но никак не язык для веба:)
Я просто не понимаю как можно писать динамично развивающиеся веб приложения на языке, который:
— Не умеет нормально работать с кодировками (и не надо мне рассказывать про iconv — уже намучился с разными нюансами)
— Не имеет нормальных средств для мета программирования
— < тут пошли мелочи, которые меня тоже достают >
Кроме него становится модным mercurial и bazaar. Становятся модными распределенные системы ревизии кода. И они становятся модным именно из-за своей распределенности.
А вы что Personal Home Page смотрели чем-то отличным от браузера? :)
Это все лечится костылями. Их там великое множество :)))
Ситуация с замыканиями тоже забавная. Они, конечно, в 5.3 появились, но до Javascript все равно не дотягивают.
Пхпешники, которые ничего кроме него не знают, меня, конечно, будут минусовать, ну и пусть. Не я первый, не я последний:)
code.google.com/p/php-aop/
www.phpclasses.org/browse/package/3215.html
только сначала скажите, ЗАЧЕМ это в веб-приложениях?
Что значит зачем это в ВЕБ-приложениях? А зачем это не в веб приложениях? А зачем нужны события в программах?
В конце-концов о том, что такое AOP, где может быть полезно и т.п. расскажет гугл. Есть куча хороший статей, авторы которых умеют излагать свои мысли куда лучше меня.
в каком месте Вы увидели модификацию исходников?
> В конце-концов о том, что такое AOP, где может быть полезно и т.п. расскажет гугл.
то есть с практической применимостью AOP лично Вы не знакомы. так и запишем: snob mode on ;-)
AOP в PHP возможно тремя вариантами (скажу спасибо, если кто дополнит):
— Получать все экземпляры классов через специфическую фактори, либо сделать какой-нибудь IoC контейнер. Серьезные проблемы, которые можно решить только соглашениями о кодировании, все равно остаются
— Использовать расширения, позволяющие модифицировать классы/функции. Нестабильно, не поддерживается байт-код кешерами, не распространено на хостингах
— Модификация исходников, склад модифицированных файлов в отдельную директорию и их подключение когда надо. Каждый раз проверять по времени изменения файла не надо ли перестроить эти самые исходники.
В этом случае мы избегаем минусов двух первых способов, но приобретаем либо зависимость от расширения tokenizer (не на всех хостингах есть), либо от своего парсера, то не является надежным.
есть пределы разумного
четвертый вариант
Полагаю, что так быстрее. ПРОФИТ!
А можно посмотреть примеры живых проектов, которые построены по такому принципу? Сколько в них задействовано разработчиков и какое у вас соотношение расходуемого времени на багфикс/импрувы/рефакторинг?
Мои живые проекты в интранете (информационная система для клиники, система бронирования для гостиницы), далеко не хайлоад, я единственный разработчик, но поверьте на слово, что там нет кучи повторяющегося кода или незавершенных транзакций с БД. Больше всего времени, пожалуй (точную статистику не веду), уходит на рефакторинг с целью избавления от повторяющегося кода, если под багфиксами понимать исправление явных ошибок, когда пользователи «генерируют» баг-репорты.
Не хочу сказать, что я супер-пупер гуру в PHP и Ruby, но PHP мой основной язык разработки еще с тех времен, когда PHP4 на российских хостингах днем с огнем не найти было. С Ruby знаком недавно, меня он поразил своей элегантностью, красотой и т. п., но вот повода применить его на практике не встречал. Скорее всего, человек активно использующий руби много лет и сможет написать на нем что-то быстрее, чем я, но уж точно на PHP я напишу это что-то быстрее, чем если буду писать на Ruby и мне довольно сложно будет объяснить заказчику, почему сроки разработки выросли. Не говоря о том, что гуру Ruby назовут мой код говнокодом :) потому что мало знать собственно язык, нужно знать его библиотеки и фреймворки, особенности трансляторов и т. д., и т. п., а главное их активно использовать, а я, пытаясь сократить сроки, буду писать в PHP-стиле, так что мой Ruby код можно будет перевести в PHP чуть ли не через поиск и замену в редакторе.
Я пытался сказать о том, что использование AOP может позволить прозрачно разделить описание бизнес-объектов и таких общих вещей как управление транзакциями. Поверьте, в крупных долгосрочных проектах, где занято несколько разработчиков, а бизнес-объекты хочется переиспользовать между проектами, это очень упрощает жизнь.
При этом, как правило, все настройки этого транзакционного управления собираются в одном файле. И не надо оглядываться на крики в духе «ааа, килобайты иксэмэля, мы все умрём», потому что современние IDE с подсказками и автокомплитом превращают его редактирование в простеишую задачу.
XML меня как раз не пугает, сам активно исьзую для конфигов и метаданных (хотя в последнем проекте использую YAML, т. к. его использует выбранный фреймворк)
Правильное решение должно выглядеть как-то так, имхо:
db.transaction { |db|
db.query1();
db.query2();
…
}
Неправда. PHP может работать как со строками *символов* в разных кодировках (функции mb_*()), так и со строками из байтов (без кодировки, функции типа str_*()). Использование вторых иногда может быть выгоднее с т.зр. производительноти.
Зачем вы использовали iconv() — искренне не понимаю. Вы строите сервис по перекодировке текста? Или вы этот кривой подход из Явы пытаетесь на PHP перенести?))
UTF-8 в PHP поддерживается замечательно.
> — Не имеет нормальных средств для мета программирования
Вам аннотаций не хватает что ли? А так ли они нужны?
> — < тут пошли мелочи, которые меня тоже достают >
Повторю свой предыдущий комментарий: по количеству лишних букв в коде: Ява многословней php, php многсловней Руби. Посмотрите на Руби — вообще расхочется другими языками пользоваться.
Вот есть у вас внутри программы строка. В какой она кодировке? В Java все строки будут в одной. А в PHP какой угодно. Отслеживать это — морока страшная.
Да и невозможность явно указать в какой кодировке происходит ввод информации — тоже минус.
Кстати, стандартные функции str_* заменяются на соответствующие из mbstring при нужных настройках PHP.
Про UTF-8. А символы порядка байтов тоже поддерживаются? А с регулярками как? Постоянно флаг указывать? :) Еще MySql до сравнительного недавнего времени с utf-8 толком работать не мог.
Да и не все функции из стандартной библиотеки заменяются на аналоги из расширения mbstring.
А я и нигде не писал про то, что Java — лаконичен. Это не так. Он логичнее, стройнее, хз как описать. Там нет приколов типа «0» == false.
Я, вполне возможно, поливал бы Java таким же кол-вом грязи, если бы знал Ruby. К сожалению, это не так.
В каждом инструменте я пытаюсь искать не только плюсы, но и минусы. В Java для меня такие уже есть. Но я слишком плохо ее знаю, чтобы их обсуждать. А вот PHP знаю хорошо. На тему его плюсов и минусов говорить готов.
Тоже самое с регулярками. Вообще нигде не использую флаг /u
С mySQL и utf-8 тоже никаких проблем нет, причем давненько.
С 2005 года перешел на utf-8 в проектах и еще не видел особых проблем с кодировками в PHP. Проблемы возникают с кодировками только у нубов, как показывает моя практика.
Про маркер порядка байтов в начале файла что же не возразили?
Проблемы у MySql с utf-8 были. Давно. Сейчас это выражается в том, что до сих пор используют win1251. Это, конечно, — не единственная причина, но свой небольшой вклад тоже внесла.
Я не говорю что все ужасно, просто не жить. Я говорю о том, что танцев с бубном не избежать. Со временем к ним привыкаешь, пишешь свои костыли и т.п., но это не значит, что теперь не надо трезво смотреть на вещи.
> Я не говорю что все ужасно, просто не жить. Я говорю о том, что танцев с бубном не избежать.
Подозреваю, что вы просто не очень разбираетесь в кодировках, не?
Безусловно, можно сделать обертку. Можно даже сделать ее так, чтобы читать все это через потоки(под этим и подразумевались танцы с бубном). Но это разве отменяет то, что в языке не заложена работа с кодировками?
Кстати, расскажите как вы обертки для чтения из сокетов или иных мест писать будете.
Так что пишите обертки и дальше, а я выучу другой язык, где таких проблем нет. А в качестве бонуса получу возможность рассматривать проблемы с разных сторон и искать более подходящие технологии для решения своих задач.
Про знания о кодировках и пытаться возражать ничего не буду.
Про него не отписал только потому, что не вижу с ним проблем — многие IDE и редакторы кода позволяют удалять эту маркировку.
Кроме того, если вы используете шаблонизатор — вы можете сами написать префетчинг с удалением BOM при чтении PHP-файла.
Решений с данной проблемой — достаточно много, причем оно один раз делается и забывается. «Взула и забула»
Вы же это описали чуть ли не проблемой, которая мешает вам каждый день программировать на PHP и хорошо спать.
Проблем у мускуля и пхп с utf-8 нет уже лет 5 как. Вы бы еще древнее проблему вспомнили. Например ту, что в пхп4 ООП каличное. Это будет аналогично.
Не увидел от вас достойной аргументации пока что, что ж такого плохого в пхп. Да, я видел много статей, где авторы распинались и плювались слюной по поводу пхп и указывая, чем язык Х лучше. При ближайшем рассмотрении оказывалось, что авторы уже давно не видели пхп в глаза и притензии у них к языку — 3-4 летней давности устаревания.
Вот если бы вы мне назвали то, что функции названы как попало в ядре — я бы с вами согласился, т.к. это действительно недостаток.
А вот эти плюшки по типу BOM или проблемы с юникодом (которые ну совсем не проблемы при ближайшем рассмотрении) — это не то, о чем стоит рассказывать. Юникод уже в 6.0 будет полноценный, а вот с функциями так пока ничего и не решили, что очень жаль.
Сколько времени у вас уйдет на отладку бага с этим? Вы ведь, похоже, даже не знали о том, что это есть такое.
У меня все IDE сохраняют файлы в UTF-8 без BOM. Но ведь коллективная разработка никуда не делась, верно?
2. Старые версии
Вы про эти проблемы расскажите создателям Битрикса, которые до сих пор php4 поддерживают. К счастью, в их число не вхожу (а то стыдно было бы)
К тому же стереотипы исчезают только со временем. Опять же вспоминаем про коллективную разработку.
3. Про кривую стандартную библиотеку было написано много комментариями выше
4. Кстати, о мета программирование
В той же Java оно отнюдь не ограничивается аннотациями. Чего только стоит модификация байт-кода в памяти.
AOP в веб разработке может быть очень удобно. Но PHP не дает никаких средств для реализации аспектов. А расширения, которые позволяют это, несовместимы с кешерами байт-кода.
5. О PHP6
Во-первых, выйдет он не скоро.
Во-вторых, еще дольше он не будет распространен на хостингах
В-третьих, я не рискну сразу на шестую версию переходить, чтобы потом баги на продакшене отлавливать.
— Проблемы важны не тогда, когда все нормально.
Проблемы важны, когда завтра сдача проекта, а у вас вылез баг неожиданный.
Проблемы важны, когда у вас денег много на сайте завязано. Каждая маленькая проблема важна будет.
Вот когда вы будете отлавливать в срочно порядке какую-нибудь неожиданность, тогда вспомните много раз создателей PHP. Мне хватило бреда, что «0» == false (строка с символом 0).
На BOM попадаются только новички в PHP. И поделом, пусть учатся.
2. Мне всеравно на недопроекты по типу Битрикса и еже с ними, которые поддерживают до сих пор 4, ущербную ветку PHP. Это их личные проблемы, а не разработчиков языка. Пусть поддерживают и выгребают новые и новые грабли.
Вы еще попросите Microsoft поддерживать IE4.0, т.к. отделение в Зулуссии до сих пор сайты верстает с поддержкой IE4.0
3. Согласен, но ведь это основная проблема, поэтому с нее и надо начинать, а не с бомов и кодировок.
А то, что пхп — слаботипизированный язык — вас тоже не смущает?
4. Думаю, что до тех пор, как АОР станет полезным и реально и реально удобным для применения на веб-проектах — создатели PHP что-то придумают. Пока в веб-разработке это не столь необходимо, чтобы мыслить аспектами.
5. Я к тому, что пхп6 решит проблемы, для которых вы сейчас стесняетесь применять нормальные решения. И это далеко не костыли.
Рисковать ставить или не ставить — дело каждого. Мне пока пхп6 не нужен, т.к. проблем с юникодом вообще не ощущаю, либо ощущаю мало и тут же решаю, т.к. чаще всего все решается через mb_* и прочие вещи.
>Мне хватило бреда, что «0» == false (строка с символом 0).
Чем же это бред? PHP слаботипизированный язык, поэтому следовало применять не ==, а ===. Ошибка на уровне детсада, не знаю, что вас тут удивило.
Видимо раздел про типы и их приведение в PHP — вы не осилили.
Это не неожиданность, а нежелание читать документацию к языку.
2. Придет заказчик и скажет: «плачу много бабла, чтобы вы поправили баги на моем сайте, написанном на php4». Вы ему откажите?
3. Об этом я написал выше, но поскольку возразить мне было нечего, то ярые фанаты PHP стали просто ставить минусы:):)
Я тоже не ощущая проблему с юникодом. Потому что на кривой PHP было написано расширение, немного его выпрямляющее — mbstring.
Но проблемы ощущаются в мелочах. И на этих самых мелочах идут потери времени.
Про «0» == false. Это такой же бред, как и разделение пространства имен через "\". Это банально непривычно.
Почему в юзабилити есть понятие user experience, а в языках программирования нету? Я в кружок программирования пошел с 7 класса. Успел поразвлекаться с кучей языков. Зачем создателям PHP было городить такие нюансы?
Почему обычно строку к логическому типу преобразовывают по длине (пустая строка — false и наоборот), а в PHP — по-другому?
2. Естественно откажу. Более того — я его отправлю к тому, кто писал ему этот проект. У меня хватает работы, чтобы еще копаться в гавнокоде заказчика, написанном непонятно кем и непонятно когда. Это его проблемы, а не мои. А деньги тут не главное. Главное получать удовольствие от своей работы, а не работать как раб только за деньги.
3. Что тут можно сказать. Троллей тут хватает. Я люблю PHP, я знаю его недостатки и достоинства. Это не повод пинать инакомыслящих.
Почему и зачем начали городить огороды — я не знаю, это вопрос не ко мне. PHP довольно старый язык, очень динамично развивавшийся. Язык, который был призван строить простые формы на сайте и из которого сделали ИНСТРУМЕНТ для создания веб-проектов и веб-приложений.
История языка прямо говорит о том, что у разработчиков не было достаточно времени на проектирование, им нужен был рынок, т.к. он фактически был пуст, в вебе не было на тот момент кроме перла ничего для веб-разработки (си++/с не берем во внимание, как и SSI, т.к. это извращения под веб).
Поэтому за быстрый взлет приходится расплачиваться несовершенностью архитектуры. Но я уверен, что многие вещи — будут исправлены. Впрочем это уже видно еще с миграции на пхп5.
Возможно авторам не хватало самим опыта. Причин может быть миллион.
Но это все равно не отменяет того факта, что PHP — отнюдь не лучший в своей области. На данный момент — точно.
Тем не менее, из-за его популярности, есть куча разработчиков, которая смогла осилить только PHP и считают что лучше ничего нет.
ЗЫ: Ни в коем случае не буду отрицать, для каких-то задач PHP подходит хорошо. И с точки зрения маркетинга он хорош — огромная распространенность на хостингах.
То, что он невидим и иногда вставляется редакторами по умолчанию. Сам помню, как в одном из php-файлов оказался BOM и из-за этого картинка, генерируемая в php, в одном браузере отображалась, а в другом — нет. Искать причину пришлось долго :)
— Код файлов php как раз не обязательно должен быть в utf-8. Пример — вордпресс
В utf-8 очевидно. Поскольку разрабатывемые мной сайты обычно поддерживают русский язык, использовать 8-битные кодировки не вижу смысла. А вообще, у меня есть параметр в конфиге charset (вдруг завтра война и срочно придется менять кодировку).
> А в PHP какой угодно. Отслеживать это — морока страшная.
Ну тут можно схитрить, сказав, наоброт, php дает разработчику свободу выбора, просто выбрать надо сразу и не пытаться писать часть исходников в cp1251, а другую — в CJK к примеру. Юзайте utf-8 и проблем не будет.
> Кстати, стандартные функции str_* заменяются на соответствующие из mbstring при нужных настройках PHP.
Что создает двусмысленность, глядя на исходники не поймешь, что за функция использована, это как раз дурацкий подход.
> Да и невозможность явно указать в какой кодировке происходит ввод информации — тоже минус.
Мы говорим про веб-приложения? Так есть такой HTTP-заголовок Content-Type, в нем указывается кодировка страницы. Формы с такой страницы отправляются в той же кодировке вроде. Если вы используете utf-8 — перекодировки не нужны.
В MySQL есть команда SET NAMES utf8; (именно так, utf-8 не прокатит).
> А символы порядка байтов тоже поддерживаются?
Не сталкивался (( Они просто передаются на вызод программы в неизменном виде, так что это зависит скорее от браузера.
> А с регулярками как? Постоянно флаг указывать? :)
Увы ((. Это все же влияет на производительность.
> Я, вполне возможно, поливал бы Java таким же кол-вом грязи, если бы знал Ruby. К сожалению, это не так.
Вот тут я написал с примерами, почему Руби удобнее в плане синтаксиса: habrahabr.ru/blogs/webdev/74589/?reply_to=2160114#comment_2159965, посмотрите пример с реализацией транзакций.
Про BOM (маркер порядка байтов) посмотрите дату этого бага: bugs.php.net/bug.php?id=22108
Мне понравился ваш пример с Ruby. Сейчас я хочу изучить какой-нибудь функциональный язык. На данный момент — Lisp.
Сталкивался сам, поверьте, злило, но сторого говоря. в utf-8 BOM не нужен — он сделан для отличия Big Endian от Low Endian UTF-16 (спасибо идиотам, которые придумали несколько юникодов сразу). Отключите у себя в редакторе вставку BOM и забудьте об этой проблеме.
> Про ввод информации ответил выше. Это может быть не только HTTP запрос, но и чтение файла, сокеты, shared memory и еще много всего.
Если вы используете разные кодировки для разынх компонент приложения — проблемы вам гарантированы в любом языке, хотя бы потому, что наборы символов в разных кодировках разные и не всегда можно без потерь перевести из одной в другую. Бросайте эту дурь, или пишите обертки для перекодировки, если не можете.
> Мне понравился ваш пример с Ruby. Сейчас я хочу изучить какой-нибудь функциональный язык. На данный момент — Lisp
Мда… ну если хотите писать скобками — удачи. имхо практической пользы от лиспа ноль.
Lisp'ом заинтересовался после прочтения www.nestor.minsk.by/sr/2003/07/30710.html вполне возможно, что он меня тоже бесить будет:)
А если захотите потом писать на Лиспе под JVM, то к вашему распоряжению Clojure.
У лиспа довольно хорошая область применения в области 3D разработок, он там очень силен. В частности куски кода, насколько я знаю, на лиспе есть в 3D Max и других средах.
— есть неплохие встраиваемые интерпретаторы;
— присутствует сборка мусора;
— простой синтаксис; пусть необычный, но с минимумом синтаксиса, поэтому учится влет.
Хз, из чего вы выросли, но язык для веба подразумевает вот что:
— краткое время жизни выполняющейся программы; эти уши тянутся еще из CGI, в модели «запустился-сделал-умер» (все, что вне, к php прикручено костылями) как следствие, в php не сильно заморачиваются на утечки памяти и прямоту архитектуры.
— небольшой размер самих программ (ибо нефиг шаблонизаторам страниц быть большими); как следствие, можно не сильно заботиться о мозге программера, который копает код — он не закипит.
— hot start: поправил, сохранил, вуаля. Все, что требует deployment'а, остается далеко позади, потому что стереотипичному php-style-программисту некогда разбираться, он пишет методом проб и ошибок.
Java для «большого» веба подходит больше исключительно благодаря стараниям Sun, JBoss и иже с ними, выпустившими нормальные контейнеры для web-приложений и прямыми руками собравшими человеческую архитектуру обработки web-запросов.
А это плохо? По моему, так скорее хорошо.
> — краткое время жизни выполняющейся программы; эти уши тянутся еще из CGI, в модели «запустился-сделал-умер» (все, что вне, к php прикручено костылями) как следствие, в php не сильно заморачиваются на утечки памяти и прямоту архитектуры.
А вот некоторые Ява-приложения, я слышал, по минуте запускаются. Это по-вашему более прямая архитектура. И не плетите, что мол долго запрягать — быстро ехать, просто Ява-разработчики тоже не такие гуру, каких пытаются из себя строить.
> — hot start: поправил, сохранил, вуаля
Поверите ли, так удобнее. А как должно быть по-вашему?
И да, в связи с кратким временем жизни, разработчикам php приходится изощряться, делать программу как можно оптимальнее, подключать только нужные модули, и т.д., а Явовцы пишут монстров, кое-как слепленных и считают это «прямой» архитектурой.
А еще у вас уродливый Xml, и плохо с шаблонизаторами, так ведь?))
Я не говорил, что это плохо, я говорил, что это — факт. И что из него есть следствие — очень короткую и простую программу можно написать абы как, задней ногой, лишь бы при заказчике не падало.
Плохо это или нет для пхп, я не знаю, я на пхп ни разу не писал :)
>>А вот некоторые Ява-приложения, я слышал, по минуте запускаются. Это по-вашему более прямая архитектура.…
Нет.
По моему, прямая архитектура никак не связана с временем запуска программы. Я же в предыдущем комменте написал, почему так важен hot-start для php — потому что де-факто средний разработчик на пхп забивает и на дебаггер, и на логгирование, а дефекты ищет прямо на продакшене.
>> просто Ява-разработчики тоже не такие гуру, каких пытаются из себя строить.
Ну и наброс, я даже комментировать не стану :)
>>в связи с кратким временем жизни, разработчикам php приходится изощряться, делать программу как можно оптимальнее
Именно. В ущерб читаемости, поддерживаемости, расширяемости. Проблема в этом, а не в коротком времени жизни as is.
>> А еще у вас уродливый Xml, и плохо с шаблонизаторами, так ведь?
Если вы про «нас», т.е. про меня, то у нас в .NET все прекрасно с и с xml, и с шаблонизаторами :) Полно разных на любой вкус — хоть Spark, хоть Asp.Net MVC, хоть Monorail, хоть NVelocity.
Среди людей, которые разрабатывают по за деньги (нормальные деньги) — наверно где-то одинаковое число. Тут вопрос только в адекватности работодателя — либо он платит человеку с низкими навыками, либо не платит.
Среди школоты, которая умеет любой язык изучать за 24 часа (и яву в том числе), быдлокодеров будет больше пхп, да. Но кому это мешает на самом то деле?
Когда у вас небольшая веб студия, то вам не нужен мега успешный и крутой лид. Вам нужны просто пара толковых программистов. Не обязательно опытных, но именно толковых. Они могут не знать языка на высоком уровне, но интуитивно чувствовать, что пишут лажу.
В будущем эти толковые программисты либо уйдут, либо войдут в долю в фирме.
Как искать таких среди PHP'шников я не знаю. И это проблема.
если Ява так хороша, почему РНР ее вытеснил в WEB программировании?
В качестве примера могу привести концерн DaimlerChrysler — они юзают и PHP в том числе. Достаточно крупная корпорация? :)
но есть задачи, где лучше и менее трудозатратней все-же далать на РНР
и вообще Программисту с большой буквы, выбор языка не должен быть камнем преткновения. Он должен одинаково хорошо знать и Яву и Си и разбираться в РНР. Может быть в чём-то лучше или в чём-то хуже… Я вот РНР программист, но вынужден патчить сишные модули и запускать явские классы.
нет
>Меня интересует где более подробно почитать о развитии, а то OpenVZ как-то стагнирует.
в списках рассылки
With the kernel 2.6.29, lxc is fully functional.
У меня 2.6.31 :]
Однако, PHP популярен и легко найти разработчика на нем. На Java значительно сложнее и дороже.
И для надежности он полностью файловерный — на аппаратном уровне.
Прежде чем охватывать все — давайте сделаем действительно надежное избыточное хранилище.
Если какие-то ноды умирают, то алгоритм ставит закачку на живых нодах.
При увеличении числа нод автоматически коррелируется распределение.
Звучит неплохо?
(долбаный хабр отправляет мои комменты куда попало)
это однопробельный отступ / отсутствие документации.
если бы отступы были нормальные, я обошёлся бы без документации и читал бы все по исходникам, но так их читать сложно. если бы документация была, то я бы вообще исходников не читал (или читал бы их намного меньше). опять же, можно всё переформатировать, но при попытке сделать svn up получу кучу проблем.
я не оставляю попытки все-таки разобраться в коде phpDaemon, потому что это действительно очень круто и полезно, но каждый раз натыкаюсь на пробелы.
посоветуйте, пожалуйста, кто-нибудь что-нибудь.
> путь Microsoft — каждый сервис разрабатывается независимо, при этом каждая группа разработчиков делает собственные решения
во первых вы наверно упускаете .NET как единую платформу для решений(тьма продуктов, лекций, технологий), во вторых разброс в бизнес решениях исторически обусловлен процессом получения этих решений. Покупается компания с продуктом, разработчиками и.т.д. и логично что они некоторое время будут «вливаться» в общий поток работая отстраненно.
Единая OS:
Windows
Единая платформа для приложений:
SharePoint Server
Enterprise Services
Единая БД:
SQL Server
Единая среда разработки:
Visual Studio
Где разрозненность? Может 2 Азура? Или лайф сервисы?
Java
Hadoop
HBase
Просто оставлю это здесь:
Архитектура Яндекс.Поиска
над этой фразой тихо плакал :D
Ну да. В итоге туча теории и ничего на практике. Перечислить софт и хард, который надо юзать якобы для высокопроизводительных приложений — это сильно да, это практика :-)
Ничего личного — но это такая же теория, от которой автор отнекивался в «Вступлении».
не понятно — почему в качестве хранилища данных взята MongoDB
чем оно лучше сторадж-сервера, который напрямую отдает контент
А надежность Ж два сервера включаем в пару: с шарда1 люем одновременно данные на шард2 и наоборот. В случае отказа одной из шард — автоматически данные будут браться со второй. ngx_upstreem рулит
с Сервером приложений вообще муть…
Единственное, с чем я согласен — Поиск, да, надо использовать специализированные средства, типа сфинксва, яндекс-машины или мутить какой-нибудь asearch.
и тянуть из них информацию по аяксу (если нужно)
… страницы должны отдаваться на ура, ни одного запроса с джоином!!!
если не согласны с моими утверждениями — то должно быть обоснование.
лично я Hiload занимаюсь более года и имею хоть не большой, но опыт в построении высоконагруженных систем.
все тяжелые процессы надо валить в бэдграунд — так делается во всех известных мне нагр системах
если требуется показывать прогресс, то не проблема — используем аджакс
так делается и при аплоадинге и при генерации кучи данных (система лотерейных билетов) и при обработки графических данных — автоматическое выделение фрейма при нарезке отсканированных отображений (в частности были комиксы) и еще много где… я указал то, где это приходилось использовать лично.
страницы должны отдаваться на ура, под этим понимается, что время генерации страницы должно быть минимальным. А для этого:
Если используется БД, то должен использоваться только запросы не сложнее SELECT * WHERE без всяких джоинов. Вся доп логика уходит в бэдграундовские процессы. Для этого существует технология «вечных скриптов», которые подготавливаютнужные нам данные и быстро их отдаем фронт-процессом.
куда уж яснее…
За публичное выражение нелюбви PHP, пусть и аргументированное, на хабре быстро улетаешь в минус. Так что минус поставить я не мог — карма отрицательная. Просто высказал предположение.
А, может, ваше высказывание где-то кому-то не понравилось и он решил пройтись минусами по вашим комментариям…
так я пропитый до мозга костей РНРник с десятилетним стажем. Все хочу соскочить с этого наркотика, да не получается. Чисто по экономическим причинам.
соскочить трудно по экономическим причинам,
сам понимаешь, сколько получает чел с 10 летним стажем. А на других языках — я буду новичек.
хотя мне было предложение на Сях равноправное РНР, но что-то я не поспешил с ним. Просто сейчас в очень интересном проекте, где кроме знания РНР много чего требуется от меня. Вот, по этому и трудно соскачить.
все — покидаю,
удачных проектов!!!
дисковое пространство — дешевое
экономия на месте — это экономия на времени отдачи
это простой, процессов, это доп сжираемая память, доп обращение к дисковому пространству в случае свопинга и тд и тп…
SELECT user FROM users u
LEFT JOIN cities c ON u.city=c.id
WHERE userId=123456
про полнотекстовый не было ни сказано ни слова…
любой поиск по полям.
«сфинкс, яндекс-энджине» — это серверы для полнотекстового поиска. я не понял зачем вы их тут привели.
много место оно не съест, а вот засвопить таблицу cityes он сможет. Ладно, будем надеяться, что у нас сервер достаточно по ресурсам мощный, но вместо одного буфера — будет выделено два — это доп память, потратится время на слияние. микросекунды… но когда речь идет о нагрузках — то боремся и за микросекунды.
а шлак плюсуют…
так-что удачи, набирайтесь разуму у тех, кто считает себя умнее.
а не кажется тебе, что это очень низко… и неужели есть такие люди среди программистов???
лично я минусов почти не ставлю.
Людей с низкой самооценкой, неспособных признать собственную неправоту, к сожалению, хватает.
Ну и пофиг. Единственное неудобство — писать раз в 5 минут. Зато обдумать мысль успеваешь:)
А статью, если захочу написать, я всегда найду через кого опубликовать.
лично я могу публиковаться и в журналах, не проблема.
у меня есть пять публикаций, где-то раз в год по одной (кроме этого года)
здесь как-то проще, вылизывать статьи не надо,
да и можно писать полу-статьи, т.е. укороченные статьи в свободном стиле.
php-fpm
вот тут пишут что разницы в нем и mod_php нет, а тут он себя сообще плохо проявил. А вот спецы по битриксу сравнивали и тоже там php-fpm уступает.
вот еще rt.ru
Сайты работают, да. Потому, что их поддерживают.
Качество сайта для меня не только дизайн и функционал, а еще и код системы, на которой он построен.
Что лучше, проще поддерживать — нормальный, наследуемый код, аккуратный, структурированный или перловку из кода, где сам черт ногу сломит?
Если не смотрели код Битрикса — то советую посмотреть на досуге. Для ловления лулзов.
З.Ы. Похоже задел нежные чувства кого-то из битриксоидов — минуснули карму. Да, большего я от вас, битриксоиды, не ожидал. Нечем крыть, кроме как нажать кнопочку слива кармы — это сильно ;)
Andrei Nigmatulin
Ну по большому счету автор все-таки прав — FastCGI не ускоряет php ;-)
Вы это имели ввиду?
желаю удачи, будут вопросы — в личку.
шардинг это про базы данных и uniqeu ключи насколько я понял, а не про http, причем тут nginx.
сторадж сервер — это сервер, на котором хранится контент: фото/видео/аудио/просто файлы
тип файловой системы — это вторично. Скорее всего ext3, но возможно есть что-то более быстрое. Это уже вопросы к админу. конкретную конфигурацию сервера устанавливает админ.
в данном контексте — шардинг про файлы, хотя БД тоже устроена по принципу шардинга. В своих статьях (кажется статья про ленту друзей) в комментах я рассказывал как устоен шардинг БД.
первый nginx — выступает как прокси
второй отдает контент, если вылетает один из стораджей, отдача автоматически проксируется на другой.
Вы единственный, кто заметил этот комментарий. В конце обсуждения я сделал вывод, что публика Хабра еще не готова к теме высоких нагрузок.
Вы чо :) шардинг в хайлоаде это распределение данных одной базы данных по разным инстансам — горизонтальное партицирование.
то что вы называете шардингом это проксирование :)
если вопрос про mongodb — то это к автору топика.
я делюсь информацией, как это делается в проектах деци-миллионниках.
шардинг — это распределение данных на разных физических носителях. распределение может быть по разным признакам. В данной теме БД я не затрагивал, а имелось ввиду файловое хранилище. Хочешь обсуждать шардинг БД, wellcome в соседний топик.
контент льется на два стораджа одновременно. Для надежности. А забирается с одного. В случае выхода одного из серверов — он забирается с другого. что тут непонятного!
ну, а теперь предложи схему, как забирать контент, если выйдет файловый-сервер?
failover в такой ситуации можно сделать, ну, например, зеркалированием блочного устройства по сети с DRDB и heartbeat.
она и так будет перегружена
ладно — я спать,
ничего не надо лишнего перекачивать.
информация заливается на один сервер и дублируется на второй. В случае отказа берется со второго, не увиличивая и не задействуя какие-то дополнительные сетевые схемы.
Наша задача, как можно быстрее отдать контент.
и вообще мне надоело с пеной у рта доказывать как надо делать. делайте — как считаете нужным.
на сервере1 и сервере2 вставил бы по блочному устройству.
вставил бы по две сетевые карты, соединил бы оба сервера друг с другом и с сетью прокси сервера. запись была бы с прокси на мастер-сервер drbd, одновременно с записью на него мастер синхронно бы сливал файл по второму интерфейсу на второй сервер и к моменту аплоада на один сервер файл был бы уже на двух. тем самым нагрузка на коммутатор со стороны прокси сервера была бы в два раза ниже.
а вы?
только счет стороджей на десятки.
Ну допустим линейное чтение с одного накопителя 240 мбит (опустим vfs), ну допустим у вас гигабитный канал, 4 чтения файла забьют вам весь канал.
компоненты можно менять
человек сам думает а не только копирует
Бурное обсуждение — уже показатель не плохого материала, хотя я много с чем в этой статье не согласен… и не для Хайлоада она
С практической точки зрения представленный хлам никуда не годится. Я имею ввиду что каждый программный модуль в отдельности конечно вещь стоящая, но вот всё вместе оставляет ощущение… хмм… некоторого бардака.
По идее нужно плясать от конкретной задачи, представить архитектуру, выяснить требования к каждому модулю, а уж затем рассуждать что они будут из себя представлять. А у вас — подход микрософт, подход гугл… Да грамотный архитектор вообще об этом не думает, какие у кого подходы! Он аргументы в пользу того или иного решения проверяет, proof of concepts мастерит. А эти решения ему опыт его даёт.
Универсальную архитектуру при жёстких требованиях не сделать — то там косяк вылезет, то там модуль отвалится. Видеть надо всю систему глобально, не упуская конечную цель.
И ещё, реально работающая высоконагруженная система, решающая определённую задачу, она выверяется годами. Речь конечно не идёт о случае когда вы копируете чью-то исходную задачу — тогда конечно её решение кто-то за вас уже выверил.
Мне доводилось участвовать в разработке подобных комплексов. Чутьё приходит с годами серьёзного опыта, причём от задачи к задаче решения могут быть разные в силу специфики контекста.
Эх, тема настолько обширная, что тут можно рассказывать очень долго…
Желаю вам дело это не забрасывать, ведь именно там, где мы решаем трудные задачи, мы обогащаем свой опыт бесценными знаниями.
но нет опыта — это минус
автор эксперементирует — это плюс
но не правильно трактует результаты экспериментов — это минус
нельзя статью назвать плохой, он и удачной тоже.
статья вызвала резонанс — это плюс
Думаю, такое может утверждать лишь человек со значительно большим опытом, чем мой.
Ты, молодец и я тебя за твои стремления и знания уважаю, ты знаешь это.
читай мои комментарии внимательнее, я тебя не ругаю, а даю конструктивную оценку. Ну, грешу, сострил в одном посту, про кол-во использований в проектах PHPDaemon.
как я тебе говорил пару лет назад, тебе надо поработать годик в сильной команде хорошего проета. У тебя есть все потенциальные возможности.
Да, тема похоже для многих тут наболевшая :)
Правда споры в основном идут не о том — большинство отстаивают то, что лучше знают. Чёрт побери, столько шуму, а по сути — так несерьёзно…
Вот начиная с задач в десятки тысяч транзакций в секунду вся эта шелуха что в статье описана и осыпается, начинается реальный technical challenge.
Вы ошибаетесь и рассуждаете слишком поверхностно (только не обижайтесь пожалуйста)
Проблемы негров шерифа не волнуют) Он CTO, ему виднее :-)
бессмысленные религиозные войны…
еще не хватало взять наболевшую тему Win против *nix
спрос на тему есть, открытой информации мало. Кто может ее написать — сильно занят. Вот и появляется куча шарлотанских статей.
Начинаешь раскрывать профф. секреты высоких нагрузок- тебя минусуют. Не готова публика к теме Высоких нагрузок, не готова.
да, мемкеш имеет болезнь на запись — это заметно. Боремся расширением, у нас под него отдельный сервер. И еще мы его пропатчили, так что каждое последующее чтение прлонгирует жизнь элемента кеша на тоже время. Смешно, но это всего три строчки кода. Может когда-нибудь напишу статью про это.
а сразу сетов на порядок меньше стало.
А статья вам моя про мемкеш смотрю не понравилась, еще один минус появился…
мемкешбд вроде не имеет ttl для записей, как можно его увеличивать?
я минусы вообще никогда не ставлю.
Технический директор, программист, системный архитектор.
* Опыт — 10 лет.
* Профессионально занимаюсь проектированием и разработкой компьютерных систем, защитой информации, аудитом IT-безопасности, кластеризацией, оптимизацией.
* Могу писать и пишу на всем — от спектрума до Java 6.0.
* Блестяще владею следующими языками программирования, список в порядке излюбленности:
Java (SE), PHP (начинал с PHP 3 в 1999), PCRE (на уровне дьявола), C(++), ECMAscript (JS), VB(S), Brainfuck.
* Положительный опыт руководства командой.
* Огромный положительный опыт работы (изнутри и снаружи) с:
Linux, FreeBSD, MySQL (InnoDB), nginx, Memcached, MemcacheDB, Subversion, Wowza Media Server.
* Знаком с:
Ruby, PostreSQL, MS SQL, Oracle, TDB, Perl, AS 3.
* Неплохо знаком с квантовой информатикой (пока на эмуляторе), создаю нейронные сети, занимаюсь прикладной криптографией.
* Проектирую и создаю сети распределенных вычислений, пишу под них программы, автор IMemcacheClient и IMapReduce.
* Профессионально занимаюсь аудитом IT-безопасности, автор ряда статей.
* В WEB-разработках в качестве frontend чаще всего использую собственную платформу, написанную на PHP (куда, в том числе, входят Quicky, SmartDB, fastgeoip).
* Имею большой опыт разработки систем под нагрузкой и с повышенной отказоустойчивостью и защиты от DDoS-атак (на всех уровнях).
* Опыт разработки и поддержки meta-поисковых машин, различных платежных систем и др.
* Опыт настройки и администрирования серверов, проектирования High-Availability кластерных систем хранения информации и распределенных вычислений.
* Опыт работы с огромными High-Availability БД, поисковыми механизмами (Sphinx, Lucene, ...).
* Опыт работы с медиа (опыт разработки с нуля медийного хостинга (tube) и сервиса социального онлайн-телевидения)
* Опыт в интеграции с WebMoney, E-Gold, Rupay, PayPal, Liberty, Pecunix, E-Bullion и др. платежными системами, опыт разработки сервера мерчанта.
* Автор множества opensource-проектов, из последних:
phpFastCGI, IMemcacheClient-PHP, Quicky, SmartDB, mctop, phpthread, cutebind
* Хорошее знание сетевых протоколов как высокого уровня (HTTP, FTP, DNS, BGP, OSCAR v9...), так и низкого (IP, TCP, UDP).
но для его возраста — это вполне отличные результаты
P.S. Да, я могу сходу писать на любом языке, глянув примеры. Однажды за выходные выучил Java на достаточном уровне чтобы писать threaded-приложение с ConcurrentHashmap'ами, которое применялось в виде модуля к медиа-серверу. Но опять же, какое отношение это имеет к делу?
Для настоящего программиста язык роли не играет, это лишь примитивный инструмент через который программист выражает свои мысли.
Кому нужен человек, изгалающий мысли одинаково на разных языках?
> Для настоящего программиста язык роли не играет, это лишь примитивный инструмент через который программист выражает свои мысли.
Настоящие Программисты вообще не пользуются редактором, потому что программируют бренное железо сразу в опкоде, воткнув мизинец в USB-порт.
Никогда не посещала мысль, откуда взялось такое разнообразие языков программирования и почему продолжают появляться новые языки?
P.S. Тему, если интересно, предлагаю перенести в личку, дабы не разбрасывать тут фекалии на вентилятор.
У тебя одни успехи, у меня другие
У тебя одни интересы, у меня другие.
это несоизмеримо
А вообще, товарищ, попрошу не оффтопить, тема тут никак не обсуждение моей скромной персоны. И уж тем более не копипаст чужих резюме, могли бы просто дать ссылку.
то я знаю его лично…
что-что а мозга у автора работает…
и выступал он на HiLoad не плохо
но есть у него и свои недостатки,
о которых неэтично говорить вслух
второе обдумываю
как его пропустили на Ни++, я даже не представляю,
с темой HL я знаком не по наслышке и мои замечания можно найти в этом посте, хотя я как любитель флуда, немного пофлудил и здесь. Полночь, Луна в зените… а почему и не по размышлять…
Но, что я замечу — автор, действительно оригинал (я имею ввиду в жизни ).
Автор просто написал список инструментов, которые ему нравиться использовать, не более. Ещё, в добивку, в описании использовал сокращения с которыми многие попросту не знакомы, как я могу понять что такое «DNS round-robin, либо по BGP с получением статуса AS.»? Эта фраза должна прибавить мне знаний данной тематики?
кто незнаком — пусть пропустят, кому надо — возьмет на заметку )
Сам факт того, что автор чем-то владеет пользы хабранароду не даст.
пусть автор форкает еще проект — мы за, но второй гугл (русский?) строить… не подымутся
Sapienti sat. Человек, которому это надо — в любом случае пойдет и прочтёт о каждом пункте не один десяток экран, тот которому это не надо, не будет тратить своё хабравремя на чтение таких вещей и пойдет дальше.
Сколько бы статей вы ни прочли, сколько бы лекций не выслушали… Вы ничего не добьетесь, пока не научитесь думать и исследовать САМОСТОЯТЕЛЬНО.
Подумайте как сделать хорошо, напишите, поймете что вы придумали на самом деле плохо. Повторите сначала раз 5-10 учитывая свои ошибки, и вот тогда вы сделаете что-то по-настоящему хорошее. Со временем конечно количество итераций будет уменьшаться, однако не бойтесь ошибаться и начинать с чистого листа.
Плохой учитель преподносит истину, хороший учит ее находить. — А. Дистервег
Не бери все близко к сердцу,
меня тоже вчера статью про то как я искал где и почему падает мемкеш раскритиковали и наминусовали. А я так, попутно методики поиска еще и раскрыл протокл мемкеш и как его использовать для отладки. Многи не способны увидеть в статье главное.
ну а остальное — оффтоп
Вот какой смысл мне знать что вы использовали? Если я захочу узнать о том как построить гугл я прочту о архитектуре гугла.
это был соседний топик
там были вы или не вы?
Хотелось бы подробнее об этом узнать. Скажем загрузил пользователь аватарку (а может вам надо хранить favicon для поисковика). Файл этот надо будет раздавать через nginx. Как?