Какая платформа JavaScript обычно используется для высокопроизводительных веб-сайтов?
Это доработка от десятичного к двоичному алгоритму старого калькулятора Марчанта (извините, у меня нет ссылки) в Ruby, адаптированном специально для этого вопроса:
def isexactsqrt(v)
value = v.abs
residue = value
root = 0
onebit = 1
onebit <<= 8 while (onebit < residue)
onebit >>= 2 while (onebit > residue)
while (onebit > 0)
x = root + onebit
if (residue >= x) then
residue -= x
root = x + onebit
end
root >>= 1
onebit >>= 2
end
return (residue == 0)
end
Вот обработка что-то похожее (пожалуйста, не голосуйте за стиль кодирования / запахи или неуклюжий ввод-вывод - это алгоритм, который имеет значение, а C ++ не является моим родным языком). В этом случае мы ищем остаток == 0:
#include <iostream>
using namespace std;
typedef unsigned long long int llint;
class ISqrt { // Integer Square Root
llint value; // Integer whose square root is required
llint root; // Result: floor(sqrt(value))
llint residue; // Result: value-root*root
llint onebit, x; // Working bit, working value
public:
ISqrt(llint v = 2) { // Constructor
Root(v); // Take the root
};
llint Root(llint r) { // Resets and calculates new square root
value = r; // Store input
residue = value; // Initialise for subtracting down
root = 0; // Clear root accumulator
onebit = 1; // Calculate start value of counter
onebit <<= (8*sizeof(llint)-2); // Set up counter bit as greatest odd power of 2
while (onebit > residue) {onebit >>= 2; }; // Shift down until just < value
while (onebit > 0) {
x = root ^ onebit; // Will check root+1bit (root bit corresponding to onebit is always zero)
if (residue >= x) { // Room to subtract?
residue -= x; // Yes - deduct from residue
root = x + onebit; // and step root
};
root >>= 1;
onebit >>= 2;
};
return root;
};
llint Residue() { // Returns residue from last calculation
return residue;
};
};
int main() {
llint big, i, q, r, v, delta;
big = 0; big = (big-1); // Kludge for "big number"
ISqrt b; // Make q sqrt generator
for ( i = big; i > 0 ; i /= 7 ) { // for several numbers
q = b.Root(i); // Get the square root
r = b.Residue(); // Get the residue
v = q*q+r; // Recalc original value
delta = v-i; // And diff, hopefully 0
cout << i << ": " << q << " ++ " << r << " V: " << v << " Delta: " << delta << "\n";
};
return 0;
};
6 ответов
(Полный отказ от ответственности: я разработчик Dojo, и это моя неофициальная точка зрения).
Все основные библиотеки могут использоваться в сценарии высокой нагрузки. Следует учитывать несколько моментов:
Начальная загрузка
Начальная загрузка влияет на время отклика: от запроса веб-страницы до отклика и рабочего режима. Тривиальные вещи:
- объединить несколько файлов JavaScript вместе (работает и для файлов CSS)
- минимизировать и / или сжать ваш JavaScript
Идея состоит в том, чтобы отправлять меньше - хорошо для сервера и хорошо для клиента.
менее тривиальная вещь:
- структурируйте свою программу таким образом, чтобы она работала без всех загруженных модулей
Пример последнего: разделите ваши модули на основные (например, основная логика) и несущественные ( например, помощники: всплывающие подсказки, подсказки, средства проверки, средства справки, различные «постепенные улучшения» и так далее). Идея состоит в том, что часто есть вещи, которые не важны для частых пользователей, но приятны для случайных пользователей ⇒ они могут быть отложены.
Мы можем сначала загрузить основные модули, а остальные загрузить асинхронно. Пример: если пользователь хочет отредактировать объект, нам нужно сначала его показать, после этого у нас есть несколько сотен миллисекунд, чтобы загрузить остальные: таблицы поиска, подсказки и т. д.
Очевидно, это помогает, когда асинхронная загрузка модулей поддерживается используемой вами структурой. В Dojo встроено это средство.
Распространять файлы
Всем известно, что из-за ограничений браузера на количество параллельных загрузок с одного и того же сайта полезно загружать ресурсы (изображения, CSS, JavaScript) из разных доменов:
- мы можем загружать больше параллельно, если линия пользователя имеет достаточную пропускную способность - в наши дни это почти всегда верно
- , мы можем настроить веб-серверы, оптимизированные для обслуживания статических файлов: огромный дисковый кеш, маленькие рабочие, keep-alive, async обслуживание и т. д.
- мы можем удалить все ненужные функции, которые нам не нужны при обслуживании статических файлов: сеансы, файлы cookie, и так далее
Одна из часто упускаемых из виду оптимизаций в приложениях JavaScript - это использование CDN :
- ваш веб-сайт может получить выгоду от географического распределения CDN (файлы могут обслуживаться с ближайшего / самого быстрого сервера)
- пользователь мог иметь необходимые файлы в своем кэше, если они использовались другим приложением
- промежуточные / корпоративные кеши увеличивают вероятность того, что требуемые файлы уже кэшированы
- последнее, но не менее важное: это файлы, которые вы не используете Не служит - подумайте об этом
Опять же, Dojo уже давно поддерживает CDN и распространяется публично AOL CDN и Google CDN . Последний также включает в себя практически все популярные инструменты JavaScript. Очевидно, вы можете создать свой собственный CDN и свою собственную сборку Dojo для CDN и приложения, если вы чувствуете, что вам это нужно - это тривиально и хорошо задокументировано.
Пропускная способность связи
Как это может отличаться для разных наборов инструментов? XHR - это XHR.
Вам необходимо максимально снизить нагрузку на ваши серверы. Проанализируйте весь трафик и определите, сколько статических / неизменяемых данных передается по каналу. Например, обычно много HTML-кода избыточно на нескольких страницах: заголовок, нижний колонтитул, меню и так далее. Вам действительно нужно, чтобы все это пересылалось каждый раз?
Одним из очевидных решений является переход от статического HTML + «постепенных улучшений» с помощью JavaScript к реальным «одностраничным» приложениям JavaScript. Опять же, это часто упускаемая из виду, но самая полезная оптимизация.
Хотя идея кажется простой, на самом деле она не так проста, как кажется. Как только мы переходим от однострочников к приложениям, у нас возникает множество вопросов, и самый большой из них - это упаковка: каковы ваши компоненты, какие компоненты предоставляются набором инструментов, и как их упаковать и доставить.
Dojo предоставляет модули, хорошее ООП для общих классов, виджеты (комбинация необязательного HTML и связанных поведений) и множество средств для работы с ними. Вы можете:
- загружать модули по запросу, а не в заголовке
- загружать модули асинхронно
- автоматически находить все зависимости между модулями и создавать «сборку» - один файл в простых случаях или несколько, если ваше приложение большой и требует нескольких слоев
- во время "сборки" он может встроить все фрагменты HTML для ваших виджетов, оптимизировать CSS, и минимизировать / сжать JavaScript
- Dojo может автоматически находить и создавать экземпляры виджетов в HTML, сохраняя при этом много шаблонного кода
- и многое другое
Все эти функции очень помогают при создании приложений на стороне клиента. Вот почему мне нравится Dojo .
Очевидно, есть и другие способы оптимизации высоконагруженных веб-сайтов, но, согласно моей практике, они являются наиболее специфичными для фреймворков JavaScript.
Очень просто: все из них .
Все фреймворки созданы для обеспечения максимально возможной производительности и предоставления разработчикам полезных функций и инструментов. Ваш выбор должен основываться на ваших требованиях .
JavaScript работает на стороне клиента, поэтому ничто не повлияет на производительность вашего сервера. Единственное отличие на стороне сервера - это объем пропускной способности, используемый для передачи файлов .js клиенту.
Мне лично нравится MooTools , потому что он отвечает моим требованиям и также придерживается моих идеалов программирования. Многие люди приняли jQuery (лично мне это не нравится, не значит, что он плохой). Других я не использовал.
Но ни один не лучше другого, он »
Я не думаю, что это имеет какое-то значение. Большие, похоже, используют смесь JQuery и prototype вместе с другими.
Откровенно говоря, не имеет значения, что вы используете для часто посещаемых веб-сайтов, поскольку мы говорим о клиентских технологиях. После загрузки файла накладных расходов практически нет. Итак, если вы просто хотите сделать одну простую вещь и ее поддерживают несколько фреймворков, используйте то, что имеет меньший размер файла (конечно, если он работает очень плохо, используйте другой!)
При этом, как говорится, Google размещает много фреймворков, так что даже это действительно не проблема. Я использую Jquery, размещенный в Google, и очень счастлив.
http://code.google.com/apis/ajaxlibs/
Backend и то, что должен использовать сервер, - это совершенно другой вопрос, где вы получите тысячу разные ответы!
Ну - в качестве примера stackoverflow полагается на jQuery (и использует ссылку google apis) - это одна из самых быстрых и популярных библиотек и не только это, но я бы сказал, что ее проще всего использовать. Какое поведение вы собираетесь вести на сайте? На самом деле все зависит от ваших потребностей.
Ответ, как всегда, таков: это зависит от обстоятельств. О каком спектакле вы говорите? Скорость загрузки? Используйте минимизатор, и, вероятно, нет большой разницы. Или производительность на стороне клиента, и что вы с ней делаете?
Но я бы посоветовал, если вам нужна необработанная производительность, я бы вообще не использовал фреймворк и создал низкоуровневый javascript, который будет намного лучше трудно поддерживать.
Некоторую полезную информацию можно найти на сайте YUI .
Как уже объяснялось в других ответах, структура не будет узким местом в производительности вашего сайта - - скорее, многие другие факторы. Если вы используете популярные фреймворки и загружаете их с популярных для них URL-адресов (например, AOL или Google), они, вероятно, будут кэшированы в браузерах ваших пользователей, так что вам тоже не нужно сильно об этом беспокоиться.
Если вы вообще заботитесь о производительности, однако, ОБЯЗАТЕЛЬНО ознакомьтесь с работой Стива Содерса; , включая обе его книги, «Высокопроизводительные веб-сайты» и «Еще более быстрые веб-сайты».
I ' m предвзято, поскольку Стив - друг и коллега (и мы тоже разделяем издателей),