Здравствуйте, Нахлобуч, Вы писали:
Н>Здравствуйте, Дм.Григорьев, Вы писали:
ДГ>>Прежде всего, по причине невозможности кеширования объектов между HTTP-запросами, и по причине отсутствия реализации Hibernate для PHP, все запросы приходится оптимизировать вручную.
Н>Во-первых, кэширование можно и самому (если уж очень припрет) сделать.
Как? Что-то мне подсказывает, что ты имеешь в виду совершенно другое кеширование, и вообще читаешь мои посты через строчку.
ДГ>>Раскладывать вручную оптимизированный запрос в "правильную" объектную модель — занятие для больших оригиналов. Нужны очень веские причины, чтобы заниматься подобным извращением.
Н>Частично соглашусь. Вручную гидрировать "правильную" объектную модель и правда занятие не из приятных. Однако же в случае, когда классы Domain Model представляют собой просто DTO на стероидах (чего достаточно для простых приложений), делать это, по-моему, не так и сложно.
Гы. "Просто DTO"? "Не так уж и сложно"? Тебе никогда, видать, не приходилось поднимать несколько объектов одним SQL-запросом из нескольких сджойненных таблиц (чтобы не плодить отдельныё SQL-запрос на каждую фигню) — именно это я и имел в виду.
ДГ>>Далее. Все результаты SQL-запросов где-то используются, верно? Так случилось, что большинство результатов просто отдаётся клиенту (исключения — какие-то проверки перед модификацией базы). А теперь смотри: результаты используются в XSLT-преобразовании.
Н>Сам с таким подходом не сталкивался, но сдается мне, что при более-менее сложной верстке этот XSLT будет феерически объемным.
Неправильно тебе сдаётся.
Н>Если я правильно понял логику, то MenuManager получается очень перегруженным и у него образуется слишком большая зона ответственности — и получение объектов из БД, и разруливание вопросов с полномочиями. А сие не есть правильно .
Ага, вот и я о чём.
Н>ты очень сильно завязываешься на имена столбцов — они у тебя есть и в тексте запроса, и во всяких индексаторах, и в XSLT. По мне, так это дюже нехорошо.
Гы, а ты очень сильно завяжешься на имена полей объектов. Те же яйца, только в профиль, да ещё и коду будет в десять раз больше.
Н>Если же использовать какие-никакие классы-DTO, то в общем случае получается, что для разных типов пользователей (админы, простые смертные и т.д.) требуются разные DTO с разным набором полей. Получаем экспоненциальный рост количества классов.
Н>Получается, что для упрощения своей же жизни все вопросы отображения и сокрытия той или иной информации должны быть решены на уровне View'а (если говорми про MVP/MVC). Но тогда выходит, что либо придется использовать какой-нибудь шаблонизатор (из оных для PHP знаю только Smarty), либо делать все XSLT-преобразования на сервере.
Вах, как всё стало просто!
Засунь свой Smarty куда подальше. Сложную вёрстку (и редизайн) на нём сделать гораздо труднее, чем на XSLT. И кстати, ООП-модель предметной области к Smarty прикручивается также криво, как и к XSLT. PHP вообще под ООП не заточен.
И ещё раз повторяю для тупых — XSLT на клиент выносится из соображений производительности. При этом код серверной части менятся минимально (к вопросу о лёгкости сопровождения).
Н>Разницы между 0.05 секунды и 0.5 секунды (такой оверхед надо еще постараться получить) пользователь вряд ли заметит.
Оверхед в 10 раз тебе не существенен? Вот на этом месте спор можно смело заканчивать. При хорошей нагрузке твои ООП-творения благополучно ляжут.
Н>Ну неужто в интернет-магазинах и службах знакомств ты текст запроса тоже в коде писал?
Да. И я считаю это вполне оправданным. Поскольку на мои аргументы ты не обращаешь внимания, доказывать тебе что-либо дальше никакого смысла не вижу.
ДГ>>И я готов поспорить, что твои ООП-заморочки (так называемые "упрощения") приведут только к усложнению кода и существенному снижению его эффективности.
Н>Эффективность -- это в смысле быстродействие? А как же преждевременная оптимизация -- корень всех зол?
Повторяю для тупых — у меня было достаточно проектов, чтобы наэкспериментироваться и выработать подход. Я не с бухты-барахты стал писать так, как пишу. Некоторые сайты мне пришлось переписывать с "правильных" моделей на работающие и держащие нагрузку. А ты либо обыкновенный теоретик без опыта, либо не писал на PHP ничего серьёзного (т.е. опять же без опыта).
Кстати, а как большое железо решает задачу: Клиенты не должны узнать что в одном из датацентров выключили свет/порвали сеть/итп...
Как эту задачу решить кластером я представляю. А вот как с этим справится большое железо нет.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Ну вот и хамство началось.
ДГ>Как? Что-то мне подсказывает, что ты имеешь в виду совершенно другое кеширование, и вообще читаешь мои посты через строчку.
Я имею в виду кэширование, во-первых, результатов отработки PHP (сгенерированных страниц), а во-вторых, бизнес-объекты -- есть же в PHP какие-то решения (на память только memcached приходит).
ДГ>Гы. "Просто DTO"? "Не так уж и сложно"? Тебе никогда, видать, не приходилось поднимать несколько объектов одним SQL-запросом из нескольких сджойненных таблиц (чтобы не плодить отдельныё SQL-запрос на каждую фигню) — именно это я и имел в виду.
Приходилось. Не вижу, где тут проблема. Разработать стиль именования столбцов и выдирать данные. Получается эдакий легковесный ORM/RSM.
ДГ>Неправильно тебе сдаётся.
Хорошо.
ДГ>Гы, а ты очень сильно завяжешься на имена полей объектов. Те же яйца, только в профиль, да ещё и коду будет в десять раз больше.
Испорчен я компилируемыми языками со строгой типизацией, знаешь ли
ДГ>Вах, как всё стало просто!
ДГ>Засунь свой Smarty куда подальше. Сложную вёрстку (и редизайн) на нём сделать гораздо труднее, чем на XSLT. И кстати, ООП-модель предметной области к Smarty прикручивается также криво, как и к XSLT. PHP вообще под ООП не заточен.
Засовывать ничего никуда не буду. Показал бы пример такого XSLT, чтоб было с чем сравнить.
ДГ>И ещё раз повторяю для тупых — XSLT на клиент выносится из соображений производительности. При этом код серверной части менятся минимально (к вопросу о лёгкости сопровождения).
Обороты сбавь. Код состояния HTTP 304 знаком?
ДГ>Оверхед в 10 раз тебе не существенен? Вот на этом месте спор можно смело заканчивать. При хорошей нагрузке твои ООП-творения благополучно ляжут.
Я не говорил, что несущественен. Ты его получи сначала, оверхед такой.
ДГ>Повторяю для тупых — у меня было достаточно проектов, чтобы наэкспериментироваться и выработать подход. Я не с бухты-барахты стал писать так, как пишу. Некоторые сайты мне пришлось переписывать с "правильных" моделей на работающие и держащие нагрузку. А ты либо обыкновенный теоретик без опыта, либо не писал на PHP ничего серьёзного (т.е. опять же без опыта).
Я в самом начале дискуссии написал, что PHP не знаю. Пишу на ASP.NET.
К тому же, у меня вызывает большие сомнения необходимость переписывания сайтов с "правильных моделей на работаюшие" -- тебе профайлер сказал, что производительность теряется именно из-за той самой "правильной" архитектуры?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
HgLab: Mercurial Server and Repository Management for Windows
Общаться с упёртыми теоретиками — гиблое дело. Надоело. Предлагаю пари, скажем на 15000 WMR (или 500 WMZ; в общем, сколько тебе не жалко ).
1. Берём какую-нибудь простенькую задачу (скажем, простенький форум без наворотов) и делаем её оба. Ты на объектной модели, я на своих модулях. На PHP5, разумеется.
2. Сравниваем объём получившегося кода в килобайтах (пишем без комментариев), понятность кода (не экономим на именах переменных и методов), выполняем нагрузочное тестирование. В качестве жюри для оценики субъективных вещей (типа понятности кода) предлагаю привлечь членов RSDN Team (надеюсь, не откажутся).
3. Затем придумываем простенькую задачу на расширение фукнциональности (добавление какой-либо одной фичи) и реализуем её.
4. Сравниваем объем изменений в коде (можно, например, банально сравнить объём diff-ов svn) и прочие характеристики (жду предложений).
Поскольку ты доказываешь, что ООП хорош в любой ситуации, то для опровержения необходимо привести хотя бы один пример задачи, с которой мой подход справляется лучше. Поэтому постановку исходной задачи утверждаю я (обсуждаемо вместе). Поскольку мне необходимо доказать, что мой подход справляется с поддержкой и расширяемостью, задачу на расширение функциональности выбираешь ты (уже после того, как мы оба заканчили первую часть).
Чтобы никто из нас не попытался съехать с базара, предлагаю с самого начала скидывать ставки на WM-кошелёк жюри, и установить максимальный срок выполнения заданий, по истечении которого не представивший решение считается проигравшим. Поскольку делать мы будем в свободное от работы время, срок должен быть достаточно большим. Скажем, пара месяцев на исходное задание (там работы на неделю вечерами; такой большой срок — это чтобы не было никаких отмазок типа "вот, срочная работа привалила").
Здравствуйте, Нахлобуч, Вы писали:
ДГ>>Гы, а ты очень сильно завяжешься на имена полей объектов. Те же яйца, только в профиль, да ещё и коду будет в десять раз больше. Н>Испорчен я компилируемыми языками со строгой типизацией, знаешь ли Н>Я в самом начале дискуссии написал, что PHP не знаю. Пишу на ASP.NET.
Вот-вот. Ты, парень, несколько не в теме. Я уже устал повторять, что предлагаю решения для совершенно определённого класс задач и совершенно определённых средств разработки. А ты мне тут теорию впариваешь.
ДГ>>Засунь свой Smarty куда подальше. Сложную вёрстку (и редизайн) на нём сделать гораздо труднее, чем на XSLT. И кстати, ООП-модель предметной области к Smarty прикручивается также криво, как и к XSLT. PHP вообще под ООП не заточен. Н>Засовывать ничего никуда не буду. Показал бы пример такого XSLT, чтоб было с чем сравнить.
Приведи код на Smarty, я приведу аналогичный на XSLT.
ДГ>>И ещё раз повторяю для тупых — XSLT на клиент выносится из соображений производительности. При этом код серверной части менятся минимально (к вопросу о лёгкости сопровождения). Н>Обороты сбавь. Код состояния HTTP 304 знаком?
На форумах, где контент постоянно меняется, от этого кода толку мало. И вынос XSLT на клиента добавляет скорости независимо от кеша страниц. Вполне устоявшаяся практика, между прочим.
ДГ>>Оверхед в 10 раз тебе не существенен? Вот на этом месте спор можно смело заканчивать. При хорошей нагрузке твои ООП-творения благополучно ляжут. Н>Я не говорил, что несущественен. Ты его получи сначала, оверхед такой.
Это были твои слова — с 0.05 сек до 0.5 сек.
Н>К тому же, у меня вызывает большие сомнения необходимость переписывания сайтов с "правильных моделей на работаюшие" -- тебе профайлер сказал, что производительность теряется именно из-за той самой "правильной" архитектуры?
Я замерял суммарное время выполнения скриптов. Самопальное профилирование, в общем.
Здравствуйте, Дм.Григорьев, Вы писали:
ДГ>Общаться с упёртыми теоретиками — гиблое дело. Надоело. Предлагаю пари, скажем на 15000 WMR (или 500 WMZ; в общем, сколько тебе не жалко ).
Да лехко 6000 WMR...
ДГ>1. Берём какую-нибудь простенькую задачу (скажем, простенький форум без наворотов) и делаем её оба. Ты на объектной модели, я на своих модулях. На PHP5, разумеется.
...и ASP.NET 2.0 с моей стороны (с использованием всяких библиотек, разумеется)
ДГ>2. Сравниваем объём получившегося кода в килобайтах (пишем без комментариев),
Что мы друг другу докажем килобайтами кода? Что тебе или мне писать меньше пришлось? И что с того?
И пишу я с комментариями всегда.
ДГ>понятность кода (не экономим на именах переменных и методов),
Ну это, предположим, можно кое-как, но оценить.
ДГ>4. Сравниваем объем изменений в коде (можно, например, банально сравнить объём diff-ов svn) и прочие характеристики (жду предложений).
Опять же -- что докажем-то?
ДГ>Поскольку ты доказываешь, что ООП хорош в любой ситуации, то для опровержения необходимо привести хотя бы один пример задачи, с которой мой подход справляется лучше.
Критерии оценки "лучше" какие? Уж не объем ли кода?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
HgLab: Mercurial Server and Repository Management for Windows
Здравствуйте, Дм.Григорьев, Вы писали:
ДГ>Вот-вот. Ты, парень, несколько не в теме. Я уже устал повторять, что предлагаю решения для совершенно определённого класс задач и совершенно определённых средств разработки. А ты мне тут теорию впариваешь.
Я "впариваю" свои соображения и свое видение проблемы. Можешь не соглашаться -- дело твое. Хамить только не надо.
ДГ>На форумах, где контент постоянно меняется, от этого кода толку мало. И вынос XSLT на клиента добавляет скорости независимо от кеша страниц. Вполне устоявшаяся практика, между прочим.
Это как же он добавляет скорости? Одно дело поднять из кэша сохраненную страницу, и совсем другое -- заново напялить на XML целое XSLT-преобразование.
ДГ>Это были твои слова — с 0.05 сек до 0.5 сек.
Не искажай. Мои слова были:
Разницы между 0.05 секунды и 0.5 секунды (такой оверхед надо еще постараться получить) пользователь вряд ли заметит.
ДГ>Я замерял суммарное время выполнения скриптов. Самопальное профилирование, в общем.
Брависсимо, что я могу сказать. И откуда же такая оголтелая уверенность в том, что своим переписыванием ты чудесным образом увеличил скорость работы сайта? Быть может, пооптимизируй ты запросы -- и все сравнялось бы.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
HgLab: Mercurial Server and Repository Management for Windows
О, у меня ещё останутся деньги по экскурсиям покататься! Я как раз собирался на этих выходных в Абхазию... (Это так, к слову. )
Н>...и ASP.NET 2.0 с моей стороны (с использованием всяких библиотек, разумеется)
Не катит. ASP вполне себе объектный. Повторяю в десятый раз (уж извини — походу опять для тупых ): мой модульный подход — результат эволюции моего именно PHP-стиля. (На Java я, знаешь ли, тоже всё на объектах рисую... хотя прочтение флейма, на который я привёл ссылку ниже, вызвало определённую задумчивость.) И изначально в ветке был вопрос именно по PHP. И тебе требуется доказать, что именно на PHP со всеми его ограничениями ты сделаешь на объектах во всех смыслах лучше, чем я без объектов.
По библиотекам — разговор отдельный. Я как бы против, но это обсуждаемо.
Н>Что мы друг другу докажем килобайтами кода? Что тебе или мне писать меньше пришлось? И что с того?
IT неоднократно утверждал, что объём кода — это наиболее простой и достоверный показатель его сложности. (Кстати, про то, что при необходимости ООП идёт лесом
, он тоже упоминал. )
Н>И пишу я с комментариями всегда.
Комментарии перед сравнением вырежем. И вообще, нормальный код (тем более для такой тривиальной задачи) должен быть самодокументирующимся. (Я даже готов переименовать свои $db->qrow() и $db->qarray() в $db->queryRow() и $db->queryArrayOfRows() не взирая на килобайты! ).
ДГ>>4. Сравниваем объем изменений в коде Н>Опять же -- что докажем-то?
Сложность изменений. Ну или я жду твоих предложений.
ДГ>>Поскольку ты доказываешь, что ООП хорош в любой ситуации, то для опровержения необходимо привести хотя бы один пример задачи, с которой мой подход справляется лучше. Н>Критерии оценки "лучше" какие? Уж не объем ли кода?
Объём кода как показатель сложности, и скорость работы (кстати, по последнему критерю сравнивать ASP и PHP опять же некорректно).
Здравствуйте, Нахлобуч, Вы писали:
Н>Хамить только не надо.
Ладно, извини.
Н>Это как же он добавляет скорости? Одно дело поднять из кэша сохраненную страницу, и совсем другое -- заново напялить на XML целое XSLT-преобразование.
Если преобразование выполняется на клиенте, с сервера нагрузка снимается — сервер просто отдаёт XSLT-файлы, которые на клиенте кстати ещё и кешируются. Так что в итоге, сервер избавляется от работы по генерации страниц, а учитывая компактный объём моих XML-ответов, ещё и трафик снижается донельзя.
ДГ>>Это были твои слова — с 0.05 сек до 0.5 сек. Н>Не искажай. Мои слова были: Н>
Н>Разницы между 0.05 секунды и 0.5 секунды (такой оверхед надо еще постараться получить) пользователь вряд ли заметит.
Ээээ... Я вообще-то изначально делал упор на высокую посещаемость. При хорошей нагрузке разница в 10 раз — это серьёзный повод для раздумий.
ДГ>>Я замерял суммарное время выполнения скриптов. Самопальное профилирование, в общем.
Н>Брависсимо, что я могу сказать. И откуда же такая оголтелая уверенность в том, что своим переписыванием ты чудесным образом увеличил скорость работы сайта? Быть может, пооптимизируй ты запросы -- и все сравнялось бы.
Уверенность оттуда, что я проводил замеры в процессе рефакторинга. Собственно, я и занимался оптимизацией запросов (для скорости) — а заодно упрощал код (для удобства), убирая всю эту громоздкую объектную инфраструктуру. Говорю же — я пробовал и так, и эдак. Ты сам согласился, что инкапсулировать сложные параметризованные запросы в методы с двадцатью параметрами неудобно. А если вгонять выборку нескольких объектов в один SQL-запрос, подобные ситуации будут возникать на каждом шагу — пусть не с двадцатью параметрами, а с двумя, но всё равно искать концы неудобно.
Здравствуйте, Дм.Григорьев, Вы писали:
ДГ>Ээээ... Я вообще-то изначально делал упор на высокую посещаемость. При хорошей нагрузке разница в 10 раз — это серьёзный повод для раздумий.
Да ну ты получи такую разницу сначала. Чтоб при прочих равных условиях (SQL-запросы, БД, индексы) код, написанный в твоем стиле и его ОО-эквивалент выполнялись с разницей на порядок -- это надо сильно постараться.
ДГ>Уверенность оттуда, что я проводил замеры в процессе рефакторинга. Собственно, я и занимался оптимизацией запросов (для скорости) — а заодно упрощал код (для удобства), убирая всю эту громоздкую объектную инфраструктуру. Говорю же — я пробовал и так, и эдак.
Опять же -- сидел с секундомером и замерял? И что значит "и так, и эдак"? Оптимизация индексов и запросов при сохранении архитектуры не помогла?
ДГ>Ты сам согласился, что инкапсулировать сложные параметризованные запросы в методы с двадцатью параметрами неудобно. А если вгонять выборку нескольких объектов в один SQL-запрос, подобные ситуации будут возникать на каждом шагу — пусть не с двадцатью параметрами, а с двумя, но всё равно искать концы неудобно.
И какая связь с быстродействием? "Неудобно искать концы" в неудобных средах разработки.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
HgLab: Mercurial Server and Repository Management for Windows
Здравствуйте, WolfHound, Вы писали:
WH>Ты про это? WH>http://tpc.org/tpcc/results/tpcc_perf_results.asp?resulttype=all&version=5&currencyID=0
Угу.
WH>Так там вего один кластер. Сделаный в 2004ом... причем это самая быстрая система сделаная в 2004ом...
Именно, а знаешь почему? Неэффективно, просто класс задач такой, узким местом являются сами данные, которые на несколько машин эффективно не растянешь. За последние лет 10, ни одни кластер там долго на первом месте не держался, если вообще до первого дотягивал. Практика показывает, что для таких задач всегда можно собрать одну машину, которая будет дешевле и эффективнее кластера.
WH>Как эту задачу решить кластером я представляю. А вот как с этим справится большое железо нет.
Кластеры бывают разные, повышение надежности и провышение производительности задачи чуть ли не противоположные, и кластеры, соответственно тоже по разному устроены (хотя можно и комбинировать). Кластер, который собрали для повышения отказоустойчивости, по сути большая машина с онлайн бакапом и хот стэндбаем, нагрузка по обработке запроса там не параллелится.
Здравствуйте, Нахлобуч, Вы писали:
ДГ>>Уверенность оттуда, что я проводил замеры в процессе рефакторинга. Собственно, я и занимался оптимизацией запросов (для скорости) — а заодно упрощал код (для удобства), убирая всю эту громоздкую объектную инфраструктуру. Говорю же — я пробовал и так, и эдак.
Н>Опять же -- сидел с секундомером и замерял?
Скидывал в журнал ($endtime — $starttime).
Н>И что значит "и так, и эдак"?
Вот то и значит. За последние два года я наваял порядка 20-ти проектов (из них 3 более-менее крупных, остальные — уровня инет-магазинов), и хотя инет-магазины я рисовал практически под копирку (то есть брал исходники последнего проекта и копировал на новый), среди них нет и двух с одинаковой инфраструктурой и одинаковыми служебными библиотеками (хе-хе, можешь себе представить, как прикольно поддерживать весь этот зоопарк полу-клонов... но к сложности отдельно взятого сайта это отношения не имеет! )
Н>Оптимизация индексов и запросов при сохранении архитектуры не помогла?
Оптимизация запросов помогала — для скорости. И упрощение архитектуры помогало — для простоты. Я же писал. Что ты прицепился к этой архитектуре, как к священной корове?
Н>"Неудобно искать концы" в неудобных средах разработки.
То есть, ты предлагаешь забить на PHP? С удовольствием, но это уже другой разговор.
Ну и слава Богу! Значит, я ещё и в Сочи да Анапу как-нибудь сгоняю на катере на подводных крыльях. Хотя уродский он... а я так надеялся, что пустили пресноводные красавцы-"Метеоры"...
. Я рассказал, как я делаю — дешево и сердито. Ты мне начал доказывать, что на других языках по-другому круче. Но вопрошавшего другие языки не интересовали. Так что мы хорошо поругались ни о чём, и ничего нового не узнали. Поэтому предлагаю эту тему закрыть.
Здравствуйте, IB, Вы писали:
IB>Кластеры бывают разные, повышение надежности и провышение производительности задачи чуть ли не противоположные, и кластеры, соответственно тоже по разному устроены (хотя можно и комбинировать). Кластер, который собрали для повышения отказоустойчивости, по сути большая машина с онлайн бакапом и хот стэндбаем, нагрузка по обработке запроса там не параллелится.
Те ты лучше меня знаешь как у меня кластер работает?
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Дм.Григорьев, Вы писали:
ДГ>Так что мы хорошо поругались ни о чём, и ничего нового не узнали. Поэтому предлагаю эту тему закрыть.
Только твое предложение меня заинтересовало. А что если и правда устроить состязание языков-фреймворков-платформ? Не не деньги (не люблю я этого), а исключительно их спортивного интереса -- посмотреть, что в итоге получится. Уже и кандидат есть -- Beast. А? Может, еше кто подтянется.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
HgLab: Mercurial Server and Repository Management for Windows
Здравствуйте, Нахлобуч, Вы писали:
Н>Только твое предложение меня заинтересовало. А что если и правда устроить состязание языков-фреймворков-платформ? Не не деньги (не люблю я этого), а исключительно их спортивного интереса -- посмотреть, что в итоге получится. Уже и кандидат есть -- Beast. А? Может, еше кто подтянется.
Гы, очередной холивар задумал?!
(ворчит) Больше мне заняться нечем... Да и какой смысл устраивать состязание PHP и ASP? Я почти уверен, что PHP отсосёт по всем параметрам. Ни для кого не секрет, что у PHP единственное преимущество — низкий порог вхождения. Убогий язык для убогих задач, не случайно он так распространён на shared-хостинге. А сравнивать ASP и Java я ещё не готов — слишком мало опыта. Разве что через годик-другой (надеюсь) я достаточно освоюсь в J2EE и имеющихся к ней фреймворках.
Здравствуйте, IB, Вы писали:
WH>>Те ты лучше меня знаешь как у меня кластер работает? IB>Причем тут ты?
При том что у меня запросы паралелится и отказоустойчивость обеспечивается.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
все запросы приходится оптимизировать вручную. 
При хорошей нагрузке твои ООП-творения благополучно ляжут.
). 
)
Мы уже победили, просто это еще не так заметно...
