Кликнулось слишком быстро. В смысле, MySQL тоже умеет писать свои функции? Мы просто с ним не работаем. Но показатель производительности на постгресе впечатляет — функция, написанная на C пашет быстрее функции, написанной на PL/PgSQL, думаю, на порядки. Во всяком случае сортировка по индексу на основе самопальной C-шной функции (и, соответственно — по самопальному типу данных) работает примерно с той же скоростью, что и сортировка по встроенным типам данных, что есть хорошо. Правда, там куча как теперь уже малознакомой специфики (конструкций языка) — так изаведомо малознакомой специфики — как Postgresql
Было бы интересно посмотреть примеры модулей к PHP и базам данных и т.д — т.е. к существующим приложениям общего назначения. А то книжки по юниховому C++, как правило, рассказывают про визуальные среды — типа «как нам сделать Visual Studio под Линух». Да и примеры кода там ужасающие приводятся. И, в самом деле, лучше начинать с азов — я последний раз (не считая микроопыта месячной давности, давшегося, надо признать, большой кровью) писал на C лет 20 назад, а пресловутый микроопыт показал, что С довольно сильно изменился.
офигительно минуснули. Я имел в виду, что ту же капчу, написанную на PHP и работающую через GD можно спокойно сваять на C, отчего она будет работать быстрее.
Я не предлагал делать капчу в виде анимированного квадратика)))
P.S. Нет —, конечно, догадывался, что к GD не обязательно лезть через PHP. Просто оно как-то всегда проходило как-то мимо.
а не лучше лы было бы в таком разе вместо картинки флешак зафигачить? по тому же принципу. Конечно, зависит от фона, но если удастся сделать фон целиком во флеше — весить будет меньше и тянуться адекватно
1876 км от МКАД метро, пожалуй, не поможет.))) А пробки-то там откуда?))). В качестве «чутка» запчастей я храню то, что может вылететь и повлиять на работоспособность серверов. RAID стоимостью 1К в них не входит. Я такое на свои сервера вообще не ставлю. Старая привычка еще со времен возни с FreeBSD — в начале 2000-х подобные игрушки без вазелина на нее, как правило, не вставали.
Впрочем, если учесть разницу в стоимости самосбора и готового решения вендора — можно было бы, пожалуй, и хранить.
В рабочее время лучше на метро)))). Быстрее и почти без пробок. У меня на такой случай всегда лежит чутка запчастей дома (обходится примерно как стоимость пресловутого HP Care Pack). Впрочем — холивар на эту тему страивать не стоит — каждый экономит свои нервы так, как им (нервам, в смысле) удобнее.
Экстрим)))). У нас, в этом плане ситуация чуть проще — наш провайдер держит дата-центр в закрытом институте, и доступ к серверам в нерабочее время мягко говоря затруднен (конечно, я слышал, бывает и по-другому, но на московском рынке, к сожалению, ситуация типичная). Ну а в рабочее… дайте подумать… наверное, на замену памяти ушло бы часа полтора (включая дорогу до провайдера).
А зачем покупать сервера за 4 — 10 тысяч (я ни в коей мере не против оптимизации кода — наоборот). Но приличный сервер можно собрать тысячи за 2 (TWIN Core Quadх8Гбх320Гб в корпусе 1 U на платформе Intel), а тысяч за 5 можно уже собрать совсем монстра на SuperMicro TWIN.
P.S. Для людей, считающих, что сервер может быть собран только вендором, отвечающим за его качество, можно прикинуть добавочную стоимость от вендора (порядка 200%) и попробовать пересчитать ее на классические гарантии при сборке из запчастей (3 года — платформа=хорошей гарантии вендора, + 1 год — винты (суммарно не более 10% стоимости сервера) — если они будут лететь регулярно на следующий день после окончания гарантии — даст удорожание сборки на 20% — соответственно от прибыли вендора остается 180%), + 1 год — процессоры (20% стоимости сервера — если будут ломаться как винты, от прибыли вендора останется 140%), ну и память (как правило с пожизненной гарантией).
Конечно, собрать сервер — дело несколько более сложное, чем тачку домой, но, мне кажется, трата 2 — 3 дней на изучение материала, в данном случае, себя окупит.
А на новом сервере провести оптимизацию и тонкий тюнинг софта.
Интерфейс — на 5. Сама CMS (по первому впечатлению) — на 3-. И чего-то долго оно все подгружает. Над серверной частью поработайте. При грамотном построении кода окошко должно грузиться за доли секунды.
P.S. А может и над клиентской тоже.
P.P.S. ЗАкрыл вкладку файрфокса, потом попробовал открыть админку и получил «Warning: Smarty error: unable to read resource: „/desktop.tpl“ in /home/ibpro/public_html/smarty/Smarty.class.php on line 1092». Все-таки есть ощущение, что серверная частьчудит
А самое забавное — что сей апокалиптический сценарий поведения AOL принадлежит вроде как (судя по Теминому ЖЖ) Эльдару Муртазину. То есть психуют все-таки где-то чуть поближе, чем в Америке.
Было бы интересно провести тест при параболическом распределении узлов. т.е. вначале детей немного, потом количество резко увеличивается, а потом падает. IMHO, такое распределение больше приближено к жизни. Впрочем, полагаю, реально картина если и изменится, то не сильно.
А еще есть пара полезных операций — как то смена порядка следования детей внутри родительского узла (и лучше смена на произвольное количество позиций), а также копирование ветки (то есть добавление в середину дерева не узла, но ветви произвольного размера).
P.S. алгоритмы AL можно серьезно оптимизировать, добавив level и havechild (тот же самый уровень и признак наличия потомков) Происходит некоторое замедление добавления (принудительный апдейт или апдейт с проверкой), удаления и апдейта (на отдельных операциях — ровно на проверку а остались ли еще дети).
Так когда мы пытались сформировать дерево в nested sets, оно там никогда выше 1300 — 1400 узлов не дорастало))). мы скрипт отрубали.
делать границы с шагом, разумеется, можно, но не универсально — а мы пытались выработать некий универсальный подход, который позволил бы нам работать с большими деревьями быстро и с минимальными затратами.
А предметная область удручающе банальна — web-дизайн. Мы используем дерево в качестве универсального хранилища данных для сайта/группы сайтов. Там, не то, чтобы постоянно, но регулярно возникают задачи по копированию/перемещению/вставке в середину иногда одиночных узлов, а иногда весьма ветвистых веток. Фактически, любое обновление сайта означает вставку одиночного узла, а если на сайте болтается какой-нить мультитоварный каталог посерьезнее — возникает необходимость делать вставки участков иерархии. Nested Sets для решения наших задач не подошло совсем — слишком много в общем случае объектов на update. Причем количество этих объектов, вообще говоря, не контролируется.
Это как с рекурсией. Рекурсия по дереву сверху вниз есть абсолютное зло, поскольку, находясь наверху, мы не можем оценить количество рекурсивных вызовов. С другой строны, рекурсия снизу вверх, при определенных обстоятельствах, вполне допустима — поскольку количество вызовов ограничено вложенностью начального узла.
Еще раз. Есть дерево. ветвистое. глубокое. Суммарно — около 100000 узлов, вложенность что-то порядка 15. Начинаем формировать дерево Nested Sets из имеющегося Adjacency List. Поскольку работа с деревом предполагает, в том числе, копирование, перемещение веток, а также вставку узлов в середину, данные перед вставкой берутся в сравнительно произвольном порядке. До 500 узлов тормозов не заметно, после начинаются нарастающие тормоза. Начиная с 700 узлов среднее время выполнения вставки составляет около минуты на узел. После вставки 1300 узлов процесс остановлен.
Опыт проводился на тестовом сервере (Athlon 2500XP) и на PostgreSQL 8.3. Для чистоты эксперимента был проведен раза три, с вариациями по порядку выборки исходного дерева. Существенных изменений в производительности не замечалось.
Железка, когда еще была боевым сервером, держала сайты суммарной посещаемостью около 800000 хитов в сутки + почту к этим сайтам и испытывала проблемы разве что от кривоватых рук тогдашнего админа (сволочь ротацию логов как-то совсем криво делал).
А с самими запросами ничего не делалось. просто вставлялся узел, потом апдейтилось дерево.
потому что дерево и граф — все-таки немного разны понятия. Графы в WEB (а иначе откуда берется мускуль, в отличие от деревьев, не юзаются). Для графа нужна совсем другая структура данных. по собственному опыту — мерзотная.
Неплохая статья. Хотя местами расходится с фактами.
Хотя данные в таком виде уже более приспособлены сразу для вывода, но, как видите, главный недостаток такого подхода — необходимо достоверно знать количество уровней вложенности в вашей иерархии, кроме того, чем больше иерархия, тем больше JOIN'ов — тем ниже производительность.
(про JOIN и про Adjacency List).
Там проблема скорее в ограничении количества таблиц, которые можно JOINуть. У Котерова был эксперимент — на ограничении 32 таблицы запрос по выборке дерева большого и сильно вложенного (уровень вложенности 8) с 32 JOINами работает (можно найти на dklab — проверял месяца три назад) примерно с той же скоростью, что и 8 JOINов (примерно с той же скоростью в данном случае означает флуктуации между запросами на уровне флуктуации скорости выполнения одного запроса)
NESTED SETS, если его попробовать (у меня ощущение, что про него пишут просто потому что он упоминается в любой статье про деревья) реально применить, годится либо для деревьев, которые никогда не будут меняться и данные в которые никогда не будут дописываться в середину дерева, либо для «кустиков» до 800 узлов суммарно. Потому как при больших (ударение на первую букву) размерах, вставка узла в середину начинает занимать около МИНУТЫ на не самом отстойном железе и внятно сконфигуренной базой. У Nested Sets имеется один единственный замечательный + — вывод дерева в правильном порядке.
Materialized Path в классическом виде хранит информацию о предках, а не порядок вывода по отношению к предкам. Если скомбинировать классический Materialized Path с Materialized Path, приведенным в этом примере, да еще написать правильную функцию сравнения того Materialized Path, в котором порядок вывода хранится, получится вполне внятное дерево, выводимое единым запросом в правильном порядке. Правда, остаются проблемы с переносом веток, но, проблемы эти решаются (т.е. перенос ветки с вложенностью 5 и 7000 потомков занимает, в среднем, около 2 секунд совместной работы PostgreSQL+PHP).
А в целом, хотелось бы в таких статьях (это вроде как уже не первая) побольше конкретики собственного опыта (я вырастил дерево такой-то вышины и такой-то ширины, и храню я это дерево там-то и там-то потому-тои потому-то)
Если обо всем — однозначно дешево. Не скажу, что демпинг, но можно безболезненно для себя поднимать цены раза в 3 как минимум. При необходимости, поднаймете приличного внешнего дизайнера. Зато удовольствие от работы, за которую получал условный рубль, а продал за условные три возрастает даже не в геометрической прогрессии.
А когда работаешь с удовольствием, и результат получается лучше. И в следующий раз можно за него уже четыре условных рубля брать…
Может быть и укладывается. Просто если мы говорим о работе хорошего дизайнера (я в данном случае хорошим дизайнером называю не хорошего с точки зрения работы — т.е. четко и в срок делающего то, что ему сказано — а хорошего с точки зрения готового результата — креативщика типа), его гайдлайны будут напрягать. На такой проект, IMHO, правильно давать минимум 2 дизайн-концепции от приличных людей с зарплатой от 2500/мес, напряг от дополнительного внешнего контроля (этих самых гайдлайнов в данном случае) заставит этих приличных людей пахать над концептами дольше, чем если бы этого контроля не было — скорее всего получится в идеале недели 2 — 3 — почти цельный месяц. Получается затрат только на концепции уже больше 4000. Минимум 1000 на доработку. ну и 100% наткрутки на их зарплату.
Так что, мне видится 10000 — это минимум.
Впрочем, всегда случаются варианты лучше идеального. Да и гайдлайны тоже бывают разные — у тасиса, например, они весьма либеральные, а у колгейта позволяют (или позволяли года три назад) делать официальный сайт только в Шотландии и только в виде точной копии американского. БМВшных гайдов не видел, посему точно сказать не могу. Так что, возможно все.
Просто если идеальный вариант не случится (а дизайн — штука весьма непредсказуемая), норма прибыли упадет. Рухнет даже. А это уже плохо для бизнеса.
Можно на эту тему почитать обсуждения предыдущих рейтингов здесь и на РОЕМе.
Я не предлагал делать капчу в виде анимированного квадратика)))
P.S. Нет —, конечно, догадывался, что к GD не обязательно лезть через PHP. Просто оно как-то всегда проходило как-то мимо.
Оченно даже полезно.
Впрочем, если учесть разницу в стоимости самосбора и готового решения вендора — можно было бы, пожалуй, и хранить.
P.S. Для людей, считающих, что сервер может быть собран только вендором, отвечающим за его качество, можно прикинуть добавочную стоимость от вендора (порядка 200%) и попробовать пересчитать ее на классические гарантии при сборке из запчастей (3 года — платформа=хорошей гарантии вендора, + 1 год — винты (суммарно не более 10% стоимости сервера) — если они будут лететь регулярно на следующий день после окончания гарантии — даст удорожание сборки на 20% — соответственно от прибыли вендора остается 180%), + 1 год — процессоры (20% стоимости сервера — если будут ломаться как винты, от прибыли вендора останется 140%), ну и память (как правило с пожизненной гарантией).
Конечно, собрать сервер — дело несколько более сложное, чем тачку домой, но, мне кажется, трата 2 — 3 дней на изучение материала, в данном случае, себя окупит.
А на новом сервере провести оптимизацию и тонкий тюнинг софта.
P.S. А может и над клиентской тоже.
P.P.S. ЗАкрыл вкладку файрфокса, потом попробовал открыть админку и получил «Warning: Smarty error: unable to read resource: „/desktop.tpl“ in /home/ibpro/public_html/smarty/Smarty.class.php on line 1092». Все-таки есть ощущение, что серверная частьчудит
А еще есть пара полезных операций — как то смена порядка следования детей внутри родительского узла (и лучше смена на произвольное количество позиций), а также копирование ветки (то есть добавление в середину дерева не узла, но ветви произвольного размера).
P.S. алгоритмы AL можно серьезно оптимизировать, добавив level и havechild (тот же самый уровень и признак наличия потомков) Происходит некоторое замедление добавления (принудительный апдейт или апдейт с проверкой), удаления и апдейта (на отдельных операциях — ровно на проверку а остались ли еще дети).
делать границы с шагом, разумеется, можно, но не универсально — а мы пытались выработать некий универсальный подход, который позволил бы нам работать с большими деревьями быстро и с минимальными затратами.
А предметная область удручающе банальна — web-дизайн. Мы используем дерево в качестве универсального хранилища данных для сайта/группы сайтов. Там, не то, чтобы постоянно, но регулярно возникают задачи по копированию/перемещению/вставке в середину иногда одиночных узлов, а иногда весьма ветвистых веток. Фактически, любое обновление сайта означает вставку одиночного узла, а если на сайте болтается какой-нить мультитоварный каталог посерьезнее — возникает необходимость делать вставки участков иерархии. Nested Sets для решения наших задач не подошло совсем — слишком много в общем случае объектов на update. Причем количество этих объектов, вообще говоря, не контролируется.
Это как с рекурсией. Рекурсия по дереву сверху вниз есть абсолютное зло, поскольку, находясь наверху, мы не можем оценить количество рекурсивных вызовов. С другой строны, рекурсия снизу вверх, при определенных обстоятельствах, вполне допустима — поскольку количество вызовов ограничено вложенностью начального узла.
Опыт проводился на тестовом сервере (Athlon 2500XP) и на PostgreSQL 8.3. Для чистоты эксперимента был проведен раза три, с вариациями по порядку выборки исходного дерева. Существенных изменений в производительности не замечалось.
Железка, когда еще была боевым сервером, держала сайты суммарной посещаемостью около 800000 хитов в сутки + почту к этим сайтам и испытывала проблемы разве что от кривоватых рук тогдашнего админа (сволочь ротацию логов как-то совсем криво делал).
А с самими запросами ничего не делалось. просто вставлялся узел, потом апдейтилось дерево.
(про JOIN и про Adjacency List).
Там проблема скорее в ограничении количества таблиц, которые можно JOINуть. У Котерова был эксперимент — на ограничении 32 таблицы запрос по выборке дерева большого и сильно вложенного (уровень вложенности 8) с 32 JOINами работает (можно найти на dklab — проверял месяца три назад) примерно с той же скоростью, что и 8 JOINов (примерно с той же скоростью в данном случае означает флуктуации между запросами на уровне флуктуации скорости выполнения одного запроса)
NESTED SETS, если его попробовать (у меня ощущение, что про него пишут просто потому что он упоминается в любой статье про деревья) реально применить, годится либо для деревьев, которые никогда не будут меняться и данные в которые никогда не будут дописываться в середину дерева, либо для «кустиков» до 800 узлов суммарно. Потому как при больших (ударение на первую букву) размерах, вставка узла в середину начинает занимать около МИНУТЫ на не самом отстойном железе и внятно сконфигуренной базой. У Nested Sets имеется один единственный замечательный + — вывод дерева в правильном порядке.
Materialized Path в классическом виде хранит информацию о предках, а не порядок вывода по отношению к предкам. Если скомбинировать классический Materialized Path с Materialized Path, приведенным в этом примере, да еще написать правильную функцию сравнения того Materialized Path, в котором порядок вывода хранится, получится вполне внятное дерево, выводимое единым запросом в правильном порядке. Правда, остаются проблемы с переносом веток, но, проблемы эти решаются (т.е. перенос ветки с вложенностью 5 и 7000 потомков занимает, в среднем, около 2 секунд совместной работы PostgreSQL+PHP).
А в целом, хотелось бы в таких статьях (это вроде как уже не первая) побольше конкретики собственного опыта (я вырастил дерево такой-то вышины и такой-то ширины, и храню я это дерево там-то и там-то потому-тои потому-то)
А когда работаешь с удовольствием, и результат получается лучше. И в следующий раз можно за него уже четыре условных рубля брать…
Так что, мне видится 10000 — это минимум.
Впрочем, всегда случаются варианты лучше идеального. Да и гайдлайны тоже бывают разные — у тасиса, например, они весьма либеральные, а у колгейта позволяют (или позволяли года три назад) делать официальный сайт только в Шотландии и только в виде точной копии американского. БМВшных гайдов не видел, посему точно сказать не могу. Так что, возможно все.
Просто если идеальный вариант не случится (а дизайн — штука весьма непредсказуемая), норма прибыли упадет. Рухнет даже. А это уже плохо для бизнеса.