Таки Одесский Форум

Таки Одесский Форум (http://forumodessa.com/index.php)
-   Программирование (http://forumodessa.com/forumdisplay.php?f=128)
-   -   Облегчить работу сервера ? (http://forumodessa.com/showthread.php?t=855)

tnorman 13.03.2009 01:37

Облегчить работу сервера ?
 
В общем так. Я ламер и в программировании и в верстке и в дизайне и в прочих штуках которые как-то могут касаться интернета. Потому задаю вопрос знатокам.

Допустим у нас есть сервер от которого требуется сгенерировать для N-количества клиентов, 400 000 div элементов в течении 1 минуты.

Задача:
Максимально снизить нагрузку на сервер, спихнуть большую часть работы клиенту.

Решение:
В данный момент есть технология Ajax насколько я слышал позволяет избавить сервер от надобности генерировать ненужные элементы. Это хорошо. Но допустим 400 000 div элементов остались у нас уже при использовании этой технологии.

Каким образом можно дальше снять нагрузку ? Есть ли какие-то форматы, которые могут позволить серверу работать быстрее затрачивая меньше рессурса ?



Была такая мысль, допустим:

1 символ = 8 бит
<div> = 40 бит

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



Вобщем что вы думаете по этому поводу 0_о, где я сильно ударил лицом по грязи, а где всего слегка ?

Sergey 13.03.2009 18:40

компрессия HTTP
 
"Сжатие контента можно осуществлять непосредственно веб-сервером В частности для Apache есть модули mod_gzip и mod_deflate. Также компрессию возможно реализовать на стороне PHP включением директивы zlib.output_compression=1."
http://www.aglais.ru/1c-bitrix/perfo...mpression.html

tnorman 13.03.2009 21:57

Цитата:

Сообщение от Sergey (Сообщение 35518)
"Сжатие контента можно осуществлять непосредственно веб-сервером В частности для Apache есть модули mod_gzip и mod_deflate. Также компрессию возможно реализовать на стороне PHP включением директивы zlib.output_compression=1."
http://www.aglais.ru/1c-bitrix/perfo...mpression.html

Эм...
Я имел в виду не компрессировать информацию сервером (это ведь дополнительная нагрузка), я имел в виду, чтоб сервер генерировал инфу в особой кодировке, а на стороне клиента эта кодировка интерприировалась как html код и выдавалась браузеру уже в готовом виде.

Fog 15.03.2009 02:11

Задача не ясна :)

tnorman 15.03.2009 11:01

Тяжело объяснять то, чего никогда не видел или чего может быть нету :)

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

Добиться этого тем, чтоб сам сервер работал с другим кодом (а не обычными php html mysql). Специальный язык который бы отвечал требованиям. Тоесть такой, в котором пришлось бы генерировать меньшие объёмы информации и пересылать это интерприатору на стороне клиента. Интерприатор переводил бы ему знакомый код в HTML и передавал бы это браузеру. Таким образом нагрузка на сервер частично снимается и ещё больше работы передано в руки клиента.

Тоесть суть в том, что сам сервер не имеет дела ни с php ни с html как таковыми. А имеет дело со своим собственным, максимально облегченным кодом. Который легко генерируется и быстрее пересылается.

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

SeM 15.03.2009 12:31

А для каких целей нужно передавать столько <div> ? Если это будет какое-то мультимедиа приложение тогда можно использовать Flash. Программа загружается на клиент и никакой нагрузки на сервер.

Fog 15.03.2009 18:26

Ты не объясняешь что за данные, и какие условия их отдачи, поэтому непонятно, что тебе посоветовать.

Так абстрактно - могу посоветовать кэшировать данные - тоесть, не генерировать каждый раз, а генерировать один раз, а потом отдавать готовый файл. Перегенерировать файл, если данные изменились...

tnorman 15.03.2009 22:40

Ну к примеру googleEarth :)

Вопрос с подгрузкой территорий решён через Ajax, он помогает подгружать то что видим и некоторое количество по краям от видимой области. Объектов тьма-тмущая. Но сервер генерирует лишь небольшую часть из них

Теперь представим себе эту экономную технологию в сочетании с

Цитата:

Специальный язык который бы отвечал требованиям. Тоесть такой, в котором пришлось бы генерировать меньшие объёмы информации и пересылать это интерприатору на стороне клиента. Интерприатор переводил бы ему знакомый код в HTML и передавал бы это браузеру. Таким образом нагрузка на сервер частично снимается и ещё больше работы передано в руки клиента.

Тоесть суть в том, что сам сервер не имеет дела ни с php ни с html как таковыми. А имеет дело со своим собственным, максимально облегченным кодом. Который легко генерируется и быстрее пересылается.
Вот примерно то, о чем я думаю. Опять таки, тема скорее для пространных размышлений чем для конкретной дискуссии :)

Sergey 17.03.2009 01:55

GIF is super-AJAX
 
Цитата:

Сообщение от tnorman (Сообщение 37736)
Ну к примеру googleEarth :)
Вопрос с подгрузкой территорий решён через Ajax, он помогает подгружать то что видим и некоторое количество по краям от видимой области. Объектов тьма-тмущая. Но сервер генерирует лишь небольшую часть из них

Ну, во-первых, уже лет 15 (особенно это заметно на медленных модемных каналах :-) большая картинка грузится сначала размыто, потом постепенно улучшается.
Во-вторых, на машине с Windows XP, IE 6, Celeron 1.2, RAM 256 эта программа ( G Earth ) тормозит так, что увеличить хоть что-то весьма проблематично (на быстром канале)
В-третьих, компрессия трафика, по-моему, как раз и обозначает, что сервер, хоть и _сгенерировав_ 1000 раз <div>, в канал связи отправляет нечто вроде " 1000 * '<div>' ", то есть зипует всю эту байду. А на клиентской стороне, без всяких дополнительных программ, _любой_ браузер начиная с IE5, самостоятельно эту зипу распаковывает.
И если вешать на Web-сервер некий модуль, который будет экономить слово '<div>' и писать вместо него 16-ричное 0d, то никакого выигрыша в быстродействии не окажется. К тому же потом надо будет писать клиентский модуль под разные ОС, который будет перехватывать ВЕСЬ трафик http, определять, что вот этот кусочек зашифрован этим образом, и т. д. и т. д.

Существует же, в конце концов, javascript :) Генерируй браузером хоть миллион div'ов. Чего клиента жалеть? Лучше сервер пожалеть...

tnorman 17.03.2009 07:36

Цитата:

Сообщение от Sergey (Сообщение 39077)
Ну, во-первых, уже лет 15 (особенно это заметно на медленных модемных каналах :-) большая картинка грузится сначала размыто, потом постепенно улучшается.

Про особенности расширения JPEG и проргессивного сжатия я почитать успел, и не нашёл там аналогии своей идеи
Растровая графика это одно, элементы страницы это другое. Не вижу толку если информация будет проявляться рассеянной по всей странице, в любом случае что-то читабельное получится лишь при полной загрузке страницы.
Эта технология тут не применима.


Цитата:

Сообщение от Sergey (Сообщение 39077)
Во-вторых, на машине с Windows XP, IE 6, Celeron 1.2, RAM 256 эта программа ( G Earth ) тормозит так, что увеличить хоть что-то весьма проблематично (на быстром канале)

Это проблема клиента, а не сервера.

Цитата:

Сообщение от Sergey (Сообщение 39077)
В-третьих, компрессия трафика, по-моему, как раз и обозначает, что сервер, хоть и _сгенерировав_ 1000 раз <div>, в канал связи отправляет нечто вроде " 1000 * '<div>'........

НЕТ НЕТ НЕТ НЕТ НЕТ.
Меня пока не интересует, что будет отправлять в канал связи сервер. Меня волнует, что и сколько раз он генерирует.

Именно тут и нигде иначе логическое расположение технологии о которой я спрашиваю.

Сервер не генерирует "Дивы", сервер не генерирует ШТМЛ. Сервер изначально работает с облегчённой версией кода. который приобретает удобоваримую html фору лишь после декодировки на стороне клиента, или через специальный конвертер на стороне сервера. Задача не в том, чтоб просто сократить количество передаваемых данных, задача снизить время работы сервера.

Цитата:

Сообщение от Sergey (Сообщение 39077)
то есть зипует всю эту байду.

Вот и я про это 3-4 раза успел сказать. Сервер помимо того что генерирует 1000 дивов, ещё и тратит рессурс на то, чтоб зиповать эту байду...
Такое никуда не годится, это не экономия.
Канала да, но этого не достаточно.


Цитата:

Сообщение от Sergey (Сообщение 39077)
А на клиентской стороне, без всяких дополнительных программ, _любой_ браузер начиная с IE5, самостоятельно эту зипу распаковывает.
И если вешать на Web-сервер некий модуль, который будет экономить слово '<div>' и писать вместо него 16-ричное 0d, то никакого выигрыша в быстродействии не окажется.

Никаких модулей, сервер должен думать на этом языке, пусть это будет очередной ассемблер, который будет декодироваться в ШТМЛ. Я даже и не думал предлагать вариант с компиляторами на стороне сервера, этого быть не должно. это 16-ричное "0d" должно возникать, как естественный элемент программы, а не как результат предварительной компиляции <div></div>


Цитата:

Сообщение от Sergey (Сообщение 39077)
К тому же потом надо будет писать клиентский модуль под разные ОС, который будет перехватывать ВЕСЬ трафик http, определять, что вот этот кусочек зашифрован этим образом, и т. д. и т. д.

Надо будет.
Вроде как Флешплеер для интерприации флешовского ассемблера.

Цитата:

Сообщение от Sergey (Сообщение 39077)
Существует же, в конце концов, javascript :) Генерируй браузером хоть миллион div'ов. Чего клиента жалеть? Лучше сервер пожалеть...

Этого не достаточно хотя бы потому, что я задал вопрос со сноской, что этого не достаточно.

вывод:
Я судя по всему опять не достаточно ясно выразился.

unique 18.03.2009 11:19

Цитата:

Сообщение от tnorman (Сообщение 39095)
Вроде как Флешплеер для интерприации флешовского ассемблера.

Нужен просто новый протокол, который будет иметь возможность прямого отображения в HTML на стороне клиента.


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

Чем не подходят сервлеты, JSP, ASP?

tnorman 18.03.2009 18:39

Цитата:

Сообщение от unique (Сообщение 40517)
Нужен просто новый протокол, который будет иметь возможность прямого отображения в HTML на стороне клиента.


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

Чем не подходят сервлеты, JSP, ASP?

Хотя-бы тем, что я о них ничего не знаю :D, судя по всему это имеет какое-то отношение к моим размышлениям, пошёл искать инфу, спасибо.

Sergey 26.03.2009 15:17

Greasemonkey
 
Плагин для FireFox, реализующий идею модификации HTML-контента на стороне клиента и позволяющий пользователю "огненного лиса" создавать собственные сценарии (так называемые User Scripts), изменяющие загружаемые браузером страницы путем внедрения в их код дополнительных скриптов. Используя Greasemonkey можно настраивать по своему вкусу внешний вид практически любого интернет-ресурса. Самое главное - иметь за плечами опыт программирования, а если такового нет, то позаимствовать готовые скрипты можно с сайта userscripts.org.
http://www.greasespot.net/

unique 26.03.2009 17:03

Цитата:

Сообщение от Sergey (Сообщение 49004)
Плагин для FireFox, реализующий идею модификации HTML-контента на стороне клиента и позволяющий пользователю "огненного лиса" создавать собственные сценарии (так называемые User Scripts), изменяющие загружаемые браузером страницы путем внедрения в их код дополнительных скриптов. Используя Greasemonkey можно настраивать по своему вкусу внешний вид практически любого интернет-ресурса. Самое главное - иметь за плечами опыт программирования, а если такового нет, то позаимствовать готовые скрипты можно с сайта userscripts.org.
http://www.greasespot.net/

Не совсем то, что надо было.


Кстати, tnorman, совет помог? Какие результаты?

tnorman 27.03.2009 18:17

Цитата:

Сообщение от unique (Сообщение 49136)
Не совсем то, что надо было.
Кстати, tnorman, совет помог? Какие результаты?

Руки не добрались :)
Занимался по работе всякими верстками :D как освобожусь обязательно загляну в эти широты.


Часовой пояс GMT +3, время: 14:04.

Powered by vBulletin® Version 3.8.1
Copyright © 2000 - 2018, Jelsoft Enterprises Ltd. Перевод: zCarot
Copyright © 2009 Таки Одесский форум