spotifi: Разумеется. Но в кэш их не положишь.
Поэтому каждый посетитель будет создавать тяжелые запросы к диску.
А товара мало - все будет в кэше, и к диску запросов минимум.
В итоге на одного пользователя требуется гораздо меньше процессорного времени, я уж не говорю про объем памяти и нагрузке на диск.
spotifi: Еще раз - вы серьезно считаете что работа с БД размером 2Мб и 2Тб это одинаковая нагрузка?
И время потраченное на один запрос будет одинаковым при прочих равных?
spotifi: Я в курсе.
Просто согласитесь что для одинаково эффективной работы множества пользователей с БД в 2мегабайта и для работы с БД в 2террабайта железо нужно немного разное, при одинаковой эффективности ПО.
spotifi: От количества товаров в БД нагрузка в основном и зависит.
Сравните - магазин торгующий сотовыми - 300товаров в базе данных, база данных весит 5мегабайт.
и магазин торгующий автозапчастями - несколько миллионов автозапчастей в базе, база данных занимает примерно 2террабайта.
Для первого магазина памяти 1Гб будет с большим запасом, и база будет размещаться полностью в памяти.
Для второго магазина все хуже - два террабайта БД не запихаешь в 1гб памяти, и в 32Гб тоже.
Для первого магазина не нужен никакой поиск - пользователь зашел, полистал странички и оформил заказ.
Для второго магазина пользователь сначала ищет в базе каталожный номер запчасти, потом смотрит список запчастей с этим номером, и цены на них, сравнивает и только тогда покупает.
Как вам помогут векторные индексы, если у вас памяти мало, а база данных огромная?
Вы считаете, что нагрузка на интернет магазин зависит только от количества посетителей?
Сравните два магазина - у одного 5 товаров и тысяча посетителей, у другого 80тысяч товаров, и та же тысяча посетителей. Думаете нагрузка на сервер будет одинаковая?
Движок магазина может позволять производить сравнение характеристик товара - это нагрузка на сервер.
Нет такой фишки, и нагрузка в разы меньше.
Поэтому требуемая производительность сервера под интернет магазин может отличаться в сотни раз, при одинаковом количестве пользователей.
landergate: Виртуализация всегда добавляет довольно заметные накладные расходы.
А заметно это в разных случаях по разному.
Иногда практически не ощущается, иногда очень заметно.
Dim: На стол физически не уместить более двух сотен ярлыков и файлов.
А чтобы это сказалось на быстродействии - надо уместить несколько десятков тысяч.
Индекс на быстродействие влияет мало.
Обновление времени доступа - практически не влияет.
1)Зачем перекидывать медиа в неиндексируемые места? Их как правило надо индексировать, иначе замучаешься искать. Если индексировать не надо, можно отключить индекс.
2)Профиль никак не проверяется при старте. Вообще никак. Загружается необходимые данные из профиля, и больше ничего.
3)При чем тут медиа? Речь вроде не про медиа.
А даже если и медиа- что плохого в хранении медиа на системном диске? Не у каждого есть второй диск.
4)Никаких проблем это не создает, и причиной тормозов не является ни в коем случае.
5)Количество ярлыков могло создавать проблемы лет этак пятнадцать назад, когда память измерялась десятками мегабайт. Сейчас когда память измеряется гигабайтами это просто смешно. Не влезет на стол столько ярлыков, чтобы заметно нагрузить память и создать проблемы.
alexdora: Если сильного ветра нет, не проблема. Зонд будет подниматься строго вверх, при минимуме помех принимаешь картинку - на 30км запросто.
А если будет ветер - зонд унесет и плакала связь.
По поводу 300баксов за комплект - вы спросите сколько стоит комплект для приема этой передачи. :)
У вас речь про вертушку - если он будет висеть в точке, не проблема, если будет подниматься строго вверх, тоже не проблема.
А если он на крейсерской скорости 180км/ч будет лететь над землей, то придется через каждые 20км ставить БС.
Поэтому каждый посетитель будет создавать тяжелые запросы к диску.
А товара мало - все будет в кэше, и к диску запросов минимум.
В итоге на одного пользователя требуется гораздо меньше процессорного времени, я уж не говорю про объем памяти и нагрузке на диск.