Domovoy

ReFeRy,прости засланца.(перечитал все написаное и вспомнил о чем вообще пост) Вот уж не думал что получится как в том анекдоте.

"Сажаю я ее на стол сдвигаю клавиатуру...
ух ты у тебя компьютер дома есть? А конфигурация какая"

надеюсь нигде буквами не ошибся заполняя форму

И кстати первый вопрос был как на стороне клиента превратить главу текста из чистого текста в html. Предлагаете классическую замену вида символы с кодами 10 и 13 менять на сочетание тегов /p p (импровизация на тему nl2br)?

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

Хрень говорите?
Первый вопрос который напрашивается: как превратить чистый текст в html на стороне клиента?
Второй вопрос: сколько дополнительных соединений в итоге обращающихся к интерпретатору породит простая загрузка страницы? 2, 3,5,60,100? Последние цифры абсурд но на днях в новостях мелькала цифра рекорда кажется в 500 запросов необходимых для отображения страницы.Пусть и с сторонней рекламой.
третий вопрос следует из второго: сколько Рабочих процессов единовременно будет при активности в 40-40 запросов в секунду? Сколько памяти они единовременно сьедят? или сколько клиенту придется ждать когда его страницу отдадут?
Какова вероятность что в потрохах сайта будет тяжелый фреймворк не экономящий память/процессорное время?

А теперь предполагаем что у нас пхп и апач. И получаем что сайт захлебывается при 300 просмотрах в минуту.

про такой вариант сборки страницы на стороне клиента я знаю но там овчинка выделки не стоит. любого кто скажет что надо следовать этой моде на высоконагруженном сервисе я первым пошлю в пешее эротическое путешествие с пожеланием питона в центр тяжести. Ибо результат будет тяжелее и для сервера и для клиента. Причем гораздо тяжелее. Тем более отдавать текст фанфика все равно придется в html

скорее из 1995го. ибо любимое количество памяти 8-32 кб. а частота 20 мгц

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

при минимум 300+ запросах в минуту к динамическому контенту, сайт откликается очень даже неплохо. от генерации html на сервере никуда не деться.

правда я чего то не понимаю в математике.

берем за топ 200 запросов в секунду каждый из которых сьест 20 мб памяти.
так же предполагаем что время ответа в таком пике будет составлять 4 секунды. получаем необходимое значение количества памяти порядка 25 гб.
предполагаем что 20+ гб памяти уходит на субд.
суть вопроса: я чего то не учитываю или
у вас значение по памяти взято с двукратным запасом на случай песца а ля ddos атака?

можно нескромный и немного интимный вопрос?
сколько дури требуется серверу под такой проект? (просто любопытство.) и сопутствующий вопрос: даст ли что-нибудь оптимизация?