Здравствуйте, Sheridan, Вы писали:
G>>Ну что ты будешь делать если добавится еще 100 пользователей? Или (предположим не добавится) когда база станет настолько большой, что все начнет тормозить? S>Поставлю еще один сервер БД
И как твой код будет определять к какой БД обратится?
Здравствуйте, Sheridan, Вы писали:
НС>>Тесты в студию. Хотя бы их результаты. S>Что именно ты хочешь увидеть?
Доказательства твоим словам, что твое приложение на порядок быстрее вордпресса на идентичной задаче.
НС>>Тогда ты пока что ничего не развеял. S>Что именно ты хочешь увидеть?
Здравствуйте, Sheridan, Вы писали:
НС>>Вот поэтому для работы с БД и нужно выбирать языки, в которых есть механизмы цитирования кода, а не С++. S>Пример пожалуйста.
Пожалуйста:
T GetUsers<T>(Expression<Func<User, bool>> filter, Expression<Func<User, T>> selector) {...}
...
var userNames = GetUsers(user => user.IsActive, user => new {user.FirstName, user.LastName});
А потом во вьюхе:
<div class="users">
@foreach (var name in userNames)
{
<div class="user">
<span>@name.FirstName</span>
<span>@name.LastName</span>
</div>
}
</div>
Заметь, на 100% статически типизированный код с минимумом лишнего мусора.
Здравствуйте, Sheridan, Вы писали:
S>Предложи тест, набросаю под него по свободе код. S>Только без фанатизма, типа "нагрузи полутысячью юзеров" — их у меня взять негде.
Я предложи? Откуда ж мне знать какие у тебя должны быть юзкейсы, требования, пользователи, объемы данных и прочее? Ты же софт пишешь.
Только что-то мне подсказывает, что пользователей у тебя десяток, количество запросов штук 10 в минуту максимум, данных в базе мегабайты. так?
Здравствуйте, genre, Вы писали:
G>>>Ну что ты будешь делать если добавится еще 100 пользователей? Или (предположим не добавится) когда база станет настолько большой, что все начнет тормозить? S>>Поставлю еще один сервер БД G>И как твой код будет определять к какой БД обратится?
Мой код? Зачем ему это? Для такого есть более правильные инструменты. Например
Здравствуйте, genre, Вы писали:
G>Я предложи? Откуда ж мне знать какие у тебя должны быть юзкейсы, требования, пользователи, объемы данных и прочее? Ты же софт пишешь. G>Только что-то мне подсказывает, что пользователей у тебя десяток, количество запросов штук 10 в минуту максимум, данных в базе мегабайты. так?
А ты не знай что у меня. Предложи своё. Или давай, например, сгенерируем все ip-адреса указанной какой нибудь подсети.
Здравствуйте, Sheridan, Вы писали:
S>Ну так масштабировать надо узкие места. Как правило это БД. При огромном числе запросов, когда начнут кончаться сокеты — пишется балансер, если один из существующих не подходит. Будет необходимость — разберусь. Ранняя оптимизация, знаешь ли, вредна
В БД ты не упрешься. Ну если не будешь (надеюсь) писать логику на SQL. А вот что ты планируешь делать если упрешься в процессор?
Здравствуйте, Sheridan, Вы писали:
НС>>Вот поэтому надо выбирать языки, в которых есть LINQ, а не С++. S>Объектную модель записей БД я и сам в состоянии построить.
Но продолжаешь чиселками номер поля указывать.
S> Но мне она не нужна. Лишняя прослойка между данными и результатом.
Ты просто не понимаешь как работает LINQ. Никакой проклейки нет — модель, при желании, может служить строго источником метаданных. linq2db даже умеет в качестве модели использовать интерфейсы, экземпляр которых невозможно создать в принципе.
Здравствуйте, genre, Вы писали: S>>Ну так масштабировать надо узкие места. Как правило это БД. При огромном числе запросов, когда начнут кончаться сокеты — пишется балансер, если один из существующих не подходит. Будет необходимость — разберусь. Ранняя оптимизация, знаешь ли, вредна
G>В БД ты не упрешься. Ну если не будешь (надеюсь) писать логику на SQL. А вот что ты планируешь делать если упрешься в процессор?
Я наверное неправильно написал. Щас перепишу понятнее. В скобках — примечания.
1. Ну так масштабировать надо узкие места. Как правило это БД. (у БД есть свои методы маштабирования)
2. При огромном числе запросов, когда начнут кончаться сокеты (или другие ресурсы) — пишется балансер, если один из существующих не подходит. Будет необходимость — разберусь.
Ранняя оптимизация, знаешь ли, вредна
Здравствуйте, Sheridan, Вы писали:
G>>Я предложи? Откуда ж мне знать какие у тебя должны быть юзкейсы, требования, пользователи, объемы данных и прочее? Ты же софт пишешь. G>>Только что-то мне подсказывает, что пользователей у тебя десяток, количество запросов штук 10 в минуту максимум, данных в базе мегабайты. так? S>А ты не знай что у меня. Предложи своё.
Интересно, как я могу предложить свое для тестирования, неизвестного мне, твоего? Или опять скорость виндовых гуев с помощью линуховых мерять собрался?
Здравствуйте, Sheridan, Вы писали:
S>Мой код? Зачем ему это? Для такого есть более правильные инструменты. Например
Вот смотри как замечательно. Еще десять тысяч ведер и мы выясним, что возможно это не единственный пример, а может, вместо написания веб сервиса на с++ можно взять более правильные инструменты.
Здравствуйте, Sheridan, Вы писали:
S>Ну так масштабировать надо узкие места. Как правило это БД. При огромном числе запросов, когда начнут кончаться сокеты
У тебя начнутся проблемы задолго до того как начнут кончаться сокеты. Вангую что больше 200 запросов/с твой код не осилит.
S> — пишется балансер, если один из существующих не подходит.
Здравствуйте, Sheridan, Вы писали:
S>1. Ну так масштабировать надо узкие места. Как правило это БД. (у БД есть свои методы маштабирования) S>2. При огромном числе запросов, когда начнут кончаться сокеты (или другие ресурсы) — пишется балансер, если один из существующих не подходит. Будет необходимость — разберусь. S>Ранняя оптимизация, знаешь ли, вредна
Как какое правило? С чего ты взял, что ты упрешься в БД?
