Icecast2 - почему вы дергаете статистику с помощью PHP?

29.08.2011

epic fail ))))

29.08.2011

я в первый раз об этом слышу)) спс теперь буду знать.

что в этом такого эпичного?

29.08.2011

no comments

29.08.2011

и?

29.08.2011

Ну ты постучись ещё тогда уж) или пришли мне свои контакты на почту)

30.08.2011

побуду слоупоком по времени ответа ;)

сбрасывать нагрузку с сервера на пользователей это плохой тон.

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

и да, я не люблю js

01.09.2011

именно так я и делал когда пользовался не измененным айскастом.
раз в 4 секунды дампил всю статистику одновременно обрабатывая ее в нужном мне виде. и потом просто дергал этот дамп не трогая айскаст через javascript клиентами.
но это и так логично и любой здравомыслящий программист именно так и сделает.
в данном случае речь шла о формате вывода для тех кто пользуется стандартными php скриптами которые дергают сервер каждый раз.
сразу json который приятнее,быстрее,лучше как для javascript(на клиенте или сервере) так и для php, ruby, python итд.
а что плохой тон - решать владельцу сайта. пихать картинки в шаблонах/стилях, использовать анимацию на javascript - тоже плохой тон во времена HTML5/CSS3.

04.09.2011

как дернуть информацию из этого json подскажи, напиши пример

04.09.2011

Ребят ну напишите уже кто нибудь

04.09.2011

ajax-ом )

04.09.2011

у меня не вышло.....

21.09.2011

Потому, что кэшируем страницу, в т.ч. число слушателей.
Но спасибо за совет с JSON — красиво.

21.09.2011

а полученный json можно хранить в Cookies или HTML5 LocalStorage) или тоже кешировать.
ну и все делается на стороне клиента используя CPU клиента что дает сервачку возможность "остыть" и не работать лишний раз.

23.09.2011

еще немного на тему этого: вконтакте при загрузке фоток уменьшает их на стороне клиента. сервер при этом только принимает уже сжатые и обработанные фотки.
плохо это не уметь использовать ресурсы клиентов в своих целях и на благо пользователям)

12.12.2011

Очень плохой способ. Я думал намного лучше будет.
Если в тегах будет символ кавычки, то он пойдет в ответ как есть, а не в виде quot, в результате все крешется
Происходит это потому, что айскаст юзает libxml2, а она очень хитро это дело обрабатывает (сделал патч тегов, но либа развернула обратно). Патчить либу на стал, сделал себе няшную сохранялку при смене трека.
Второй недостаток в том, что при каждом реквесте мы насилуем айскаст и генерим новый жсон, что жрет ресурсы.


Ну это вообще пушка. Откуда клиенту знать, до каких пор его кешировать? В этом и весь смысл поллинга, что клиент как можно чаще обращается к серверу, а тот отдает обновления по мере изменений.

При этом можно еще немного байтиков заработать: у меня сохраняются json-файлики последовательно, т.е. 1, 2, 3... и т.д, что позволяет плееру дергать только последний. А пока последнего нету - клиенту отдается 404. Как только тег сменился, появляется новый файлик, клиент его получает и долбит уже следующий. Небольшая, но экономия.

17.12.2011

Статьи про здоровье и правильное питание, **********
симптомы болезней, информацию про народную медицину.
**********
У нас вы найдёте различные медицинские услуги, **********
здоровье человека, диеты, лечение болезней.

Добавлено спустя 2 минуты 57 секунд:
Статьи про здоровье и правильное питание, **********
симптомы болезней, информацию про народную медицину.
**********
У нас вы найдёте различные медицинские услуги, **********
здоровье человека, диеты, лечение болезней.

Добавлено спустя 6 минут 52 секунды:
Статьи про здоровье и правильное питание, **********
симптомы болезней, информацию про народную медицину.
**********
У нас вы найдёте различные медицинские услуги, **********
здоровье человека, диеты, лечение болезней.

17.12.2011

На первый взгляд всё вроде бы и правильно, но айскаст этот json-вывод отдает не как статику, а генерирует каждый раз по-новому. И даже если бы это была статика, Icecast по этим вопросам лучше не трогать, для этого есть Nginx, Lighttpd и иже с ними. Не зря ведь в конфиге айскаста под clients подразумеваются не только слушатели, но и любые другие клиенты, подключившиеся к нему. И если перекинуть на него ещё и запросы всех слушателей, нагрузка, как здесь уже правильно заметили, увеличится во много раз. Ведь один раз в несколько секунд запрос на генерацию будет отправлять не один PHP-скрипт, а несколько десятков/сотен/etc. клиентов. В результате сомнительный выигрыш в производительности переростает в серьезную угрозу. И пока один сервачок, который мог бы и поработать, будет "остывать", другой, который лучше бы без необходимости лишний раз не трогать, отвалится и растеряет всех слушателей. Перечитай свой же пост **********, точнее подпись к демотиватору, на редкость не бестолковую.

Хотя сама идея с распределением нагрузки правильная. Было бы разумно настроить сбор статистики по айскастам все-таки PHP-скриптом с последующим сохранением результатов в статический json-файл, который уже, в свою очередь, будет раздаваться клиентам.

Я сто лет назад подобное уже делал, правда с другой целью. Вот мой вариант status.xsl с json-выводом. Проверялось PHP-функцией json_decode(), работает. То, что переносы не расставлены -- это так надо.

1. <?xml version="1.0" encoding="UTF-8"?>
2. <xsl:stylesheet
3. xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="2.0"
4. xmlns:js="http://muttmansion.com">
5. <xsl:output method="text" />
6. <xsl:template match="/icestats">var sources = [<xsl:for-each select="source">
7. <xsl:if test="position() > 1">,</xsl:if>
8. {mount:'<xsl:value-of select="@mount" />',<xsl:if test="name">name:'<xsl:value-of select="name" />',</xsl:if>
9. <xsl:if test="server_type">content_type:'<xsl:value-of select="server_type" />',</xsl:if>
10. <xsl:if test="stream_start">stream_start:'<xsl:value-of select="stream_start" />',</xsl:if>
11. <xsl:if test="bitrate">bitrate:'<xsl:value-of select="bitrate" />',</xsl:if>
12. <xsl:if test="quality">quality:'<xsl:value-of select="quality" />',</xsl:if>
13. <xsl:if test="listener_peak">listener_peak:'<xsl:value-of select="listener_peak" />',</xsl:if>
14. <xsl:if test="genre">genre:'<xsl:value-of select="genre" />',</xsl:if>
15. <xsl:if test="description">description:'<xsl:value-of select="description" />',</xsl:if>
16. <xsl:if test="server_url">server_url:'<xsl:value-of select="server_url" />',</xsl:if>
17. <xsl:if test="artist">artist:'<xsl:value-of select="artist" />',</xsl:if>
18. <xsl:if test="title">title:'<xsl:value-of select="title" />',</xsl:if>
19. <xsl:if test="url">url:'<xsl:value-of select="url" />'</xsl:if>listeners:'<xsl:value-of select="listeners" />'}</xsl:for-each>
20. ];</xsl:template></xsl:stylesheet>

Добавлено спустя 2 минуты 37 секунд:

причем 11 секунд ушло на размышление
лол программисты блеать

17.12.2011

И опять не починены кавычки. Да еще и одиночные, которые постоянно встречаются в тегах вида Prishla osen'

Генерировать статику через поллинг статистики - двойной идиотизм. Клиенту нужны свежие данные, а не когда оно там в очередной раз просрется. Неужели так сложно залезть в стату и прикрутить сохранение файла?

17.12.2011

Писал под себя, и, как указал ранее, под другие цели. Поэтому вопроса с кавычками не возникало. Если у Вас есть какие-либо наработки по этому поводу, имеет смысл опубликовать их здесь, дополнив тот или иной предложенный код, вместо ведения многозначительных, но в то же время пустых разговоров вокруг да около. Ну или не вести их вообще, если хотите держать свои наработки при себе (на что имеете полное право, которое никто не оспаривает). То же самое и с вопросом сохранения файла. Подход крайне прост и известен давно: сказал А -- говори и Б.


Почему идиотизм? Зависит от ситуации, и не надо здесь обобщать.

Например, если требуется вывести на сайте количество слушателей с нескольких серверов Icecast, то вариант с сохранением файла на каждом из них будет не самой лучшей идеей, ведь это лишний, ненужный шаг во всем процессе. И где идиотизм в проходе PHP-скриптом по каждому status_json.xsl, сбору статистики и сохранению её в общий stat.json на сайте радиостанции, который уже будут забирать все браузеры и рендерить в человекопонятный вид у себя на стороне?

17.12.2011

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

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

1. void
2. logging_playlist (const char *mount, const char *metadata, long listeners)
3. {
4. char datebuf[128];
5. struct tm thetime;
6. time_t now;
8. char buff[5000];
9. int len = strnlen (metadata, 5000);
10. if (len < 5000)
11. {
12. strncpy (buff, metadata, len + 1);
13. int i;
14. for (i = len; i >= 0; i--)
15. {
16. if (buff[i] == '"')
17. {
18. memmove (buff + i + 1, buff + i, len - i + 1);
19. buff[i] = '\\';
20. }
21. }
23. ice_config_t *conf = config_get_config ();
24. char fn_json[FILENAME_MAX];
25. snprintf (fn_json, FILENAME_MAX, "%s%sstat.js",
26. conf != NULL ? conf->webroot_dir : ".", PATH_SEPARATOR);
28. FILE *json = fopen (fn_json, "w");
29. fprintf (json, "play_callback(\"%s\",%ld);", buff, listeners);
30. fclose (json);
31. }

Сделано было под МОИ нужды, хотя можно поправить под что угодно. Кавычки эскейпятся, битый жсон не приходит. Использован коллбек, а не переменная, дабы можно было отправлять запрос на чужой домен/порт. Обновление происходит при смене трека, в ту самую секунду, когда сменился оный, а не когда поллер просрется. Создается статика, которую можно отдавать хоть айскастом, хоть нгинксом. И никакого похапе. Под "мои цели".

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

А идиотизм потому, что накушался этого говна, которое досталось мне в наследство: тег меняется, а плеер еще минуту-другую кажет старый, ибо сначала должен обработать похапе-скрипт раз в минуту, а потом еще плеер должен опросить. Такая слоупочность плеера адово выбешивала.