↓
 ↑
Блог администратора Просмотр новости

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

20 мая 2018

Напоминаю о возможности отключить рекламу на всём сайте, для всех устройств.

Всего 100 рублей в месяц, а при оплате за 6 или 12 месяцев и того меньше, и у вас чистый от рекламы сайт, который загружается гораздо быстрее. Особенно при просмотре с телефона по мобильному интернету.

Вырученные деньги тратятся на оплату сервера. К сожалению, стоимость сервера только растёт. Вот недавно взыграл очередной кризис, евро поднялся в цене, и ежемесячная плата выросла на 7%.


Немного статистики:

В 2017 году донат от пользователей (за отключение рекламы и безвозмездные переводы) покрыл 45% расходов на сервер.

За 4 месяца 2018 года ситуация сильно улучшилась, донат покрыл 88% расходов.



Комментарии
Показано 10 из 28

Показать предыдущие 10 комментариев

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

Переводчик
Редактор
Комментариев 639
Рекомендаций 2
Domovoy, простите, но вы хрень городите.
 

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

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

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

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

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

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

Переводчик
Редактор
Комментариев 639
Рекомендаций 2
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) переложена на клиентов.
 

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

Переводчик
Редактор
Комментариев 639
Рекомендаций 2
Domovoy, жму руку :)
 

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

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

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

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

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

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

Если вы не зарегистрированы, зарегистрируйтесь
Имя:
Пароль:
 
Войти при помощи:

ПОИСК
ФАНФИКОВ


Активные конкурсы








Поддержи проект рублёмЧтобы Фанфикс рос большим

бесплатный фотохостинг создан специально для пользователей Fanfics.me

Книги жанра ЛитРПГ
Опубликуй свою книгу!

Следи за любыми произведениями с СИ в автоматическом режиме и удобном дизайне

О-о-о-очень длинные истории про Марти Сью и их подружек!

Старейший в рунете архив фанфиков





Закрыть
Закрыть
Закрыть