Ну, если двух ядер мало, то можно поставить 9.1, а не 9.5
Или, когда двух ядер перестанет хватать, купить поддержку. Или купить ее сразу, благо HADR и репликация нужны сразу, а стоит она копейки.

Насколько я помню, на сервере 2*2 все запустится, просто не будет лишние ядра использовать - что на раннем этапе не страшно.

maximpr1111
В данном случае, я подразумеваю под веб сервером, машину которая отвечает за получение запросов и распределение их между Application Server-ами, которые, так как речь идет о servlet-технологии могут их обрабатывать и без посредников.

А. В этом случае можно подумать о железках - round robin многие умеют делать. Если есть нормальный админ - то выйдет дешевле. Если нет - то все равно проблемы будут.

Я то думал, что ты решил разделить генерацию html и собственно бизнес-логику (так иногда делают, например, накладывая XSL на отдаваемый XML на отдельной машине). Зачастую даже производительнее получается и дешевле.

tygraИзвините, но если идет речь о системе с количеством пользователей, измеряемым миллионами, и в то же время считать копейки - у вас ничего не получится уже до того, как чего-то начнете.
Не копейки. Для указанной системы стоимость лицензий - самый большой планируемый расход (если не делать систему на, по мере возможности, бесплатных или дешевых решениях). Windows Data Center (да даже и Server 2008 64bit) - это очень дорого.


По поводу Java и быстрой системы - нюню, этто буддетт оччень быстттро, по эсттоннсски :)

Гм, а что, есть хоть одно возражение против скорости Java? Тем более на сервере. Или есть более быстрые промышленные решения (ну, кроме реализации на голом C - да и то, не факт, что будет заметно быстрее и уж точно на порядок дороже в разработке). Как-то я вот смотрю по сторонам, вижу кучу нагруженных сервисов на Java - и не вижу особых проблем с производительностью. Хотя некоторые из них даже и спроектированы не самым удачным способом.

Yo.! VoDA
А тянуть "гигабайты данных по эзернету в жава и там их лопатить" это сказки. Никто вменяемый так не делает (кроме случая когда это действительно необходимо).
делают, еще как делают :(
обычно все начинается с кеширования справочников в хибернейте со словами, хибер же лучше заджоинит ...

Вменяемые - не делают, они вообще не используют ORM на нагруженных системах.
Угу. Использование Java не значит, что не нужно представлять, как работает БД.
Хотя использование БД как простого и эффективного хранилища для большей части задач имеет смысл - тем не менее это не стоит делать через hibernate.
Впрочем, если для справочников нужны join'ы - это уже что-то не правильное.

Anton DemidovВы что-нибудь про нормализацию данных слышали? Третья нормальная форма?

О, умный какой. Судя по вопросу, ты про 3НФ услышал совсем недавно?
Ты подумай, как-нибудь, на досуге, зачем вообще используются нормальные формы, когда они нужны, когда нет. Подумай, какое отношение третья нормальная форма имеет к задаче загрузки справочников в application layer и оптимальности управления справочниками. Зачем вообще в корпоративных системах используются справочники, как их использование сказывается на производительности.
Ну и на все прочие вопросы, которые после пятой/десятой спроектированной системы обычно уже не возникают. И после этого уже "умные" вопросы задавай.
Ах, да, и где там внутри справочника нужны join'ы ;)


Оракл где-то писал (давно было - ссылку не найду), что PL/SQL в режиме интерпретации в два раза быстрее Явы. А начиная с версии 9i PL/SQL может компилироваться в натив код (через С).
Очень хотелось бы посмотреть на ссылку. А то Java, вообще говоря, чистому C уступает максимум на десятки процентов, а зачастую и превосходит. Может, это про Java 1.0 было? Так с тех пор много воды утекло. В общем, надо посмотреть, что именно Oracle мерял и для чего - а то если меряли для рекламы использования хранимых процедур, то PL/SQL и C мог бы превзойти, дурное дело не хитрое.
P.S. Кстати, Java уже довольно давно автоматически компилится в нативный код (если это окупится при выполнении). См. JIT.

mva103
Я проводил нагрузочное исследование для выяснения нагрузочной способности MSSQL и Oracle. Задача тестирования была в выяснении потолка количества обслуживаемых простых запросов от application layer(делался селект из таблицы в 4 записи). Архитектура была такая
RDBMS<------>(APACHE + PHP) * 4<----------->nginx+ round robin<--------->client * N
К сожалению не могу привести абсолютных цифр, т.к. тестировал для себя, а не для отчета

Было бы, конечно, интересно посмотреть на результаты теста (численные) - хотя бы примерно.

Но, честно говоря, зачем application layer усиленно ходить к БД с такими запросами, да еще и в таком режиме. Кэш делу не помог бы? Или данные менялись через БД, в обход application layer? И в основном сверялись версии данные в кэше с данными в БД? Т.е. какую задачу решает такое массовое обращение?

И в таком случае правильно ли было использовать схему "тред на запрос"? Если основное, что делают треды - это ждут ответа от БД? Может, использовать схему однопоточной последовательной обработки было бы лучше? Правда, конечно, кодировать это существенно сложнее и думать нужно гораздо больше (и не знаю, можно ли это вообще сделать на PHP).

Anton Demidov
У вас несколько односторонний взгляд на вещи. БД - для хранения и обработки данных. Она проектируется и живёт по своим правилам, отличным от того, что вы делаете на уровне приложения, особенно java-приложения.

Все верно, конечно. Но если мы проектируем сразу трехзвенку (а такое часто случается), то стоит учитывать и возможности/ограничения БД и возможности/ограничения AppLayer'а - тогда всем будет проще. Увы, обычно в проекте или хорошо знают БД или хорошо умеют работать с Java/PHP/C# - в результате появляются странные решения.

Anton Demidov
Я это к тому, что справочники должны храниться в базе нормализованными и "разворачиваться" при помощи "джойнов" в удобоваримый для application layer вид. А вы уже можете кешировать результаты этой выборки, а не сырой селект из таблиц. Проблемы здесь не вижу.

В общем, конечно, да. Но смотри(те), для обычных звездочек (таблица с данными, куча классификаторов через искусственные, например, ключи) при таком решении мы получим:
1) Для каждого запроса нужно делать несколько join'ов по всем таблицам справочников (обычно редко изменяемых)
2) Для каждого типа запроса на AL придеться: получать очередную звезду, вытаскивать и переводить в соответствующие Java(например) объекты все полученные сущности (как факты, так и каждый из классификаторов). При этом есть некоторые проблемы - например, придумать всегда одинаковую (для простоты кодирования) схему именования алиасов для разных объектов.
В любом случае нужно будет дополнительное кодирование и сложно делать code reuse.

Есть другой вариант:
Все в БД хранится так же, но AL выбирает только нужные факты, без join на справочники.
Справочники (в уже удобном виде) живут в кэше AL (стратегии можно разные придумать - lazy loading, загрузка при старте и т.п. - зависит от размера справочника и много другого). Связывание id с конкретным объектом делает уже сервер приложений. Кстати, зачастую может выяснится, что привязывать объект к справочнику внутри и не нужно.

Нарушений нормализации - нет, но и лишних join'ов - тоже нет. Работает быстрее, кода нужно писать меньше. Это - стандартная практика.

Кстати, я первый пост про join понял в другом ключе - что необходимы join "внутри" справочника - а это уже не совсем правильная вещь.



Ещё меня смутило ваше предложение DPHИли данные менялись через БД, в обход application layer? Звучит так, как будто это вас удивляет и возмущает. Я вас правильно понял?

Ага. Так как требования к производительности разумно решать через кэширование (да и кодировать так зачастую проще). Но при этом возможность изменить БД в обход AL приводит к большим затратам на синхронизацию кэша с БД. Стандартной практикой для трехзвенок является запрет на изменение БД не через стандартные средства AL. Если делается иначе - то нужно точно понимать, почему.

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




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

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

P.S. С "ты" и "вы" все довольно сложно, это очень индивидуальная особенность. Если есть конкретные пожелания по обращению, то постараюсь их выполнить.
Умолчания, увы, практически не действуют - на разных форумах, в разных ветках, для разных людей действуют разные условности обращений.


--
Per rectum ad astrum[/quot]

Yo.!
ну и много твоих вменяемых хотя бы в России/СНГ забубенивших нагруженную систему на жабе ? чо-то на top.mail.ru я таковых не наблюдаю.

А как ты отличаешь написанные на JAVA от обычного LAMP? Вообще информация о архитектуре почти всегда NDA.

В РФ вообще мало сколь-нибудь нагруженных систем и меньшая часть из них на top.mail.ru.
Но значительная часть сервисов Яндекса, например, живет на Java, в том числе и сильно нагруженные.
Из не только РФ систем, с которыми знаком - есть биржевые системы (а это - уже 50+K событий в секунду), букмекерские сайты. Из крупных сайтов (хотя это уже не просто нагруженные, а очень нагруженные системы) - eBay.

По моему опыту, сайты, выросшие из мелких студенческих проектов - LAMP. Те, что сразу проектировались под высокую нагрузку - Java или C/С++.

VoDAБольшинство систем создаваемых на любом языке - не нагруженные. А за счет hibernate софто-присатели хотят уменьшить время программирования, а значит понизить себестоимость.

Ага. Я не в малейшей степени не отрицаю полезность hibernate - у него хоть и не безумно широкая, но очень популярная сфера применения. Но вот в нагруженных системах не стоит использовать.

DPHВпрочем, если для справочников нужны join'ы - это уже что-то не правильное.А как вы собираетесь использовать справочник по ссылке через внешний ключ НО не джойнясь при этом???[/quot]
Ты в своем предыдущем посте описал именно то, что я имел в виду - сборку на клиенте (да и то, если нужно).