Ключевые факторы для разработки масштабируемого веб-приложения
Обычно алгоритм Вашей программы будет намного более важен для скорости Вашего приложения, чем язык . Можно реализовать плохой алгоритм на любом языке, включая C++. Имея это в виду, Вы будете обычно мочь написать код выполнения быстрее на языке, который помогает Вам реализовать более эффективный алгоритм.
Высокоуровневые языки делают очень хорошо в этом путем обеспечения более легкого доступа ко многим эффективным предварительно созданным структурам данных и поощрения методов, которые помогут Вам избежать неэффективного кода. Конечно, они могут время от времени также помогать записать набор действительно медленного кода также, таким образом, все еще необходимо знать платформу.
кроме того, C++ догоняет "новый" (отметьте кавычки), функции как контейнеры STL, автоматические указатели, и т.д. - видят библиотеку повышения, например. И Вы могли бы иногда находить, что самый быстрый способ выполнить некоторую задачу требует техники как адресная арифметика с указателями, которую это запрещается на высокоуровневом языке - хотя они обычно позволяют Вам обращаться к библиотеке, записанной на языке, который может реализовать его, как желаемый.
главное состоит в том, чтобы знать язык, который Вы используете, это связало API, что это может сделать, и что это - ограничения.
6 ответов
That's a fairly vague and broad question and something you could write books about. How far do you take it? At some point the performance of SQL JOINs breaks down and you have to implement some sharding/partitioning strategy. Is that the level you mean?
General principles are:
- Cache and version all static content (images, CSS, Javascript);
- Put such content on another domain to stop needless cookie traffic;
- GZip/deflate everything;
- Only execute required Javascript;
- Never do with Javascript what you can do on the serverside (eg style table rows with CSS rather than using fancy jQuery odd/even tricks, which can be a real time killer);
- Keep external HTTP requests to a minimum. That means very few CSS, Javascript and image files. That may mean implementing some form of CSS spriting and/or combining CSS or JS files;
- Use serverside caching where necessary but only after you find there's a problem. Memory is an expensive but often effective tradeoff for more performance;
- Test and tune all database queries;
- Minimize redirects.
Having a good read of highscalability.com should give you some ideas. I highly recommend the Amazon articles.
Every application is different. You'll have to profile your application to see where you should concentrate your optimization efforts. Some web applications might require database access optimizations, while others have complicated business logic that cause the bottleneck.
Don't attempt to optimize random arbitrary parts of you application without first profiling. You might end up having to support complicated optimized code that doesn't actually make your application snappier.
Нет. Просто запрограммируйте приложение, используя правильные методы проектирования (разделение задач и т. Д.), А затем, когда приложение готово или почти готово, проведите тестирование производительности. Тогда вы обнаружите настоящие узкие места - они не будут такими, как вы могли предположить вначале. Здесь в игру вступает ваш правильный дизайн с самого начала - он упрощает внесение изменений для устранения узких мест.
Из других ответов здесь я понимаю, что существует общая путаница между масштабируемостью и производительностью. Высокая производительность означает быструю реакцию. Высокая масштабируемость означает, что вы получите ответ независимо от того, сколько других пользователей одновременно используют сайт. Здесь большая разница.
На самом деле, вам действительно нужно немного пожертвовать производительностью, чтобы получить хорошую масштабируемость. Общий шаблон масштабируемости - распределенные вычисления. Выделение функциональности на отдельные уровни кластерных серверов (сеть, бизнес-правила, база данных) - обычный подход к масштабируемости. Этот дополнительный круговой обход немного замедлит загрузку страницы.
Каждый всегда хочет сосредоточиться на высокой масштабируемости, но также не забывайте об этом, для поставщиков программного обеспечения, которые продают лицензии клиентам, которые самостоятельно размещают приложение, уменьшение масштаба может быть столь же важным, как и увеличение масштаба. Приложение, которое может работать на одном сервере для десяти пользователей, но также может быть сконфигурировано для работы в веб-кластере из десяти серверов, среднем уровне из трех серверов и кластере баз данных из четырех серверов для 10 000 пользователей, будет системой, хорошо спроектированной для масштабируемости.
Иногда конкретный ответ более полезен, чем просто общие советы.
Если вы хотите масштабировать, единственное, на что нужно ориентироваться, - это СКОРОСТЬ (в аппаратном и программном обеспечении) и РЕСУРСЫ (в аппаратном обеспечении) ).
Аппаратное обеспечение, последнее дорогое (больше серверов, балансировщиков нагрузки и т. Д.).
Таким образом, тщательно выбрав исходную структуру разработки, вы сэкономите много времени и ресурсов - вплоть до нескольких порядков. величина.
Например, nginx (намного) быстрее, чем Apache.
Другие решения быстрее, чем nginx (как для статического, так и для динамического содержимого), но я не мог раскрыть их без цензуры на StackOverflow (оно было оценено как СПАМ и реклама, несмотря на то, что это БЕСПЛАТНОЕ решение).
Это пределы «совместного использования»: мы должны делиться только «приемлемым»