Новые книги
 Как бы нас сегодня ни огорчало ЖКХ, один неоспоримый плюс все же появился в последнее время. Нам не надо теперь стоять в длинных очередях в сбербанк, чтобы оплатить счета! Перевести деньги за жилье, электроэнергию, отопление, воду и прочее можно за считаные минуты, не выходя из дома. И мы научим вас, как это сделать.Но ничего не бойтесь! Вам надо только строго следовать нашим простым пошаговым подсказкам-инструкциям, да еще для вашего удобства подкрепленные иллюстрациями. Кроме оплаты ЖКХ, вы научитесь оформлять и отправлять жалобы, писать заявления, находить нужную информацию про ЕИРЦ и капитальный ремонт, расселение аварийных домов и кадастровую оценку вашей недвижимости, незаконные свалки и законные требования к шумным соседям, и многое-многое другое. И главное – к подвигам вас должен толкать стимул: чем меньше вы будете тратить время на решение скучных бытовых вопросов, тем больше останется времени для вашей насыщенной, творческой, интересной жизни. |
 Что делает рекламу эффективной? Вопрос, который стоит и перед практиками, и перед теоретиками, и перед студентами, вынесен во главу угла седьмого издания прославленной «Рекламы» У. Уэллса, С. Мориарти и Дж. Бернетта.Книга поможет разобраться в правилах планирования, создания и оценки рекламы в современных условиях. В ней рассматриваются все аспекты рекламного бизнеса, от объяснения роли рекламы в обществе до конкретных рекомендаций по ведению рекламных кампаний в различных отраслях, описания стратегий рекламы, анализа влияния рекламы на маркетинг, поведения потребителей, и многое другое. Вы познакомитесь с лучшими в мире рекламными кампаниями, узнаете об их целях и лежащих в их основе креативных идеях. Вы узнаете, как разрабатывались и реализовывались идеи, как принимались важные решения и с какими рисками сталкивались создатели лучших рекламных решений. Авторы изучили реальные документы, касающиеся планирования описанных в книге рекламных кампаний, разговаривали с людьми, занимавшимися их разработкой. Сделано это с одной целью: научить читателя тем принципам и практикам, что стоят за успешным продвижением. Книга будет безусловно полезна студентам вузов, слушателям программ МВА, а равно и рекламистам-практикам. «Реклама: принципы и практика» – это книга, которую следует прочитать, чтобы узнать все об эффективной рекламе. 7-е издание. |
Постоянные Соединения с БД
| ||||||||||
 |
Глава 22. Постоянные соединения с базами данныхПостоянные соединения это SQL-ссылки, которые не закрываются по окончании работы скрипта. Когда постоянное соединение запрашивается, PHP проверяет, имеется ли уже идентичное постоянное соединение (которое осталось открытым после предыдущего запроса), и, если имеется, использует его. Если не имеется, РНР создаёт ссылку. 'Идентичным' является соединение, которое было открыто с тем же хостом, с тем же username и с тем же password (если имеются).
Те, кто не вполне знакомы со способами работы web-серверов и распределением нагрузки, могут ошибочно посчитать постоянным соединением соединение, таковым не являющееся. Постоянные соединения не дают возможности открывать 'user sessions' по той же самой SQL-ссылке, они не дают возможности эффективно строить транзакции и не делают ещё много чего. Фактически, чтобы внести полную ясность, постоянные соединения не предоставляют никакой функциональности, которая была бы возможна в их не-постоянных собратьях. Патщему? Это зависит от способа работы web-серверов. Есть три способа использования РНР вашим web-сервером для генерации web-страниц. Первый метод - использование PHP как CGI "wrapper/оболочки". При этом экземпляр PHP-интерпретатора создаётся и разрушается для каждого запроса страницы (PHP-страницы) к вашему web-серверу. Поскольку он уничтожается после выполнения каждого запроса, при этом закрываются все ресурсы, которые он использовал (такие как ссылка на SQL-сервер БД). В этом случае вы ничего не получите от использования постоянных соединений - они просто не существуют. Второй, самый популярный метод, - запускать PHP как модуль в многопроцессном web-сервере, которым на данный момент является только Apache. На многопроцессном сервере обычно имеется один процесс (parent/родительский), координирующий работу набора других процессов (его потомков), которые фактически выполняют работу по обслуживанию web-страниц. При поступлении каждого запроса от клиента, запрос направляется одному из дочерних процессов, который в данный момент не обслуживает другого клиента. Это означает, что, когда тот же самый клиент выполняет второй запрос к серверу, он может быть обработан другим дочерним процессом, а не тем, который был в первый раз. При этом постоянное соединение делает так, что каждый дочерний процесс должен соединиться с вашим SQL-сервером в первый раз при обслуживании страницы, которая использует это соединение. Если другая страница затем требует установления соединения с SQL-сервером, она может использовать соединение, которое дочерний процесс установил ранее. Третий метод - использовать PHP как plug-in на многопоточном web-сервере. В настоящее время в PHP 4 имеется поддержка ISAPI, WSAPI и NSAPI (под Windows), которые все позволяют использовать PHP как plug-in на многопоточных серверах, таких как Netscape FastTrack (iPlanet), Microsoft Internet Information Server (IIS) и O'Reilly WebSite Pro. Поведение будет точно таким же, как и для многопроцессной модели, рассмотренной ранее. Обратите внимание, что поддержка SAPI отсутствует в PHP 3. Если постоянные соединения не имеют дополнительной функциональности, то чем они тогда хороши? Ответ предельно прост - своей эффективностью. Постоянные соединения пригодятся, если велика нагрузка при создании большого количества ссылок на ваш SQL-сервер. То, насколько реально велика эта нагрузка, зависит от многих факторов. Например, какого типа БД, находится ли она на том же компьютере, что и ваш web-сервер, насколько загружена машина, на которой установлен SQL-сервер, и так далее. Важно то, что, если нагрузка по созданию соединений велика, постоянные соединения могут оказать существенную помощь. Они позволяют дочернему процессу соединиться только один раз для каждого жизненного цикла, вместо того чтобы делать это каждый раз при обработке страницы, которой нужно соединение с SQL-сервером. Это значит, что каждый дочерний процесс, который открыл постоянное соединение, будет иметь своё собственное постоянное соединение с сервером. Например, если у вас 20 дочерних процессов, которые запустили скрипт, выполняющий постоянное соединение с вашим SQL-сервером, у вас будет 20 различных соединений с SQL-сервером, одно для каждого дочернего процесса. Заметьте, однако, что этот подход имеет и некоторые недостатки, если вы используете БД с ограничением на количество соединений, которое превзойдено постоянными соединениями. Если ваша БД имеет лимит в 16 одновременных соединений и, при работающей сессии сервера, 17 дочерних потоков пытаются соединиться, один из них не сможет это сделать. Если в скриптах есть ошибки, которые не позволяют отключать соединения (такие как бесконечные циклы), БД с лишь 32 соединениями может быть быстро перегружена. Проверьте в документации к вашей БД информацию об обработке оставленных и незанятых соединений.
Важное резюме. Постоянные соединения были созданы для отображения один-в-один регулярных соединений. Это значит, что вы должны всегда иметь возможность заменить постоянное соединение на не-постоянное, и это не должно изменить поведение вашего скрипта. Это может (и, возможно, будет) изменять эффективность работы скрипта, но не его поведение! См. также fbsql_pconnect(), ibase_pconnect(), ifx_pconnect(), imap_popen(), ingres_pconnect(), msql_pconnect(), mssql_pconnect(), mysql_pconnect(), OCIPLogon(), odbc_pconnect(), Ora_pLogon(), pfsockopen(), pg_pconnect() и sybase_pconnect(). | | ||||||||
| ||||||||||