А вы протестируйте сами. Нагоните ботов на оба сайта, по нарастающей, и посмотрите при какой активности ботов они лягут...

Мне кажется хватит на очень очень много уников

Цитата
workbench пишет: А вы протестируйте сами. Нагоните ботов на оба сайта, по нарастающей, и посмотрите при какой активности ботов они лягут...

Очень смешно. Вам лет сколько? 12? 13? Попробуйте такие манипуляции со своими проектами лучше провести. А я как-нибудь обойдусь.

Цитата
Limon пишет: многое еще зависит от того, какие плагины стоят, как они настроены, то же кэширование может в несколько раз снизить нагрузку.

Я написал, что меня интересует уровень посещаемости в стандартной конфигурации. Само собой у меня уже настроено кеширование и имеются плагины снижающие нагрузку. Мне хватило бы примерной цифры для стандартного конфига сервака. Остальное сам дофантазирую.

Цитата
gensokolsky пишет: Мне кажется хватит на очень очень много уников

Вы просто капитан очевидность)))))

Цитата
Js пишет: Если ничего сложного не стоит скажем с выводом на несколько страниц контента на 1000 материалов, то выдержит до 800 он лайн и примерно 15 000 хостов А если немного криво все делается, то у меня такой лег при 600 он лайне. Пришлось базу данных в облако засунуть

Обычные статейные сайты. На страничке выводится по 8 материалов, обрезанных тегом more. одним словом, все как у остальных.))) А 15 000 уников в общем на сервак, я надеюсь правильно вас понял?

Конфигурация здесь ни при чем.Здесь более вопрос программной настройки, и характера действий.
У меня в онлайне крутилось около 200 человек, на Raspberry Pi (700Мгц+512 памяти).

Онлайн. Что такое онлайн ? Сидят люди и читают новости ? Или пишут комментарии ? Или это чат ?
Если сайт на вордпрессе, это блог, и он будет крутиться на убунте-апаче-мускуле-пыхе, то даже в этом случае он выдержит тысячи человек онлайн.
Кто-то из них получит респонс от сервера за 1 секунду, кто-то за 1.4 секунды.
Если они будут одновременно писать комменты - то база будет подтормаживать.

Если твой сайт будет выводить все комментарии из десятитысячного списка по запросу к БД с джоинами - то сайт не выдержит и десятка в онлайне.
А поставишь ligghtpd\nginx + php-fpm + mariadb - сайт выдержит десятки, а то и сотни тысяч человек онлайн.
Оптимизируешь базу и запросы - ускоришь коннект.

Это все субъективно, я бы тебе посоветовал поставить какой-нибудь проект, и провести стресс-тест сего чуда.

Цитата

Кот Саханчук пишет: Цитата Gman пишет: Сервис есть в сети соответствующий, как протрезвею ссылку кину Буду ждать. Спс Цитата Vitaliy Blats пишет: Оптимизируешь базу и запросы - ускоришь коннект. А можно про это по подробней. Или хотя бы линк на путнее чтиво. Цитата Vitaliy Blats пишет: Это все субъективно, я бы тебе посоветовал поставить какой-нибудь проект, и провести стресс-тест сего чуда. Навряд ли смогу потестить. Сам в администрировании дуб дубом. Через ТП хостинга установили на сервак eAcceleretor. Ну и пару плагинов для самого акселератора. Как уже говорил выше, на серваке два вордпресс сайта. Вместе жрут около 350 Мб. Еще 150 Мб кешировано. Свободно всегда показывает порядка 700 Мб. Посещаемость одного сайта около 300 уников в сутки. Второй проект без посещалки. Новый так сказать.

Ну если ты говоришь, что у тебя wordpress, то в структуре запросов врядли что-то сможешь оптимизировать.
А вот структуру БД вполне можно. По мелочи. Например, числовые поля, там где размер будет заведомо меньше какой-то величины, поменять тип данных с INT на MEDIUMINT и так далее. TEXT, поменять на VARCHAR, в таком духе.
Включить mysql long query logging в /etc/mysql/my.cnf; Узнать какой размер временных таблиц, и подрихтовать значения кешей.

700 Мб - это место на диске, или ОЗУ ?

Для посещаемости сайта 300 уника в сутки, тебе хватит древнего смарта на андроиде
Узкое место любого сайта - входящее соединение.
Если количество одновременных коннектов превышает норму - остальные отсекаются, т.е. сайт в дауне. Поэтому я и не люблю apache

Если очень хитромудрый запрос в базу, с селектами, джойнами, ордерами и сортами - для каждого подзапроса создается таблица, потом данные парсятся и выводятся, либо заполняются еще в одну таблицу. В общем выполняются долго.
Вот например select DISTINCT(userid) from users order by userid desc будет выполняться за два или даже три захода. Имеет смысл делать сортировку на уровне скрипта.
В случае медленных баз, просто сайт будет долго выполняться.

В этом случае есть риск превышение лимита подключений к веб-серверу.
В общем долго и геморрно. Надо смотреть по месту.