Здравствуйте, ilvi, Вы писали:

I>Даже во втором случае увеличение производительности может быть меньше, если бы выделели больше времени на разработку.
I>Приведу пример из жизни. Он конешно надуманый, но какой есть
I>Есть у нас продуманая до мелких деталей машина марки ферари и есть чудо российского автопрома — лада. Сколько лад не покупай, не запрягай в одну упряжку ехать со скоростью ферари они не смогут Зато они смогут вести больше людей. Но что делать, если мне не надо именно быстро ехать, а не обеспечивать транспортом толпу людей, которые никуда не спешат?

Думаю надо обратиться на профильный форум по автомобилям. Догадываться, что вы хотите сказать очень не хочется. Я например понял так, что вы хотите максимально быстрый сервер из возможных, рекомендую взять mysql, отключить транзакции, использовать чистый сиквел и нейтив провайдер для клиента, язык ASM или C.

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

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

Здравствуйте, gandjustas, Вы писали:

M>>У меня не БД в кластере, у меня сервера приложений, а сервер БД -- 1.
G>Это понятно. При распределенной БД были бы совершенно другие проблемы.
Согласен. Распределенная БД для энтерпрайз -- это другой уровень и совершенно другой ценовой ценовой диапазон решений. Я бы даже сказал, что эта тема счас малоактивна, ибо дорого и не на потоке.

M>>И распределенный кеш нужен именно поэтому -- чтобы не держать общие данные в кеше на каждом узле и чтобы не париться с настройкой инвалидации данных.
G>Ну это ему скорости не добавляет.
Конечно, он будет медленнее, чем внутрипроцессный или даже локальный кеш, но у нас на серверах 10гигабит эзернет, который все равно невозможно "забить" данными до отказа -- он отрабатывает гораздо быстрее, чем БД Этот кеш позволяет здорово разгрузить БД, на долю которой остаются в основном пуш-запросы (update, delete).

Если вам интересно, вот результаты эксперимента по cpu utilization. С отключенным распределенным кешем сервер приложений был загружен на 20%, сервер БД -- на 85%. С включенным кешем ситуация обратная -- сервер приложений плотно "приседает" на процессор (85%-90%), а cpu БД не поднимается выше 17%. Это говорит о том, что у нас есть отличный запас по производительности -- в случае "затыка" мы не лимитированы БД, которую было бы сложно отмасштабировать, а можем набросать еще серверов приложений.

G>"Этого" ни в одной инфраструктуре. Подходов к кешированию по last-modified может быть много, и зависят они от сценариев использования данных.
В NHibernate в кеше используется одна из разновидностей такого кеширования. Прямо "из коробки".

G>Зато такое кеширование является самым эффективным.
Согласен, кастомный "ручной" тюнинг во многих случаях является самым эффективным, но он и требует больше всего затрат на наладку и поддержку. Мы не можем себе такое позволить -- нам нужны будут несколько человек, которые анализируют сценарии и занимаются исключительно проблемой производительности. Причем из-за частой смены модели (~20 экспертов постоянно ее оптимизируют и усовершенствуют) нам придется только и делать, что менять схемы кеширования. А учитывая повышенную сложность отладки приложений с кешем...

M>>Хм. Лично я не понимаю, зачем в каждой точке кода, где нужен кеш, думать, как этот кеш сделать. Грубо, если в сервисе А вам нужно N полей объекта, а в сервисе B -- N+2, то придется по новой продумать весь сервис кеширования.
G>Не надо ничего по новой продумывать, это все обобщенным кодом делается. Если стратегии кеширования не меняются, то и код не меняется.
Думаю, что для каждого случая надо будет продумывать свою стратегию кеширования. Имхо это затратно.
Мне не сложно запустить по сети несколько инстансов memcached (я это делаю менеджером memcahed, не вставая из-за компьютера). Мне кажется, приобрести лишние планки рамы -- это гораздо дешевле, чем сопровождать изощренные схемы кеширования.

Здравствуйте, meowth, Вы писали:

M>>>И распределенный кеш нужен именно поэтому -- чтобы не держать общие данные в кеше на каждом узле и чтобы не париться с настройкой инвалидации данных.
G>>Ну это ему скорости не добавляет.
M>Конечно, он будет медленнее, чем внутрипроцессный или даже локальный кеш, но у нас на серверах 10гигабит эзернет, который все равно невозможно "забить" данными до отказа -- он отрабатывает гораздо быстрее, чем БД Этот кеш позволяет здорово разгрузить БД, на долю которой остаются в основном пуш-запросы (update, delete).
О минимальности требований к железу явно не задумывались.

M>Если вам интересно, вот результаты эксперимента по cpu utilization. С отключенным распределенным кешем сервер приложений был загружен на 20%, сервер БД -- на 85%. С включенным кешем ситуация обратная -- сервер приложений плотно "приседает" на процессор (85%-90%), а cpu БД не поднимается выше 17%. Это говорит о том, что у нас есть отличный запас по производительности -- в случае "затыка" мы не лимитированы БД, которую было бы сложно отмасштабировать, а можем набросать еще серверов приложений.
Это говорит о том что БД используется неэффективно. Сделав правильные запросы, вы б смогли и без кеша напрягать субд не более, чем на 25%, имея ту же 20% заугрузку сервера приложений.

G>>"Этого" ни в одной инфраструктуре. Подходов к кешированию по last-modified может быть много, и зависят они от сценариев использования данных.
M>В NHibernate в кеше используется одна из разновидностей такого кеширования. Прямо "из коробки".
Каким образом? Без модификации базы просто так last-modified не натянешь.
При этом кешировать данные, возвращенные запросом — самый эффективный способ расходования памяти.

G>>Зато такое кеширование является самым эффективным.
M>Согласен, кастомный "ручной" тюнинг во многих случаях является самым эффективным, но он и требует больше всего затрат на наладку и поддержку.
Это только так кажется. На самом деле стратегий кеширования а одном приложении будет несколько штук всего, при этом все они поддерживаются обощенным кодом.
M>Мы не можем себе такое позволить -- нам нужны будут несколько человек, которые анализируют сценарии и занимаются исключительно проблемой производительности.
Естественно имея говотовое приложение, которое во всю испльзует LL, придется выделять отдельую группу для тонинга таких производительности.

M>Причем из-за частой смены модели (~20 экспертов постоянно ее оптимизируют и усовершенствуют) нам придется только и делать, что менять схемы кеширования.
Не придется, причину я выше описал.

M>А учитывая повышенную сложность отладки приложений с кешем...



M>>>Хм. Лично я не понимаю, зачем в каждой точке кода, где нужен кеш, думать, как этот кеш сделать. Грубо, если в сервисе А вам нужно N полей объекта, а в сервисе B -- N+2, то придется по новой продумать весь сервис кеширования.
G>>Не надо ничего по новой продумывать, это все обобщенным кодом делается. Если стратегии кеширования не меняются, то и код не меняется.
M>Думаю, что для каждого случая надо будет продумывать свою стратегию кеширования. Имхо это затратно.
Думать мозгом гораздо менее затратно, чем писать код. Код тяжелее выкинуть.

M>Мне не сложно запустить по сети несколько инстансов memcached (я это делаю менеджером memcahed, не вставая из-за компьютера). Мне кажется, приобрести лишние планки рамы -- это гораздо дешевле, чем сопровождать изощренные схемы кеширования.
Сам себе противоречишь. Распределенный кеш ораздо более сложен в использовани, чем кеширование по last-modified. Преимущество у него только в том, что его можно использовать дял всего. Только не факт что будет от этого толк.

Здравствуйте, ilvi, Вы писали:

I>Здравствуйте, meowth, Вы писали:

M>>Ну имхо вы усложняете. It depends. В смысле, если сервер был 1, и добавить еще один -- это да, может быть очень заморочисто. А если их было 2 или 3 или больше, то добавить еще один -- обычно совершенно не сложно, т.к. архитектура уже приспособлена к децентрализации.

I>Даже во втором случае увеличение производительности может быть меньше, если бы выделели больше времени на разработку.
I>Приведу пример из жизни. Он конешно надуманый, но какой есть
I>Есть у нас продуманая до мелких деталей машина марки ферари и есть чудо российского автопрома — лада. Сколько лад не покупай, не запрягай в одну упряжку ехать со скоростью ферари они не смогут Зато они смогут вести больше людей. Но что делать, если мне не надо именно быстро ехать, а не обеспечивать транспортом толпу людей, которые никуда не спешат?

Я так понял, замороченные примеры из жизни -- эта крута, поэтому отвечу вот каким: если бы во рту росли галлюциногенные грибы, то можно было бы трансформировать сознание, не отходя от кассы, так сказать. Понятно, что я хотел сказать?

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

Откуда вы возьмете деньги на феррари?

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, meowth, Вы писали:

M>>>>И распределенный кеш нужен именно поэтому -- чтобы не держать общие данные в кеше на каждом узле и чтобы не париться с настройкой инвалидации данных.
G>>>Ну это ему скорости не добавляет.
M>>Конечно, он будет медленнее, чем внутрипроцессный или даже локальный кеш, но у нас на серверах 10гигабит эзернет, который все равно невозможно "забить" данными до отказа -- он отрабатывает гораздо быстрее, чем БД Этот кеш позволяет здорово разгрузить БД, на долю которой остаются в основном пуш-запросы (update, delete).
G>О минимальности требований к железу явно не задумывались.
У нас не коробочное приложение. Требования выставил заказчик, мы пишем на том, что есть.

M>>Если вам интересно, вот результаты эксперимента по cpu utilization. С отключенным распределенным кешем сервер приложений был загружен на 20%, сервер БД -- на 85%. С включенным кешем ситуация обратная -- сервер приложений плотно "приседает" на процессор (85%-90%), а cpu БД не поднимается выше 17%. Это говорит о том, что у нас есть отличный запас по производительности -- в случае "затыка" мы не лимитированы БД, которую было бы сложно отмасштабировать, а можем набросать еще серверов приложений.
G>Это говорит о том что БД используется неэффективно. Сделав правильные запросы, вы б смогли и без кеша напрягать субд не более, чем на 25%, имея ту же 20% заугрузку сервера приложений.
Я понял вас: у нас неправильно написанное приложение. Правильное -- оно, конешно, лучше было бы, и уж явно не такое, как мы написали — и сервер не грузило бы, и работало мгновенно, и ошибок не выдавыло б никогда.

G>>>"Этого" ни в одной инфраструктуре. Подходов к кешированию по last-modified может быть много, и зависят они от сценариев использования данных.
M>>В NHibernate в кеше используется одна из разновидностей такого кеширования. Прямо "из коробки".
G>Каким образом? Без модификации базы просто так last-modified не натянешь.
G>При этом кешировать данные, возвращенные запросом — самый эффективный способ расходования памяти.
Еще раз говорю, укажите мне на пункт, который говорит о критичности расхода памяти. Это не аргумент.
А зачем для last-modified модифицировать БД? Отметки о модификации хранятся в системе кеширования.

G>>>Зато такое кеширование является самым эффективным.
M>>Согласен, кастомный "ручной" тюнинг во многих случаях является самым эффективным, но он и требует больше всего затрат на наладку и поддержку.
G>Это только так кажется. На самом деле стратегий кеширования а одном приложении будет несколько штук всего, при этом все они поддерживаются обощенным кодом.
M>>Мы не можем себе такое позволить -- нам нужны будут несколько человек, которые анализируют сценарии и занимаются исключительно проблемой производительности.
G>Естественно имея говотовое приложение, которое во всю испльзует LL, придется выделять отдельую группу для тонинга таких производительности.
Без комментариев, честно.

M>>>>Хм. Лично я не понимаю, зачем в каждой точке кода, где нужен кеш, думать, как этот кеш сделать. Грубо, если в сервисе А вам нужно N полей объекта, а в сервисе B -- N+2, то придется по новой продумать весь сервис кеширования.
G>>>Не надо ничего по новой продумывать, это все обобщенным кодом делается. Если стратегии кеширования не меняются, то и код не меняется.
M>>Думаю, что для каждого случая надо будет продумывать свою стратегию кеширования. Имхо это затратно.
G>Думать мозгом гораздо менее затратно, чем писать код. Код тяжелее выкинуть.
А, я понял, что вы хотите сказать -- что когда мы писали ПО, мы не думали. Вы тоже любитель ставить диагнозы по фото?

M>>Мне не сложно запустить по сети несколько инстансов memcached (я это делаю менеджером memcahed, не вставая из-за компьютера). Мне кажется, приобрести лишние планки рамы -- это гораздо дешевле, чем сопровождать изощренные схемы кеширования.
G>Сам себе противоречишь. Распределенный кеш ораздо более сложен в использовани, чем кеширование по last-modified.
Я не увидел противоречия. Сложен в использовании, если его писать самому и прочее. Тут он из коробки -- несколько параметров в config, и все работает.

G>Преимущество у него только в том, что его можно использовать дял всего. Только не факт что будет от этого толк.
Факт есть -- у нас толк присутствует.

Здравствуйте, MozgC, Вы писали:

MC>>>А не мог бы ты как нибудь написать тестовое приложение в стиле anemic? Ну чисто customer + order + orderline к примеру в winforms. Во-первых было бы многим полезно, во-вторых можно было бы уже его исопльзовать для обсуждения, приведения примеров кода и т.д.
G>>Хотел бы, но пока времени нету. Кроме того делать что-то очень простое не хотелось бы, непоказательно будет.
MC>Дык можно набросать за пару часиков основу, а потом уже постепенно ее развивать чтобы становилось все более и более показательнее. К примеру спросил потом кто-то на форуме "а вот как сделать то-то?" — ты взял и добавил это для примера в свое приложение уже по быстрому.

G>>Вероятнее всего пример будет на ASP.NET MVC. Писать MVP для winforms ломает — многословно получается. Потом может на wpf сделаю.
MC>Имхо winforms было бы проще для понимания и показательнее... А насчет необходимости MVP.. ну не буду холивар поднимать

Я присоединяюсь;
Не сочтите за наглость, но хотел бы добавить, что не настаиваю, но весьма желал бы увидеть там те аспекты, которые были затронуты в споре:
а) поддержку версионирования данных;
б) кеширование;
в) опционально, но не критично -- валидацию.

Здравствуйте, MozgC, Вы писали:

G>>>>>>В в хибернейте до сих пор осталась "фича", что объекты полученные разными путями (навигационном и запросом) являются разными?
M>>>>>Зависит от запроса.
O>>>> А разве нельзя Equals() переопределить, чтобы было как надо?
MC>>>Тут видимо имеется в виду что получаются разные instance'ы объектов, а иногда нужно чтобы был только один instance, типа как бы глобальный IdentityMap.
O>> Интересно, а когда это может причинять неудобства, кроме случая ссылочного сравнения объектов?

MC>Архитектура корпоративных программных приложений (c) Мартин Фаулер :

[поскипано]

Пора уже перечитать...

Я так понимаю, проблема в том, что один и тот же объект будет лежать в памяти в разных экземплярах и изменение одного не приведет к изменению другого? Т.е. получится рассинхронизация данных объекта в разных экземплярах? Т.е. хибернейтовские прокси будут обращаться к разным объектам, хотя id у них будет одинаковый? Вот это новость!

Здравствуйте, meowth, Вы писали:

M>>>Если вам интересно, вот результаты эксперимента по cpu utilization. С отключенным распределенным кешем сервер приложений был загружен на 20%, сервер БД -- на 85%. С включенным кешем ситуация обратная -- сервер приложений плотно "приседает" на процессор (85%-90%), а cpu БД не поднимается выше 17%. Это говорит о том, что у нас есть отличный запас по производительности -- в случае "затыка" мы не лимитированы БД, которую было бы сложно отмасштабировать, а можем набросать еще серверов приложений.
G>>Это говорит о том что БД используется неэффективно. Сделав правильные запросы, вы б смогли и без кеша напрягать субд не более, чем на 25%, имея ту же 20% заугрузку сервера приложений.
M>Я понял вас: у нас неправильно написанное приложение. Правильное -- оно, конешно, лучше было бы, и уж явно не такое, как мы написали — и сервер не грузило бы, и работало мгновенно, и ошибок не выдавыло б никогда.
Ну примерно так.
На самом деле при правильном написании с вашими нагрузками хватило бы одного аппсервера, и одни хороший сервак с БД без распределнных кешей.

G>>>>"Этого" ни в одной инфраструктуре. Подходов к кешированию по last-modified может быть много, и зависят они от сценариев использования данных.
M>>>В NHibernate в кеше используется одна из разновидностей такого кеширования. Прямо "из коробки".
G>>Каким образом? Без модификации базы просто так last-modified не натянешь.
G>>При этом кешировать данные, возвращенные запросом — самый эффективный способ расходования памяти.
M>Еще раз говорю, укажите мне на пункт, который говорит о критичности расхода памяти. Это не аргумент.
M>А зачем для last-modified модифицировать БД? Отметки о модификации хранятся в системе кеширования.
Еще раз: эффективный кеш по last-modified делает очень простыми средствами, без крутого распределенного кеша.

M>>>>>Хм. Лично я не понимаю, зачем в каждой точке кода, где нужен кеш, думать, как этот кеш сделать. Грубо, если в сервисе А вам нужно N полей объекта, а в сервисе B -- N+2, то придется по новой продумать весь сервис кеширования.
G>>>>Не надо ничего по новой продумывать, это все обобщенным кодом делается. Если стратегии кеширования не меняются, то и код не меняется.
M>>>Думаю, что для каждого случая надо будет продумывать свою стратегию кеширования. Имхо это затратно.
G>>Думать мозгом гораздо менее затратно, чем писать код. Код тяжелее выкинуть.
M>А, я понял, что вы хотите сказать -- что когда мы писали ПО, мы не думали.
Может и думали, но не в том направлении.

M>Вы тоже любитель ставить диагнозы по фото?
Уже почти профессионал.

M>>>Мне не сложно запустить по сети несколько инстансов memcached (я это делаю менеджером memcahed, не вставая из-за компьютера). Мне кажется, приобрести лишние планки рамы -- это гораздо дешевле, чем сопровождать изощренные схемы кеширования.
G>>Сам себе противоречишь. Распределенный кеш ораздо более сложен в использовани, чем кеширование по last-modified.
M>Я не увидел противоречия. Сложен в использовании, если его писать самому и прочее. Тут он из коробки -- несколько параметров в config, и все работает.
Ну да, хороший способ не думать.

G>>Преимущество у него только в том, что его можно использовать дял всего. Только не факт что будет от этого толк.
M>Факт есть -- у нас толк присутствует.
Значит он отсутвует в другом месте.

Здравствуйте, gandjustas, Вы писали:

M>>Я понял вас: у нас неправильно написанное приложение. Правильное -- оно, конешно, лучше было бы, и уж явно не такое, как мы написали — и сервер не грузило бы, и работало мгновенно, и ошибок не выдавыло б никогда.
G>Ну примерно так.
G>На самом деле при правильном написании с вашими нагрузками хватило бы одного аппсервера, и одни хороший сервак с БД без распределнных кешей.
Думаю, что вам виднее

G>>>При этом кешировать данные, возвращенные запросом — самый эффективный способ расходования памяти.
M>>Еще раз говорю, укажите мне на пункт, который говорит о критичности расхода памяти. Это не аргумент.
M>>А зачем для last-modified модифицировать БД? Отметки о модификации хранятся в системе кеширования.
G>Еще раз: эффективный кеш по last-modified делает очень простыми средствами, без крутого распределенного кеша.
При чем здесь это? Если кеш уже есть и умеет делать last-modified, чего б его тогда не поюзать?

G>>>>>Не надо ничего по новой продумывать, это все обобщенным кодом делается. Если стратегии кеширования не меняются, то и код не меняется.
M>>>>Думаю, что для каждого случая надо будет продумывать свою стратегию кеширования. Имхо это затратно.
G>>>Думать мозгом гораздо менее затратно, чем писать код. Код тяжелее выкинуть.
M>>А, я понял, что вы хотите сказать -- что когда мы писали ПО, мы не думали.
G>Может и думали, но не в том направлении.


M>>Вы тоже любитель ставить диагнозы по фото?
G>Уже почти профессионал.

M>>>>Мне не сложно запустить по сети несколько инстансов memcached (я это делаю менеджером memcahed, не вставая из-за компьютера). Мне кажется, приобрести лишние планки рамы -- это гораздо дешевле, чем сопровождать изощренные схемы кеширования.
G>>>Сам себе противоречишь. Распределенный кеш ораздо более сложен в использовани, чем кеширование по last-modified.
M>>Я не увидел противоречия. Сложен в использовании, если его писать самому и прочее. Тут он из коробки -- несколько параметров в config, и все работает.
G>Ну да, хороший способ не думать.
Зачем писать велосипед?

G>>>Преимущество у него только в том, что его можно использовать дял всего. Только не факт что будет от этого толк.
M>>Факт есть -- у нас толк присутствует.
G>Значит он отсутвует в другом месте.
Все может быть. Например, у вас

Здравствуйте, meowth, Вы писали:

G>>>>При этом кешировать данные, возвращенные запросом — самый эффективный способ расходования памяти.
M>>>Еще раз говорю, укажите мне на пункт, который говорит о критичности расхода памяти. Это не аргумент.
M>>>А зачем для last-modified модифицировать БД? Отметки о модификации хранятся в системе кеширования.
G>>Еще раз: эффективный кеш по last-modified делает очень простыми средствами, без крутого распределенного кеша.
M>При чем здесь это? Если кеш уже есть и умеет делать last-modified, чего б его тогда не поюзать?
Не умеет он. А если умеет, то вносит дофига ограничений, которые сводят на нет все усилия.

M>>>>>Мне не сложно запустить по сети несколько инстансов memcached (я это делаю менеджером memcahed, не вставая из-за компьютера). Мне кажется, приобрести лишние планки рамы -- это гораздо дешевле, чем сопровождать изощренные схемы кеширования.
G>>>>Сам себе противоречишь. Распределенный кеш ораздо более сложен в использовани, чем кеширование по last-modified.
M>>>Я не увидел противоречия. Сложен в использовании, если его писать самому и прочее. Тут он из коробки -- несколько параметров в config, и все работает.
G>>Ну да, хороший способ не думать.
M>Зачем писать велосипед?
Распределенный кеш — это не велосипед, а паровой каток.
Вам же предлагают сделать несколько реактивных самолетов.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, meowth, Вы писали:

G>>>Еще раз: эффективный кеш по last-modified делает очень простыми средствами, без крутого распределенного кеша.
M>>При чем здесь это? Если кеш уже есть и умеет делать last-modified, чего б его тогда не поюзать?
G>Не умеет он. А если умеет, то вносит дофига ограничений, которые сводят на нет все усилия.
Странно, у меня умеет Расскажите про ограничения, а я расскажу, почему я их не встретил (по крайней мере в этом проекте)

M>>>>Я не увидел противоречия. Сложен в использовании, если его писать самому и прочее. Тут он из коробки -- несколько параметров в config, и все работает.
G>>>Ну да, хороший способ не думать.
M>>Зачем писать велосипед?
G>Распределенный кеш — это не велосипед, а паровой каток.
G>Вам же предлагают сделать несколько реактивных самолетов.
Вы не поняли. Rich и так предполагает наличие кеша. Я его и использую.

Здравствуйте, meowth, Вы писали:

M>Здравствуйте, gandjustas, Вы писали:

G>>Здравствуйте, meowth, Вы писали:

G>>>>Еще раз: эффективный кеш по last-modified делает очень простыми средствами, без крутого распределенного кеша.
M>>>При чем здесь это? Если кеш уже есть и умеет делать last-modified, чего б его тогда не поюзать?
G>>Не умеет он. А если умеет, то вносит дофига ограничений, которые сводят на нет все усилия.
M>Странно, у меня умеет Расскажите про ограничения, а я расскажу, почему я их не встретил (по крайней мере в этом проекте)
Получение результатов запроса с аггрегатными значениями и кешированием по last-modified.
Пример: нужно получить на клиента только измененные с момента последнего обновления ордеры вместе с суммами их заказа.

M>>>>>Я не увидел противоречия. Сложен в использовании, если его писать самому и прочее. Тут он из коробки -- несколько параметров в config, и все работает.
G>>>>Ну да, хороший способ не думать.
M>>>Зачем писать велосипед?
G>>Распределенный кеш — это не велосипед, а паровой каток.
G>>Вам же предлагают сделать несколько реактивных самолетов.
M>Вы не поняли. Rich и так предполагает наличие кеша. Я его и использую.
Выделеноое — офигенный недостаток. Для shared хостина не подходит вообще никак.
Кроме того требует достаточно много ресурсов.

Здравствуйте, gandjustas, Вы писали:

G>Получение результатов запроса с аггрегатными значениями и кешированием по last-modified.
G>Пример: нужно получить на клиента только измененные с момента последнего обновления ордеры вместе с суммами их заказа.
Cached query + query filter, и все работает.

M>>Вы не поняли. Rich и так предполагает наличие кеша. Я его и использую.
G>Выделеноое — офигенный недостаток. Для shared хостина не подходит вообще никак.
Если вы про ресурс памяти, то он недорогой сейчас. Лишние 8-16 Мб под кэш-память — это немного, можно позволить и на shared hosting даже внутрипроцессно. Кстати, там часто предлагают опцию memcached included 64M, даже на php-хостингах.

G>Кроме того требует достаточно много ресурсов.
Вы о чем? У нас 4 инстанса memcached на машине в режиме интенсивности выше среднего кушают в сумме 0,5-1,5% процессора максимум.

Здравствуйте, Ziaw, Вы писали:


Z>Я например понял так, что вы хотите максимально быстрый сервер из возможных
Правильно поняли. Мне не нужно выполнения 100 однотипных запросов одновременно, на каждый из который уйдет по 2 минуты. Мне нужно выполнение одного запроса, но не дольше чем за 5 секунд

Z>В этой ветке пытаются понять в каких ситуациях какая модель помогает легче справляться с увеличением сложности проекта. Иногда говорят о том, как победить тормза которые вызывает использование принципа persistance ignorance.
Я не против пускай пытаются, чем смогу помогу со своей стороны.

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

Просто мое мнение, что когда говорят: "лучше еще один сервер докупим, чем программист поработает", это ни что иное как признание несостоятельности программиста и желание компании разработчика переложить свои проблемы на шею заказчика. Потому что секономили на работе одного программиста сегодня, а завтра потратились на новый сервак (который тоже не копейки стоит, и дай бог чтоб только один докупили, а не 10), потратились на создание комнаты под серверное хозяйство, потратились на квалифицированную поддержку серверов (при этом ей за каждый месяц платить надо), озадачились на тему сколь же теперь деталей нужно хранить в ЗИПе на все это хозяйство.
При этом исходя из моей практики, людям обычно пофигу на выполнение быстрых запросов 1-3 секунды и совсем не пофигу на выполнение тяжелых запросов от минуты и более. При этом тяжелые запросты выполняются нечасто, а когда вы после оптимизаций делаете скорость их выполнения хотя бы в два раза быстрее, пользователи начинают радоваться как малые дети. И начинают чаще пользоваться тяжелыми запросами, которых раньше старались избежать и просчитать аналитику в уме на авось. При том, что это ускорение давалось простым пересмотром полей на которые надо навесить индексы.
К тому же не всегда дело в быстродействии сервера. При получении данных с промышленных устройств, часто узким местом становиться канал передачи данных. Вот есть у вас подстанция где-то далеко в тайге, и на ней радиомодем. И вы хоть запакупайтесь серверов, но данные быстрее чем это позволяет модем вы с устройства подцепленного к нему не получите. В этом случае надо сидеть и тчательно вымерять алгоритм и формат передачи данных.
Я вполне понимаю, что это все сугубо мой персональный опыт и он может быть единичным из тысячи, но на основании его я считаю, что программист должен до конца отрабатывать свою работы, и не сваливать решение проблем с производительностью на докупку серверов.
П.С.: может сумбурно, но уже спать охото.

Здравствуйте, Ziaw, Вы писали:


Z>Я например понял так, что вы хотите максимально быстрый сервер из возможных
Правильно поняли. Мне не нужно выполнения 100 однотипных запросов одновременно, на каждый из который уйдет по 2 минуты. Мне нужно выполнение одного запроса, но не дольше чем за 5 секунд

Z>В этой ветке пытаются понять в каких ситуациях какая модель помогает легче справляться с увеличением сложности проекта. Иногда говорят о том, как победить тормза которые вызывает использование принципа persistance ignorance.
Я не против пускай пытаются, чем смогу помогу со своей стороны.

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

Просто мое мнение, что когда говорят: "лучше еще один сервер докупим, чем программист поработает", это ни что иное как признание несостоятельности программиста и желание компании разработчика переложить свои проблемы на шею заказчика. Потому что секономили на работе одного программиста сегодня, а завтра потратились на новый сервак (который тоже не копейки стоит, и дай бог чтоб только один докупили, а не 10), потратились на создание комнаты под серверное хозяйство, потратились на квалифицированную поддержку серверов (при этом ей за каждый месяц платить надо), озадачились на тему сколь же теперь деталей нужно хранить в ЗИПе на все это хозяйство.
При этом исходя из моей практики, людям обычно пофигу на выполнение быстрых запросов 1-3 секунды и совсем не пофигу на выполнение тяжелых запросов от минуты и более. При этом тяжелые запросты выполняются нечасто, а когда вы после оптимизаций делаете скорость их выполнения хотя бы в два раза быстрее, пользователи начинают радоваться как малые дети. И начинают чаще пользоваться тяжелыми запросами, которых раньше старались избежать и просчитать аналитику в уме на авось. При том, что это ускорение давалось простым пересмотром полей на которые надо навесить индексы.
К тому же не всегда дело в быстродействии сервера. При получении данных с промышленных устройств, часто узким местом становиться канал передачи данных. Вот есть у вас подстанция где-то далеко в тайге, и на ней радиомодем. И вы хоть запакупайтесь серверов, но данные быстрее чем это позволяет модем вы с устройства подцепленного к нему не получите. В этом случае надо сидеть и тчательно вымерять алгоритм и формат передачи данных.
Я вполне понимаю, что это все сугубо мой персональный опыт и он может быть единичным из тысячи, но на основании его я считаю, что программист должен до конца отрабатывать свою работы, и не сваливать решение проблем с производительностью на докупку серверов.
П.С.: может сумбурно, но уже спать охото.

Здравствуйте, ilvi, Вы писали:

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

Здравствуйте, Ocenochka, Вы писали:
O> А что на счет PI?
PI — то, что его поклонники называют Perstistence Ignorance, а противники — Persistent Ignorance.

Здравствуйте, Ziaw, Вы писали:

Z>Пример из практики, при переводе на клиент-сервер одной из систем сделали из рич модели тощую, руководствуясь примерно теми же мотивами, что и ты декларируешь. Ядро логики мне не удалось изолировать так же хорошо как и в жирной, хотя я проектировал ее на три года позже чем жирную (смею надеяться, что за три года в голове прибавилось ). Реюз кода уменьшился и, как я ни старался, сейчас требуется намного больше знаний о системе для написания новой логики. Сейчас я уже не так уверен, что решение проблем рич модели было бы дороже. И уж точно не сомневаюсь в праве рич моделей на жизнь.
О, прекрасно. Давайте поговорим об этом примере — нужно же понять, где неотъемлемые проблемы анемика, а где неправильная готовка. А то на вымышленных примерах обе стороны могут биться сколько угодно. Это сродни диалогу "а я брата приведу" — "а я двух двоюродных". При том что оба оппонента сироты.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Ziaw, Вы писали:

Z>>Пример из практики, при переводе на клиент-сервер одной из систем сделали из рич модели тощую, руководствуясь примерно теми же мотивами, что и ты декларируешь. Ядро логики мне не удалось изолировать так же хорошо как и в жирной, хотя я проектировал ее на три года позже чем жирную (смею надеяться, что за три года в голове прибавилось ). Реюз кода уменьшился и, как я ни старался, сейчас требуется намного больше знаний о системе для написания новой логики. Сейчас я уже не так уверен, что решение проблем рич модели было бы дороже. И уж точно не сомневаюсь в праве рич моделей на жизнь.
S>О, прекрасно. Давайте поговорим об этом примере — нужно же понять, где неотъемлемые проблемы анемика, а где неправильная готовка. А то на вымышленных примерах обе стороны могут биться сколько угодно. Это сродни диалогу "а я брата приведу" — "а я двух двоюродных". При том что оба оппонента сироты.

Мнк сложно описать эти проблемы не приводя в пример килобайты кода, схему данных, требования. Вполне возможно это неправильная готовка. Некоторые проблемы с реюзом запросов мог бы решить linq, но мне нужна поддержка oracle и firebird, так что как орм он не может быть использован.

Здравствуйте, Ziaw, Вы писали:

Z>Мнк сложно описать эти проблемы не приводя в пример килобайты кода, схему данных, требования. Вполне возможно это неправильная готовка. Некоторые проблемы с реюзом запросов мог бы решить linq, но мне нужна поддержка oracle и firebird, так что как орм он не может быть использован.
А, ну тогда спорить не о чем. Без linq анемика начинает очень жестко сосать — ей нужен адекватный язык для выражения запросов. Рич модель обходит эту тему с тыла, предлагая навигацию+LL.