Незнаю знаете вы или не знаете, но
1.Пока не загрузятся стили — страница отображаться не будет
2.Пока не загрузиться(и не выполниться) скрипт который вы инклюдите — дальше страница отображаться не будет
3.Из пункта 2 следует что в один момент времени грузиться( и исполняется) только один скрипт.
*Но в зависимости от написания второй скрипт тоже может грузиться(но не исполняться) одновременно с первым… но
4.Один браузер в один момент времени держит только два(или четыре?) соединения с одним хостом.
Тоесть в среднем за загрузку 6ти скриптом браузер сделает 6 запросов к серверу один за другим.
К картинкам это в общем плане не относиться, мозила вроде 4 картинки одновременно тащит.
НО НЕ БОЛЕЕ!

Что же делать?

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

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

Кеширование промежуточного кода (Opcode Caching)
Кэширование кода это один из самых легких и эффективных путей увеличения производительности в PHP. Использовании данного вида кэширования позволит избавиться от большого количества неэффективностей, возникающих при процессе запуска выполнения кода. Кэширование кода сохраняет промежуточный код в памяти для того чтобы не компилировать PHP-код каждый раз при запуске файла.

Данный обзор написан специально для SEO Digest — популярного онлайн-журнала среди вебмастеров и поисковых оптимизаторов. Публикуемые в нем материалы рассчитаны на широкую аудиторию пользователей: от профессионалов Рунета до любителей и начинающих. Журнал доступен в PDF и онлайн версии.

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

Основные положения

Ускорение работы любой системы возможно в основном за счет кэширования некоторых (тут стоит подчеркнуть, что именно некоторых, а не всех подряд) часто используемых операций. Все кэширующие мероприятия, в том числе и для Wordpress, можно разбить на несколько основных частей:

• База данных
• Компиляция серверных скриптов (PHP)
• Статические страницы
• Клиентская составляющая

Пару дней назад обратился ко мне человек с достаточно рутинной просьбой: подкрутить настройки VPS для его ускорения — за последнее время на сайте был резкий рост посещаемости, и сервер в часы-пик стал совсем загибаться.

Это была бы рядовая и унылая статья про nginx и opcode-кеширование, если бы сервер не был до этого «прооптимизирован» техподдержкой хостера :-)

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

Хочу поделиться забавным открытием, которое я сделал при замене батареи в своем APC Back UPS 525. Итак, загадка:



Да, я понимаю, что APC когда клеит наклейку, дает свою гарантию на батарею. Но это не повод при этом поднимать ее цену в 3-4 раза.
Для тех, кто хочет сэкономить: Аналоги аккумуляторных блоков RBC для ИБП APC

Я всегда нервничаю, когда мой домашний компьютер делает вид, что он умнее меня – сам предлагает что-то загрузить или установить, перезагрузиться, или иным образом демонстрирует зачатки искусственного интеллекта. Контроль над вашим железом – штука интересная, но зачастую требующая дополнительных трат времени на изучение «матчасти», а требуется это далеко не всегда. Источник бесперебойного питания можно назвать самой нетребовательной частью компьютерной системы: вся его настройка сводится, разве что, к отключению «тревожной сигнализации» — если свет дома или в офисе вырубается часто, она начинает действовать на нервы. А так – стоит себе под столом, ничего для себя не просит, потихоньку защищая систему от различных малых (потеря данных) и крупных (смерть материнской платы) неприятностей.

Первый пост в блоге APC by Schneider Electric мы решили посвятить подробному обзору энергосберегающего ИБП Power Saving Back-UPS Pro 550 (BR550GI), прежде всего потому, что эта модель несколько выделяется в модельном ряде бесперебойников APC. Во-первых, этот ИБП выглядит достаточно солидно, чтобы можно было поставить его не под столом, а рядом с монитором. Во-вторых, модель со встроенным ЖК-дисплеем дает вам тот самый дополнительный контроль над железом, по-прежнему не прося ничего взамен. Внутри – много фотографий и видео работы устройства, результаты тестов с типичным офисным ПК и проверка на прочность при помощи сурового аналогового трансформатора.

Энергосберегающий источник бесперебойного питания APC Power Saving Back-UPS Pro 900 – ближайший родственник модели Pro 550, о которой мы недавно рассказывали. «Девятисотый» – более мощная модель с номинальной мощностью в 540 Ватт, она способна обеспечить защитой от перебоев электропитания даже весьма производительный домашний и офисный компьютер. Впрочем, в этот раз мы решили не ограничиваться тестом ИБП на время автономной работы. В дополнение к этому мы покажем, какие компоненты используются в «бесперебойнике», из чего складывается его довольно приличный вес (больше 10 кило!). Весь процесс разборки ИБП в сервисном центре APC by Schneider Electric мы также сняли на видео.

Возникла достаточно неординарная идея: виде средства сетевого кеша взять не MemCache, а MongoDb и сравнить их производительность. Но для представления и сравнения показателей этих двух «механизмов кеширования» взяли еще и другие средства, позволяющие ускорить работу нашего App (APC, RamFS, TmpFS, XCache).
В статье приведены данные и графики сравнения этих механизмов с описанием и рассуждением полученных данных и графиков.

Демо-зал APC by Schneider Electric – уникальное место. Здесь заказчикам и партнерам «Шнейдер Электрик», подразделением которой является APC by Schneider Electric, демонстрируют самые современные разработки компании для коммутационных узлов, серверных комнат и центров обработки данных. Это также место паломничества инженеров компании, которые периодически лишают установленные агрегаты важных деталей, изымая их для исследований. Мощные ИБП, способные в течение нужного времени поддерживать работу сотни серверов без подачи электроэнергии, подключены к тестовой нагрузке, для проверки их работы в разных режимах.

С другой стороны, где еще можно потрогать руками настоящее железо из мира «больших» компьютеров (с ручками для переноски и иногда на колесиках)? Мы воспользовались возможностью и от души подергали за ручки представителей трех основных направлений деятельности APC: источник бесперебойного питания Symmetra, систему внутрирядного охлаждения InRow RP и систему наблюдения NetBotz. В соответствии с духом демо-зала, этот материал получился обзорный, но мы обязательно расскажем об отдельных решениях поподробнее.

Сегодня у нас в гостях Дмитрий Борняков, начальник отдела информационных технологий завода Балтика Новосибирск. Под руководством Дмитрия был реализован проект по внедрению в серверной комнате завода «Балтика-Новосибирск» системы кондиционирования на холодной воде без использования холодильной машины (чиллера). Высокоэффективное прецизионное охлаждение ИТ-оборудования обеспечивается промышленным этиленгликолем, применяемым в технологическом процессе приготовления пива.

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

Мы продолжаем знакомить вас с демонстрационным залом APC by Schneider Electric. В предыдущем репортаже мы кратко рассказали об основных элементах тестового стенда, а сейчас остановимся на некоторых из них чуть более подробно.

Купив источник бесперебойного питания от APC (а именно — APC Back-UPS ES 550VA ), я с удивленьем обнаружил, что «из коробки» он не может похвастаться тесной дружбою с Linux. Конечно, XFCE Power Manager, входящий в состав XFCE 4.6, подхватил и разпознал UPS, но всё, на что он оказался способен — отображение в трее уровня заряда. Какие-либо настройки отсутствовали начисто, нельзя было даже задать выключение ПК при достижении определённого уровня заряда.

Обратившись за консультацией в гугл, я узнал о существовании замечательного демона apcupsd, чья роль заключается в — никогда не поверите — управлении ИБП от APC. Но, как оказалось, практически все руководства по его начальной настройке были откровенно устаревшими — включая, как ни странно, официальный мануал. Споткнуться приходилось уже в самом начале о «cat /proc/bus/usb/devices». Поговорив с гуглом серьёзным и доверительным тоном, я добился от него ссылки на действующий мануал, художественным переводом коего с дополнениями из иных источников сия статья и является.

Описание проблемы

Представим среднестатистический высоконагруженный сайт. Обычно на таких сайтах между backend'ом и DB ставят прослойку кеша. С увеличением количества посетителей, вероятность того, что несколько пользователей одновременно наткнутся на "протухший" кеш увеличивается. Если такое случается, то нагрузка на backend и DB возрастает, что в свою очередь увеличивает время обработки запроса и увеличивает вероятность возникновения подобной ситуации. Вот такая вот система с положительной обратной связью:Маленькие красные горбики — это "затупившие" на множественном обновлении кеша запросы. Эта статья будет описывать один из подходов к решению проблемы на примере(patch attached) связки PHP/APC, однако теоретическая база применима к любому языку и системе кеширования.

Предлагаем вашему вниманию очередную подборку с ссылками на новости и материалы.

Приятного чтения!

Рабочий день медленно, но уверенно подходил к концу. Солнечный свет струился сквозь жалюзи и заливали офис золотистым багрянцем. Где-то в углу жужжала кофемашина, выдавливая остатки кофе из капсулы. Наш проджект что-то оживлённо обсуждала с дизайнером, а я правил косяки, любезно оставленные мне младшим программистом.
И всё вроде бы ничего, если бы не сообщение: «А что у вас с сайтом T?».

Эта статья поможет ответить на вопросы владельцев, разработчиков и системных администраторов PHP-сайтов:

• Как оптимизировать сайт и ускорить его работу?
• С какой скоростью будет и может работать сайт, в соответствии с теми технологиями на которых он будет запущен?
• Какие технологии следует использовать настраивая сервер или VPS?

Типичная проблема:
В какой-то момент сайт начинает открываться и работать слишком медленно. Бывает, что хостинговая компания блокирует сайт за превышение нагрузки или перерасход ресурсов. Что же делать в такой ситуации?

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

И если говорить о серверах для PHP, то такой проблемой является способ исполнения php кода, ровно как и другие значимые настройки окружения на сервере.
Не зависимо от того, есть ли проблема в вашем коде или её нет, высокая у вас посещаемость или нет, от настроек сервера зависит очень многое. Что бы все сказанное не звучало пустыми словами и была написана эта статья.

В этом обзоре я протестирую только что установленный сайт на одном из самых распространённых движков управления контентом Drupal 7.33.

Для теста выбрана лишь одна составляющая php-хостинга. Мы будем тестировать web-серверы Nginx и Apache2, модули mod_php и php-fpm, версии php php53 и php56, посмотрим, как влияют оптимизаторы apc и opcache на скорость работы сайта.

---

В продолжение статьи:

Ускорение и оптимизация PHP-сайта. Какие технологии стоит выбирать при настройке сервера под PHP

---

В отличии от предыдущего материала, в этой статье сделан упор на сравнение скорости отклика и интерпретации кода для различных версий PHP, включая PHP 7 beta3.

Для ранних версий PHP, проведено тестирование между оптимизаторами кода apc, xcache и opcaсhe.
Эта статья не содержит тестов на производительность, таких как нагрузочные тесты ab и siege. Возможно, об этом я напишу в одной из следующих статей.
В данном случае, меня не интересует сколько страниц за секунду способна сгенерировать та или иная версия php-интерпретатора, скорее то, с какой скоростью она сгенерирует мне страницу и с какой задержкой.
В данном случае разница в том, что тесты производительности замеряют отношение скорости интерпретатора к общим ресурсам сервера, а так же подготовленности других связанных компонентов web-системы к работе на повышенных нагрузках.
Остановимся на скорости и отклике. Очевидно что производительность зависит от скорости, но высокая скорость не может гарантировать высокую производительность. Это, возможно, связанно с тем, что недостаточно хорошо настроен web-сервер или база данных, а также с какими-то не было ограничениями, например сетевого стека.
Что бы не заниматься попыткой объять необъятное, мы просто замерим скорость и отклик работы интерпретаторов php, на мощном сервере без нагрузки, с одинаковыми конфигурациями web-сервера, базы данных и операционной системы для всех испытуемых. Используем конфигурацию php-fpm + nginx. База данных MariaDB. Все технические детали скрыты под спойлером ниже.

От переводчика: разбираясь на днях с ошибкой, возникшей после деплоя сервиса, натолкнулся на эту замечательную статью про механизм кэширования файловых статусов в PHP. Предлагаю сообществу перевод.

Слышали ли вы про PHP-функции realpath_cache_get() и realpath_cache_size()? А может быть про параметры realpath_cache_size и realpath_cache_ttl в php.ini?

Кэш realpath — довольно важный механизм PHP, который нужно иметь в виду. Особенно, когда приходится работать с символическими ссылками, например, при деплое проекта. Настройка кэширования realpath может значительно влиять на быстродействие сервера и нагрузку на дисковую подсистемы сервера. Этот параметр был введен в версии 5.1, когда начали появляться первые PHP-фреймворки.

Далее мы разберемся, как все это работает под капотом, и как с этим жить. Под катом много ссылок на исходники.