Рекомендуется использовать один синхронный вызов на один запрос пользователя, или вообще отказаться от синхронных вызовов.
Потому вывод:
- к базе подключаться асинхронно;
- формировать очередь задач;
- не запускать одинаковых обработчиков параллельно;
- написать асинхронный менеджер процессов;
- держать в фоне малое количество параллельных процессов;
Думаю дело не совсем в соединениях. А в количестве запущенных процессов и к каждому ещё php интерпретатор. Плюс нагрузка на многозадачные переключения.
Потому для создания множества фоновых задач пользуйтесь чем-то вроде Gearman на ваш выбор, запуская задачи из общего планировщика в одной многозадачной сессии PHP.
Елена, Если это ленд без бекенда, то здесь подход слегка упрощенный. Разделяем только на 2 файла стилей. Тот который грузится для быстрого отображения начала страницы. И другой для всего остального. Формы тогда тоже уже склеены с стартовой таблицей. Только их визуальное оформление уже допиливается в основном.
На счет мобайл фёрст. Логика проста: на мобильном ограничен трафик, по этому делаем все, что бы уменьшить трафик. А для этого делаем начальную таблицу стилей для него. А потом для всего остального через медиа запросы. Тут других подходов быть не может.
Дело в том, что строить дом нужно с фундамента, а не с крыши. Построить получится, но с какими манипуляциями приходится иметь дело. Все упирается во время, а время упирается во деньги. Если заказчик платит за анальное удаление гланд. Не вопрос. Но на практике удобнее и быстрее использовать ректальное.
И мы всегда предупреждаем заказчика, что последовательность разработки определяем мы, а не он. Или тогда он платит почасовку которая в итоге получается в 2, а то и 3 раза выше... С одной стороны заказы реже приходится искать. А с другой стороны: эта анальная трахеотомия как-то выматывает, и прицел сбивает.
P.S. А мы кроме резиной я иначе не делаю. Ибо в итоге приходит момент когда заказчик зВОНИТ, что на каком-то устройстве его ДРАГОЦЕННЫЙ сайт не работает. Или все поплыло...
Все-таки, в большинстве случаев, разделяются файлы для удобства разработчика.
Если у вас нормальный бекенд то на счет объединения он определится сам. Если http2 - то не будет обьединять вообще, а если http - то объединит соответственно странице.
Ленивый бекендщик этого не сделает, будет ссылаться на то что есть другие более важные задачи. И в итоге так и никогда и не сделает это. Поставит общую "объединялку" и все!
Чтобы это можно было сделать, верстальщик должен сделать раздельные сборки:
Стартовую таблицу стилей которая грузится на всех страницах. Сюда входят: сброс браузеров, хеадер, футер (если он fixed внизу видимого), стили видимого при загрузке домашней страницы. ТОЛЬКО то, что видно на самом большом экране без элементов которые появляются во время прокрутки.
Основную таблицу стилей для разметки страниц контента. То что входит во все страницы контента, без специфичности. Ну и не фиксированный футер тот, что после контента. Эти стили должны быть загружены уже после загрузки основного контента.
Специфичные стили для отдельных страниц. Эти грузятся отдельно на каждой странице свои стили и по надобности объединяются с Основной разметкой контента.
Таблица стилей форм. Все формы на сайте должны грузится с одной таблицы. А не быть специфичными для разных страниц. Формы это не контент!!! У форм ОБЯЗАТЕЛЬНО должна быть отдельная таблица стилей. Она подключается при включении формы генератором форм на бекенде. Даже строка поиска в хедере. Все элементы input, textarea, option должны быть описаны в отдельной таблице стилей. Эти стили объединяются с основной или стартовой таблицей как будет надо.
P.S. Уточню по Основной таблице стилей.
Верстка ВСЕГДА должна быть мобайлфёрст. И сновная таблица должна быть на мобильной версии сайта. А потом ёё расширять и естественно подключать по надобности.
Нееее-нееее-неее-не-не-не-нет! Там нужно два == !!! Это сравнение а не присваивание.
С одним = просто в $data['password'] поверх запишется хеш из пароля который пришел по сети.
И условие всегда будет выполняться, с любым даже неправильным паролем!!!
P.S. Сравнивайте всегда значение с переменной а не наоборот. Например:
if ( 2 == $a && md5($_POST['password'])) = $data['password'] )
Тогда не будет возникать трудно уловимой ошибки "присваивание вместо сравнения"...
В моем примере PHP сразу выдаст ошибку. Чтобы найти и исправить на ДВА ==.
wiyod, Но если контент блок флекс, то придется однозначно определить ширину и высоту или максимумы и/или минимумы. Если не явно у самого блока, то у самих флекс элементов уж точно. Иначе результат будет не такой как ожидаете.
P.S. Было бы очень неплохо посмотреть сам документ. Что бы поставить окончательный диагноз. А то из ваших слов не совсем понятно.
