Надоела реклама на фанфиксе?

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

Domovoy
От генерации html можно деться. Нынче популярно весь интерфейс/дизайн строить на JS, загружая шаблоны мелких блоков и отдавая данные в виде json с сервера. Правда при мало-мальски тяжелом интерфейсе этот подход будет требователен к пользовательскому железу.

На счет оперативки. Я не считал суммы, ибо там всё сложнее, чем подсчёт количества просмотров страниц. Но вообще-то ответ на любой запрос у интерпретатора занимает никак не больше 0,5 секунды, большинство страниц генерируются за ~0,1 секунды.

ReFeRy, кстати, если бы ещё была опция показа названия части в каждой главе части — вообще супер бы было.

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

Domovoy, простите, но вы хрень городите.

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

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

Domovoy
Погуглите о современных технологиях.
Если говорить простым языком: при переходе по конкретной ссылке, фанфикс может делать ровно тоже самое, что сейчас, тоже одним запросом, только убрать всю генерацию html, оформить все текстовые данные, которые нужно отобразить на этой странице, в json предопределённой структуры и готово - трафик меньше, запросов столько же, действий интерпретатора меньше. Дальше уже работает скрипт на стороне клиента. А на самом деле делается ещё чуть сложнее. Запрашиваются только данные, которые должны измениться. То есть, вся информация из шапки, сайдбара и футера вообще запрашивается всего один раз за сессию. Если же надо что-то там изменить, например, счетчик в личном меню, запрашивается буквально одна переменная, точнее даже не запрашивается, а получается от сервера вместе с результатами иного запроса.

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

Добавлено 14.08.2018 - 19:25:
Domovoy
Я отчасти понимаю ваш скептицизм, если вы мало следите за развитием отрасли. Помню, когда подобный подход только появлялся, так был написан twitter. И в итоге он оказался чрезвычайно тяжелым, особенно для смартфонов того времени. Потом я читал, что его полностью переписывали с использованием 100% предгенерации кэша. Типа юзер зашел на одну страницу, и в этот момент на бэкенде генерятся html-ки всех страниц, куда он может перейти дальше - юзер переходят, ему моментально отдают уже сгенеренную ранее html-ку.

Так вот, технологии уже давно оптимизированы, теперь подход SPA (https://ru.wikipedia.org/wiki/Одностраничное_приложение) работает быстро, если нормально написан :)

Domovoy, да, хрень. Вы даже вопросы бредовые задаёте, будто на самом деле из 2008 года :)

Давайте я вам объясню на небольшом примере с небольшими предположениями, взятыми с потолка.

Дано: юзер нажимает кнопку "Предыдущие 20 комментариев" в блогах.

Как сейчас:
1. Отправляется запрос на сервер
2. Сервер выбирает данные из базы (допустим 1КБ)
3. Сервер генерирует HTML-код из этих данных (допустим 20КБ)
4. Сервер отправляет эти 20КБ клиенту.
5. Клиент вставляет HTML-код в нужное место.

Как надо сделать:
1. Отправляется запрос на сервер
2. Сервер выбирает данные из базы (допустим 1КБ)
3. Сервер отправляет этот 1КБ клиенту
4. Клиент генерирует нужный HTML-код из этих данных и вставляет в нужное место.

Вы считаете, что первый способ лучше для сервера? Второй способ снижает нагрузку на сервер (генерация HTML), снижает нагрузку на вебсервер и трафик (отправка 1КБ вместо 20КБ данных).
Небольшой (подчеркиваю, небольшой) оверхед на клиенте на генерацию HTML абсолютно некритичен, потому что: 1) он совершенно незаметен; 2) всё равно это быстрее, чем ждать генерацию сервером и получать в 20 раз больше данных по сети.

В идеале, сервер должен отдавать только изначальную HTML-страницу с разметкой и бутстрапленными данными, нужными для генерации этой страницы. Дальше он должен только отвечать на вызовы API, передавая данные.

Пока писал — понял ваш второй вопрос.
Отвечаю: никто не дёргает сервер для маленьких кусочков данных. При первом заходе клиента данные вставляются в HTML-страницу (бутстрапятся) и отдаются клиенту, который и генерирует HTML из этих данных. CSS/JS/IMG вообще должны быть сжаты, и загружаться должны с CDN на другом домене (чтобы куки не посылались). Итого: 1 запрос вообще для загрузки первоначальной страницы.

Вот это будет оптимальная конфигурация. И рост количества клиентов не будет требовать пропорционального роста серверных мощностей, потому что основная работа (по генерации HTML) переложена на клиентов.

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

Domovoy, жму руку :)

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

Domovoy, а как, по вашему, это делается на сервере? Примерно так же. Шаблонизаторов полно, выбирай любой, или свой пиши. Но если говорить конкретно про текст фиков, а не про другой контент сайта, то да, примерно так — заменять \\0D и \\0A на </p><p>. Или разбить в массив по этим символам и склеить другими.

Добавлено 14.08.2018 - 21:29:
Тем более, что мы не знаем, может текст фиков в базе уже в HTML хранится. Бери да вставляй :)

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

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

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