Differences

This shows you the differences between two versions of the page.

--- ru:faq [2024/10/29 09:00] – [Server Load] admin
+++ ru:faq [2026/06/22 17:23] (current) – [How to test script] admin
@@ Line 35: / Line 35: @@
 те tube_embed_switch_rules выключен только для первого клика.
-===== Приоритет скиминга =====
+===== Skim Priority by Entity =====
-Ским указанный в урле имеет приоритет над всеми остальными вариантами.
+По умолчанию Ским указанный в урле имеет приоритет над всеми остальными вариантами.
 Если ским в урле не указан - проверяются персональные сетинги трейдеров.
 Если и тут ским не указан - используется дефолтный ским из сетингов.(CJSettings - Content Settings - Default skimming)
-Но при желании это поведение можно менять, порядок выбора скима меняется в сетингах. Можно таскать параметры вверх вниз по приоритетности.
+При желании это поведение можно менять, порядок выбора скима меняется в сетингах.
+Можно таскать параметры вверх вниз, меняя порядок приоритета.
@@ Line 282: / Line 283: @@
   * rewrites - если у вас Apache то htaccess, если nginx то в его конфиге
-===== "Прокладка" для out.php  =====
-Иногда возникает необходимость в реализации или тестировании какой-то функциональности, которой еще нет в скрипте. Если это касается кликов то проще всего сделать следующим образом. Например, нам надовыставить персональный ским для галер на домене gallery.com (при этом ским для галер на доменах gallery1.com gallery2.com остается дефолтным).
-  * out.php переименовываем в out_scj.php
-  * out.php делаем такой
-<code>
-<?php
-if ($_GET['url']) {
-$tmp = parse_url($_GET['url']);
-if ($tmp['host'] == 'gallery.com') $_GET['p'] = 50;
-}
-include('out_scj.php');
-</code>
@@ Line 375: / Line 359: @@
 ===== Сколько сайтов потянет сервер такой-то ... ? =====
-Вопрос из разряда "сколько коробочек влезет в жигули ?" это на 100% зависит от веса коробочек, их размера и желания максимально отптимально их там распихивать.
+Вопрос из разряда "сколько коробочек влезет в машину?" это на 100% зависит от веса коробочек, их размера и желания максимально оптимально их там распихивать.
+Например, сайт это и 1 индексная страница, которую можно закешить и отдавать с огромной скоростью
+М галер в базе с 3 вида сортировки , 500 категорий, 100к тагов,  поиск фильтрация, 10 кастом переменных и тп - это тоже 1 сайт.
+Оставить поиск на mysql - одна нагрузка, не лениться настроить сфинкс - другая нагрузка и тд.
 ===== Mysql Backup =====
@@ Line 681: / Line 671: @@
 В общей стат и стат каждого трейдера есть список урлов на которые приходит траф.
+====== Outlist and Priority ======
+В этом в целом заключается вся раздача трафика.
+Трейдеры получают приоритет по расчету Trade Formula. А так же по форсам (например 1 fast force прибавляет 10000 к приоритету что бы трейдер оказался выше по приоритету).
+Крон раз в минуту расставляет трейдеров по приоритету в список outlist (settings - out settings).
+При каждом клике на аут мы пошлем на трейдера с соответствии с вероятностью в outlist.
+Выводы которые надо понять:
+. если трейдер на первой позиции outlist (и по приоритету) - не факт что он получит первый же клик
+. если у вас в outlist 10 позиций, то в конкретную минуту хиты получают топ 10 трейдеров по приоритету
+. если вы поставили форсов больше чем позиций в листе, то они буду отданы по очереди, а не все сразу (и конечно форсов не должно быть больше чем трафика)
 ====== Page Track ======
@@ Line 702: / Line 709: @@
+====== How to count with JS ======
+Для обратной совместимости, в целом как мне кажется не имеет смысла.
+Если вы хотите считать только ины то можно поставить JS счетчик следующим кодом:
+<code>
+<script
+  src="http://your_domain/scj/cgi/pixel.js"
+  data-endpoint="http://your_domain/scj/cgi/include.php"
+></script>
+</code>
 ====== Server Load ======
@@ Line 712: / Line 730: @@
 Если есть желание смотреть дальше чем "мне админ сказал" и вы можете проверить базовые вещи на серваке, то имеет смысл читать дальше.
-Нагрузку на сервер можно сравнить куда по одной трубе затекает вода, а по другой уходит. Не бывает "нагрузка 120% но сервер держится!". Либо поступает меньше воды, чем может уйти и все хорошо, либо бассейн начинает наполняться и через какое-то время переполнится. В зависимости от емкости бассейна можно какое-то время лить больше воды, чем уходит, но до определенного предела и условно если подавать 150% от пропускной способности трубы, то бассейн переполниться через минуту, а при 101% - через условно час.
+Нагрузку на сервер можно сравнить с ситуацией когда по одной трубе вода затекает в бассейн, а по другой уходит. Не бывает "нагрузка 120% но сервер держится!". Либо поступает меньше воды, чем может уйти и все хорошо, либо бассейн начинает наполняться и через какое-то время переполнится. В зависимости от емкости бассейна можно какое-то время лить больше воды, чем уходит, но до определенного предела и условно если подавать 150% от пропускной способности трубы, то бассейн переполниться через минуту, а при 101% - через час.
 Что такое переполнение бассейна, пример ближе к реальности:
-На серваке работает apache, mysql и сервер отдает файлы (статику).
+На серваке работает apache (вебсервер), mysql и сервер отдает файлы (статику).
 % памяти - кеш статики
 % - апач
@@ Line 723: / Line 741: @@
 Например, mysql может обрабатывать 100 запросов в минуту.
-Если давать 110 то запросы будут становиться в очередь, в памяти будет выделяться место где хранить данные запроса. Из-за этого mysql займет например 60% памяти, а для статики останется 20%. Из-за того что статика не кешится - сервер начинает больше читать с диска, занимая производительность диска. Из-за этого mysql, который так же работает с диском, падает в макс производительности со 100 до 90 запросов, получается очередь формируется уже не с превышением 10%, а с превышением грубо 20% (90 сейчас максимальная, а мы все так же даем 110).
+Если давать 110 то запросы будут становиться в очередь, в памяти будет выделяться место где хранить данные запроса. Из-за этого mysql займет например 60% памяти, а для статики останется 20%. Из-за того что статика не кешится - сервер начинает больше читать с диска, занимая производительность диска. Из-за этого mysql, который так же работает с диском, падает по производительности с 100 до 90 запросов, получается очередь формируется уже с превышением не 10%, а грубо 20% (90 сейчас максимальная, а мы все так же даем 110).
-Это увеличивает скорость роста очереди, еще больше выдавливает статику из памяти = еще больше нагружает диск = еще больше падает производительность mysql = быстреенарастает очередь пока в какой-то момент не заканчивается память.
+Это увеличивает скорость роста очереди, что еще больше выдавливает статику из памяти = еще больше нагружает диск = еще больше падает производительность mysql = быстрее нарастает очередь пока в какой-то момент не заканчивается память.
-Вот почему "все было хорошо, а только добавил всего чуть чуть" - приводит не к тому что все "чуть чуть медленее работает из-за перегруза", а перегруз приводит к падению всего.
+Поэтому "все было хорошо, а только добавил всего чуть чуть" - приводит не к тому что все "чуть чуть медленее работает из-за перегруза", а перегруз приводит к падению всего (резкой деградации производительности всего)
-Иногда админ настраивает сервер немного сложнее и сервер может пропускать запросы, когда начинает перегрузка (условно пошло 110 запросов), то сервер просто 10 пропускает и серфер не видит сайт, но зато все довольны: админа не дергают, владелец не напрягает голову что б вникнуть что не так, только теряется траф.
+Иногда админ настраивает сервер немного сложнее и сервер может пропускать запросы, когда начинает перегрузка: условно пошло 110 запросов, то сервер просто эти 10 запросов пропускает, серфер не видит сайт, но зато все довольны: сервер не перегружен, админа не дергают, владелец не напрягает голову что б вникнуть что не так, только теряется траф.
@@ Line 739: / Line 757: @@
 **Начнем с веб части.**
-Надо взять ваш любимый вариант просмотра нагрузки сервака и проверить что в основном нагружает сервер. В целом есть 3 части: проц, память и диск. Есть еще пропускная способность канала, но тут можно пропустить ее.
+Надо взять ваш любимый вариант просмотра нагрузки сервака и проверить что в основном нагружает сервер.
+В целом есть 3 части: проц, память и диск. Есть еще пропускная способность канала, но тут можно пропустить ее.
 . Процессор: если в топе по нагрузке висит вебсервер (условно апач, nginx, php-fcgi and so on), те все что формирует страницу сайта и показывает ее серферу, то скорее всего у вас есть что-то тяжелое в темплейте. [[new_rotation_templates#how_it_works]]
-Кратко: темплейт обрабатывается в 2 шага: сначала заменяются таги скрипта, на актуальные данные, условно <!--ALT--> заменяется на актуальный текст. Потом выполняется темплейт как пхп что б выполнить ваш пхп код.
+Кратко: темплейт обрабатывается в 2 шага. Сначала заменяются таги скрипта, на актуальные данные, условно <!--ALT--> заменяется на актуальный текст. Потом выполняется темплейт как пхп что б выполнить ваш пхп код.
-После шага 1 темплейт кешится [[new_rotation_faq#what_is_cache]], это значит что если в темплейте нет пхп кода, а есть условно только <!--ALT--> то при запросе той же страницы сервер не будет что-то обрабатывать, а сразу достанет готовый html из кеша. Это очень быстро.
+После шага 1 темплейт кешится [[new_rotation_faq#what_is_cache]], это значит что если в темплейте нет пхп кода, а есть условно только <!--ALT--> то при запросе той же страницы сервер сразу достанет готовый html из кеша. Это очень быстро.
 Но часто в темплейтах есть инклуды своего пхп кода. Надо помнить что этот код выполняется на каждый запрос каждой страницы и при его  написании помнить что можно что-то кешировать и тп.
+mysql: если в топе mysql, то вероятно не оптимизирован какой-то из запросов. Из того что есть тияжелое в скрипте: это максосы <thumb order=rand потому что rand - очень тяжелая операция для mysql (в скрипте есть easy_rand который немного решает проблему)
-mysql: если в топе mysql, то вероятно не оптимизирован какой-то из запросов. Часто это бывают максосы <thumb order=rand потому что rand - очень тяжелая операция для mysql, в скрипте есть easy_rand который немного решает проблему.
+Либо поиск: mysql ищет намного медленее чем sphinx (надо переходить на mysql fulltext or sphinx)
-Либо поиск: mysql ищет намного медленее чем sphinx.
@@ Line 758: / Line 776: @@
-. Память и Диск - связаны, что и логично: если вам надо отдавать файл header.jpg на каждый запрос, то вы его либо кеширувете в памяти и отдаете вообще не обращаясь к диску, либо каждый раз читаете с диска. Чтение с диска примерно в 1000 раз сложнее.
+. Память и Диск - связаны, что и логично: если вам надо отдавать файл header.jpg на каждый запрос, то вы его либо кешируете в памяти и отдаете вообще не обращаясь к диску, либо каждый раз читаете с диска. Чтение с диска примерно в 1000 раз сложнее.
 В среднем mysql пытается загрузить в память как можно больше базы, что бы не обращаться к диску за данными и, если хватает памяти, то загрузит всю базу в память. После этого обращения к диску будут только для записи статистики кликов и при пересчете ctr.
@@ Line 766: / Line 784: @@
 Если траф приходит только на главную страницу, то нам важно загрузить в память html + всю статику этой страницы, что б отдавать сразу не обращаясь к диску. Если приходит на все 100 галер, то важно держать базу в памяти, что б формировать страницы не обращаясь к диску.
-Например, вы выбрали загрузить всю базу в память, но у вас траф приходит только на пару страниц где не хватает памяти кешить статику - получается что вебсервер (апач nignx) постоянно читают с диска, и сайт открывается но все медленно грузится.
+Например, вы выбрали загрузить всю базу в память, но у вас траф приходит только на пару страниц. Из-за базы не хватает памяти кешить статику = вебсервер (апач nignx) постоянно читают с диска, и сайт открывается, но медленно грузится.
 Понятно что эти параметры не переключаются из скрипта. Тут как обычно есть 2 варианта: либо вы тратите время что б разобраться в своей ситуации и настроить оптимально сколько mysql может занять памяти, либо заливаете проблему деньгами, те просто берете сервак где больше памяти и все влезает в память.
@@ Line 782: / Line 800: @@
-Из всего этого следует сакратльный вопрос: **сколько сайтов потянет сервер такой-то ... ?** Это вопрос из разряда “сколько коробочек влезет в машину?” это на 100% зависит от веса коробочек, их размера и желания максимально оптимально их там распихивать.
+Из всего этого следует вопрос: **сколько сайтов потянет сервер такой-то ... ?** Это вопрос из разряда “сколько коробочек влезет в машину?” это на 100% зависит от веса коробочек, их размера и желания максимально оптимально их там распихивать.
+====== How cache works ======
+Как работает кеширование в интернет
+<code>
++------------------+
+|  Пользователь   |
++------------------+
+         |
+         v
++------------------+
+|     Браузер     |
++------------------+
+         |
+         |
+         v
++----------------------------------+
+|        Кэш браузера              | если тут закеширвоать страницу то ни сервер
++----------------------------------+ ни скрипт никогда не узнают что
+         |                           пользователь открывал URL
+         v
++----------------------------------+
+|        CDN                       | Аналогично и тут, запрос еще не дошел до сервера
++----------------------------------+
+         |
+         |
+         v
++----------------------------------+
+|     Веб-сервер                   |
+|   (Apache / Nginx)               |   Веб-сервер может закешировать страницу полностью
++----------------------------------+   и скрипт не узнает что было  обращение к странице
+         |        \
+         |         \ обращение
+         |          v
+         |   +--------------------+
+         |   |  Серверный кэш     |
+         |   | (файлы / Redis)   |
+         |   +--------------------+
+         |
+         |
+         v
++----------------------------------+
+|     Скрипт / Приложение          |  тут скрипт уже знает что было обращение
++----------------------------------+
+         |        \
+         |         \ обращение
+         |          v
+         |   +--------------------+
+         |   |   Кэш данных       |
+         |   | Redis \ memcache   |
+         |   +--------------------+
+         |
+         v
++------------------+
+|   База данных    |
++------------------+
+</code>
+**Как браузер получает страницу и где в интернете появляется кэш**
+Когда пользователь вводит адрес сайта в браузере, кажется, что браузер «просто идёт на сервер и получает страницу».
+На самом деле браузер старается не ходить на сервер, если это возможно.
+Вся система интернета устроена так, чтобы:
+  * получить ответ как можно быстрее
+  * пройти как можно меньшее расстояние
+  * задействовать как можно меньше серверов
+Для этого используются кэши.
+**Шаг 1. Браузер и кэш браузера**
+После ввода адреса браузер сначала проверяет: «А у меня уже есть эта страница?»
+Браузер может хранить:
+  * готовую HTML-страницу
+  * стили
+  * JS скрипты
+  * изображения
+Если нужные данные уже есть в кэше браузера:
+  * никакого запроса в интернет не происходит
+  * сервер вообще ничего не узнаёт о пользователе
+  * страница открывается мгновенно
+Это самый быстрый вариант.
+**Шаг 2. DNS — поиск адреса сервера**
+Если браузеру всё-таки нужно идти в интернет, сначала он должен понять:
+«Куда идти?»
+Для этого используется DNS. DNS переводит имя сайта в IP-адрес
+**Шаг 3. CDN — сервер ближе к пользователю**
+После DNS запрос идёт не обязательно сразу на основной сервер сайта.
+Между браузером и сервером может находиться CDN — сеть серверов в разных странах.
+Пример: основной сервер находится в Европе, пользователь — в Южной Америке
+Если всегда обращаться в Европу:
+  * сигналу нужно пройти большое расстояние
+  * страница будет загружаться медленно
+CDN работает так:
+  * первый запрос идёт на основной сервер
+  * ответ сохраняется на сервере CDN ближе к пользователю
+  * следующие пользователи получают страницу быстрее
+CDN удобно использовать для контента, который не меняется на каждый запрос
+    * если CDN отдаёт ответ из кэша, запрос не доходит до основного сервера
+    * скрипт ничего не узнаёт о пользователе
+**Шаг 4. Веб-сервер (Apache / Nginx)**
+Если CDN не смог отдать страницу, запрос приходит на веб-сервер. Веб-сервер — это программа, которая принимает HTTP-запросы.
+У веб-сервера есть выбор:
+  * отдать готовую страницу (если он откуда то знает что надо отдать)
+  * передать запрос дальше в скрипт
+Если у веб-сервера есть готовый ответ:
+  * он сразу возвращает страницу
+  * скрипт не запускается
+  * скрипт не знает, что был запрос
+  * Apache может передать запрос скрипту 1 раз и закешировать ответ
+Важный момент: что такое серверный кэш. Серверный кэш — это не часть веб-сервера и не часть скрипта.
+Это:
+  * отдельное хранилище
+  * файлы, память или Redis
+  * грубо это как отдельная коробка в которую могут складывать данные кто угодно кто работает на сервере
+Еще раз для понимания. В серверный кеш могут писать:
+  * веб-сервер
+  * скрипт
+  * оба одновременно
+Шаг 5. Скрипт (приложение)
+Если запрос дошёл до скрипта:
+  * скрипт точно знает, что был пользователь
+  * может записать статистику
+  * может принять решения сформировать страницу снова или отдать из кеша
+**Скрипт формирует страницу из данных.**
+Важно: кэшироваться может не только вся страница, но и отдельные данные.
+**Пример:**
+  * название сайта хранится в базе и почти не меняется
+  * текущая дата должна быть новой каждый раз
+Тогда: название сайта можно взять из базы 1 раз и сохранить в кеше, а дата формируется заново каждый раз
+Те закеширована не вся страница, а только определенные данные из которых сформирована страница. те HTML создаётся каждый запрос, запросы есть, но нагрузка на базу данных почти отсутствует
+**Шаг 6. База данных**
+Если данных нет ни в каком кэше:
+  * скрипт обращается к базе
+  * база читает данные (тут варианты - если хватает памяти Mysql держит данные в памяти, если не хватает - читает с диска)
+  * страница полностью формируется заново
+**Что из этого всего надо понять**
+  * если запрос не дошел до скрипта - скрипт про него просто не узнает
+  * page cache, Redis, memcache, серверный кеш и еще куча слов - это не важно, это просто название "коробочек" куда складываются данные. Важно только в каком пункте и что именно вы кешируете
+**Как используется память под кеш**
+  * базово данные хранятся в файлах
+  * база данных (mysql) может данные держать в памяти если хватает памяти и достаточно выделено в конфиге mysql
+  * redis (и любой другой кеш) так же как и база стараются хранить данные в памяти но если не хватает - скидывает в файл