Решение

привожу чисто свои стили, которые применялись в проекте..

.right_menu1
{
	font-family:Arial;
	font-size: 14px;
	text-decoration: none;
	font-weight:bold;
}
 
.right_menu1 div
{
	padding-top: 5px;
	padding-bottom: 6px;
	padding-left: 36px;
 
	background-image:url(/project/templates/site/img/header21.triangle.gif);
	background-repeat:no-repeat;
 
	width:100%;
	height:100%;
	color: #575D6C;
}
 
.right_menu1 a:link:hover, .right_menu1 a:hover div
{
	text-decoration: none;
	background-color:white;
	cursor:hand;
	c\ursor:pointer;
}

1. понятно 

2. У станавливаем для дива паддинги и подсветку при наведении на пункт меню.

3. Ставим стили ховера чтобы понимал и IE и Mozilla. Замечу, что стиль подсветки применяется к тегу А, а для мозиллы к Диву в теге А!

Пример таблицы:

<table width="100%" cellspacing="0" cellpadding="0">
<tr>
	<td class="right_menu1" onclick="window.document.location='/';"><a href="#"><div>Модельный&nbsp;ряд</div></a></td>
</tr>
</table>

Failover и балансировка

Крупные проекты редко состоят из одного сервера приложений. Часто их два или больше, и возникает задача балансировки клиентов по этим серверам, а также выполнения failover — необходимо чтобы выход из строя одного из серверов не был заметен для клиентов.
Простейший способ рещить эту задачу — dns round-robin, т.е. назначение доменному имени нескольких ip-адресов. Но это решение имеет ряд недостатков, и гораздо лучше выглядит решение балансировки запросов по бакендам на фронтенде nginx. В конфигурационном файле выглядит это примерно так:
# объявляем upstream — список бакендов

upstream  backend  {
  # перечисляем dns-имена или ip-адреса серверов и их «вес»
  server   web1                 weight=5;
  server   1.2.3.4:8080         weight=5;
  # а так можно подключаться к бакенду через unix-сокет
  server   unix:/tmp/backend3   weight=1;
}
# конфигурация виртуального сервера
server {
  listen <...>;
  server_name myserver.com;
  # отправляем все запросы из локейшена / в апстрим
  location / {
    proxy_pass  http://backend;
  }
}

Запросы, приходящие к nginx, распределяются по бакендам соответственно указаному весу. Кроме того, можно сделать так, чтобы запросы с одних и тех же IP-адресов отправлялись на одни и те же серверы (для этого в upstream нужно указать директиву ip_hash). Так можно решить проблему с сессиями, но все же лучше найти какой-нибудь способ их репликации или (что еще лучше) использовать .
В случае, если один из серверов откажется принимать соединения или соединение к нему отвалится по таймауту, он на некоторое время будет исключен из upstream.

Собственно оптимизация nginx

1. Увеличение количества и объема буферов

Для хранения принятых запросов и еще не отданных ответов nginx использует буферы в памяти, а если запрос или ответ не помещается в них, nginx записывает его во временный файл (и пишет при этом предупреждение в log-файл). Поэтому необходимо установить такие размеры, чтобы в большинстве случаев не требовалось обращаться к временному файлу, а с другой стороны — чтобы буферы не использовали слишком много памяти.

Для этого используются следующие параметры:
client_body_buffer_size (по умолчанию: 8k/16k — в зависимости от архитектуры) — задает размер буфера для чтения тела запроса клиента. Обычно стандартного значения хватает, его требуется повышать, только если ваше приложение устанавливает огромные cookies.
proxy_buffer_size (по умолчанию: 4k/8k) — задает размер буфера, в который будет читаться первая часть ответа, получаемого от проксируемого сервера. В этой части ответа находится, как правило, небольшой заголовок ответа. Стандартного значения обычно хватает.
proxy_buffers (по умолчанию: 8 4k/8k) — задает число и размер буферов для одного соединения, в которые будет читаться ответ, получаемый от проксируемого сервера. Установите этот параметр так, чтобы большинство ответов от бэкенда помещалось в буферы.

2. Механизмы обработки соединений

Есть одна тонкость, касающаяся механизма обработки соединений, а именно — способ получения информации о событиях на сокетах. Существуют следующие методы:

* select — стандартный метод. На большой нагрузке сильно нагружает процессор.
* poll — стандартный метод. Также сильно нагружает процессор.
* kqueue — эффективный метод, используемый в операционных системах FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 и Mac OS X. На 2-процессорных машинах под управлением Mac OS X использование kqueue может привести к kernel panic.
* epoll — эффективный метод, используемый в Linux 2.6+. В некоторых старых дистрибутивах есть патчи для поддержки epoll ядром 2.4.
* rtsig — real time signals, эффективный метод, используемый в Linux 2.2.19+. При больших количествах одновременных соединений (более 1024) с ним могут быть проблемы (их можно обойти, но на мой взгляд, лучше с этим не связываться).
* /dev/poll — эффективный метод, используемый в Solaris 7 11/99+, HP/UX 11.22+ (eventport), IRIX 6.5.15+ и Tru64 UNIX 5.1A+.

При компиляции nginx автоматически выбирается максимально эффективный найденый метод, однако скрипту configure можно насильно указать какой метод использовать. Если вы решили сделать это, то лучше использовать такие методы:
Linux 2.6: epoll;
FreeBSD: kqueue;
Solaris, HP/UX и другие: /dev/poll;
Linux 2.4 и 2.2: rtsig, не рекомендуется при больших нагрузках.

Включение gzip позволяет сжимать ответ, отправляемый клиенту, что положительно сказывается на удовлетворенности пользователя, но требует больше времени CPU. Gzip включается директивой gzip (on|off). Кроме того, стоит обратить на следующие важные директивы модуля gzip:

gzip_comp_level 1..9 — устанавливает уровень сжатия. Опытным путем выявлено, что оптимальные значения лежат в промежутке от 3 до 5, большие значения дают маленький выигрыш, но создают существенно большую нагрузку на процессор, меньшие — дают слишком маленький коэффициент сжатия.
gzip_min_length (по умолчанию, 0) — минимальный размер ответа, который будет сжиматься. Имеет смысл поставить этот параметр в 1024, чтобы слишком малеьнике файлы не сжимались (т.к. эффективность этого будет мала).
gzip_types mime-тип [mime-тип …] — разрешает сжатие ответа методом gzip для указанных MIME-типов в дополнение к «text/html». «text/html» сжимается всегда. Имеет смысл добавить такие mime-типы как text/css, text/javascript и подобные. Разумеется, сжимать gif, jpg и прочие уже компрессированые форматы не имеет смысла.

Кроме того, существует модуль gzip_static, который позволяет раздавать уже сжатые статические файлы. В конфигурационном файле это выглядит так:
location /files/ {
gzip on;
gzip_min_length 1024;
gzip_types text/css text/javascript;
gzip_comp_level 5;
gzip_static on;
}

При использовании такой конфигурации в случае запроса «/files/test.html» nginx будет проверять наличие «/files/test.html.gz», и, если этот файл существует и дата его последнего изменения больше, чем дата последнего изменения файла test.html, будет отдан уже сжатый файл, что сохранит ресурсы процессора, которые потребовались бы для сжатия оригинального файла.

Оптимизация приложений

Существует очень полезный трюк, который позволяет указать разработчикам приложений, какие страницы нужно оптимизировать в первую очередь. Для этого потребуется в конфиге nginx указать новый формат лога:

log_format  my_combined  '$remote_addr - $remote_user [$time_local] '
    '"$request" $status $body_bytes_sent '
    '"$http_referer" "$http_user_agent" '
    '$upstream_response_time "$host"'
 
access_log /var/log/nginx/access_log my_combined;

Переменная $upstream_response_time содержит время ответа бэкенда, поэтому в лог попадает время обработки каждого запроса бэкендом. Далее понадобятся два скрипта:

1. /usr/local/bin/url_stats_report.sh:

#!/bin/sh
 
echo "=== Requests which took most of the time ===" > /tmp/report.txt
echo "overall time - number of requests - average time - url" >> /tmp/report.txt
 
cat /var/log/nginx/*access.log | /usr/local/bin/url_stats.py >> /tmp/report.txt
cat /tmp/report.txt | mail -s "url performance report" root

2. /usr/local/bin/url_stats.py:

#!/usr/bin/env python
 
import sys
 
urls = {}
 
try:
    while 1:
        line = raw_input()
        line_arr = line.split(" ")
        try:
            host = line_arr[-1]
            host = host[1:]
            host = host[:-1]
            url = line_arr[6]
            t = float(line_arr[-2])
            #print host, url, t
 
            try:
                urls[host + url] = (urls[host + url][0] + t, urls[host + url][1] + 1)
            except KeyError, e:
                urls[host + url] = (t, 1)
        except ValueError, e:
            pass
 
 
except EOFError, e:
   pass
 
def sort_by_value(d):
    """ Returns the keys of dictionary d sorted by their values """
    items=d.items()
    backitems=[ [v[1],v[0]] for v in items]
    backitems.sort(reverse=True)
    return [backitems[i][1] for i in range(0,len(backitems))]
 
if (len(sys.argv) > 1):
    f = open(sys.argv[1], 'r')
    for k in f.readlines():
        k = k.strip()
        try:
             print urls[k][0], urls[k][1], urls[k][0] / urls[k][1], k
        except:
             print 0, 0, k
else:
    i = 0
    for k in sort_by_value(urls):
        print urls[k][0], urls[k][1], urls[k][0] / urls[k][1],  k
        i += 1
        if i > 100: break

Они не идеальны, но задачу выполняют: запуская /usr/local/bin/url_stats_report.sh (например, в postrotate утилиты logrotate), вы получаете наглядную картину, какие запросы занимают большую часть времени бэкенда.

Кеширование

На данный момент существует версия nginx-0.7.59 которая поддерживает кеширование и является стабильной.. Я не могу проверить, так как использую более раннюю версию 0.7.26
Однако это все еще экспериментальная функция, но я решил рассказать о ней, т.к. ее одень давно ждали многое администраторы, да и лично для меня она очень полезна.
Сейчас nginx умеет кешировать на диске ответы от http и fastcgi запросов на бакенды, указывать ключ для кеширования, учитывать заголовки «X-Accel-Expires», «Expires» и «Cache-Control» и вручную устанавливать максимальне время жизни объекта в кеше.
Обслуживанием кеша (очиста старых файлов, наблюдение за размером и т.п.) занимается специальный процесс cache manager. Положительной особенностью реализации является то, что при старте nginx cache manager начинает проверку кеша в фоне, благодаря чему nginx не делает то что называется «дает сквида», т.е. он не висит несколько минут проверяя кеш перед стартом.
Я намеренно не указываю пример конфигурации, т.к. во-первых директивы могут еще поменяться, а во-вторых нужно глубокое понимание механизма кеширования, что требует вдумчивого чтения документации (http://sysoev.ru/nginx/docs/http/ngx_http_proxy_module.html#proxy_cache) и архивов рассылки nginx-ru.

1 Способ

UPDATE `table` SET `column` = REPLACE( column, 'search', 'replace' );

В этом коде заменяем table на название таблицы, column на название колонки, search — искомый текст, replace — текст, на который будем замещать.
Так же в запрос можно добавить какое-либо условие WHERE.

2 Способ

Сделать дамп базы, сделать реплейс любой программой, например внутренним редактором менеджера Far или Notepad++, а потом залить базу обратно… Для безопасно быстрого бэкапа и восстановления базы рекомендую использовать Sypex Dumper бесплатную версию.

И полный синтаксис команды REPLACE

  REPLACE [LOW_PRIORITY | DELAYED]
        [INTO] tbl_name [(col_name,...)]
        VALUES (expression,...),(...),...
или REPLACE [LOW_PRIORITY | DELAYED]
        [INTO] tbl_name [(col_name,...)]
        SELECT ...
или REPLACE [LOW_PRIORITY | DELAYED]
        [INTO] tbl_name
        SET col_name=expression, col_name=expression,...

Оператор REPLACE работает точно так же, как INSERT, за исключением того, что если старая запись в данной таблице имеет то же значение индекса UNIQUE или PRIMARY KEY, что и новая, то старая запись перед занесением новой будет удалена.

Другими словами, команда REPLACE не предоставляет доступа к замещаемой записи. В некоторых старых версиях MySQL такой доступ иногда оказывался возможным, но это был дефект, который уже исправлен.

Для использования REPLACE у вас должны быть привилегии INSERT и DELETE для таблицы.

При использовании команды REPLACE функция mysql_affected_rows() вернет значение, равное 2, если старая строка была заменена новой. Объясняется это тем, что в таблицу вставляется строка после того, как удаляется дубликат.

Это позволяет легко определять, какое действие произвела команда REPLACE — добавление или замещение строки. Достаточно просто проверить, какое число вернула функция mysql_affected_rows() — 1 (строка добавлена) или 2 (замещена).

Следует учитывать, что, если не используются индексы UNIQUE или PRIMARY KEY, то применение команды REPLACE не имеет смысла, так как она работает просто как INSERT.

Подробнее тут.. (на английском)

Пример использования

(function($)
{
   $(document).ready(function() {
      $('.styleswitch').click(function()
      {
         switchStylestyle(this.getAttribute("rel"));
         return false;
      });
      var c = readCookie('style');
      if (c) switchStylestyle(c);
   });

   function switchStylestyle(styleName)
   {
      $('link[@rel*=style][title]').each(function(i)
      {
         this.disabled = true;
         if (this.getAttribute('title') == styleName) this.disabled = false;
      });
      createCookie('style', styleName, 365);
   }
})(jQuery);

Рассказывать что это такое не буду… гугл Вам в помощь
И так начнем:

Генерация частного ключа и CSR

Программный пакет openssl может быть использован для генерации приватного RSA ключа и создания CSR. Он так же может быть использован
для создания самоподписных сертификатов которые могут быть использованы для тестовых целей или внутреннего пользования. Программа, которая
обычно используется для решения этих задач, известна как openssl. Она должна быть установлена в директории /usr/local/ssl. Может быть, вам
придется добавить эту директорию в переменную PATH или же переместить эту программу в директорию, которая уже прописана в переменной PATH,
для того чтобы не писать полный путь. Дальнейшие примеры полагают, что openssl доступен вам без необходимости писать полный путь.

В первую очередь надо создать ваш приватный ключ. Это будет 1024 битный ключ стандарта RSA зашифрованный с использованием алгоритма TripleDES и хранящийся в формате PEM, так что его можно будет читать как простой текст. Мы будем использовать несколько файлов для усиления
случайности и для того чтобы сделать наш ключ более секретным.
Текстовые файлы, которые были сжаты утилитой типа gzip . станут хорошим выбором. Ключ генерируется следующей командой, где file1:file2:etc представляют собой случайные сжатые файлы.

Переходим в папку куда будем помещать сертификаты:

# cd /usr/local/nginx/

Cоздаем ваш приватный ключ

# openssl genrsa -des3 -rand file1:file2:file3 -out server.key

Программа предложит вам ввести пароль и сохранит ключ в файле server.key. Очень важно не забыть пароль. Если ключ будет утерян или пароль будет забыт сертификат станет бесполезен. Невозможно выразить как важен приватный ключ для сертификата. Если приватный ключ или пароль скомпрометированы сертификат должен быть отменен. Как минимум это будет стоить вам денег заплаченных за сертификат. Было бы хорошей идеей сделать резервную копию на безопасном носителе, таком как кассета или дискета.

Один неприятный сторонний эффект ключа с паролем это то что Apache или nginx будет всякий раз спрашивать пароль при старте. Понятно что это не очень удобно если только кто-то не находится постоянно рядом на случай
перезагрузки или аварийной остановки. mod_ssl (Для апача) включает в себя возможность использования внешней программы вместо встроенного парольного диалога. Возможно убрать пароль из ключа. Если приватный ключ более не зашифрован, важно чтобы файл его содержащий, был доступен на чтение только пользователю root. Если ваша система скомпрометирована и третья сторона получила ваш незашифрованный приватный ключ, производный сертификат должен быть отменен. После того что мы сказали, используйте следующую команду для того чтобы убрать пароль из ключа.

# openssl rsa -in server.key -out server.pem

Или же просто в первом шаге не используйте ключ -des3

После того как приватный ключ сгенерирован может быть сгенерирован запрос на подпись сертификатов(CSR —). CSR может быть использован двояко. В идеале CSR должен быть послан к CA такому как Tawte или VeriSign, которые проверят подлинность запрашивающего и выдадут подписанный сертификат. Другой путь — подписать CSR самостоятельно, что будет продемонстрировано ниже.
Во время генерации CSR вас попросят ввести некоторое количество информации. Один из вопросов будет Common Name (eg, YOUR name) []:
Важно чтобы это поле содержало полностью квалифицированное имя домена вашего сервера. Если вебсайт имеет адрес www.zatusim.ru то вы должны написать именно www.zatusim.ru Команда для генерации CSR выглядит так.

# openssl req -new -key server.key -out server.csr

Пример подстановки:

Country Name (2 letter code) [AU]:RU
State or Province Name (full name) [Some-State]:Moscow
Locality Name (eg, city) []:Moscow
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Zatusim Company
Organizational Unit Name (eg, section) []:.
Common Name (eg, YOUR name) []:www.zatusim.ru
Email Address []:webmaster@zatusim.ru
 
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Генерация самоподписанного сертификата

На этом этапе вам необходимо сгенерировать самоподписанный сертификат потому что вы или не планируете заводить сертификат подписанный CA, или хотите потестировать новую реализацию SSL пока CA подписывает ваш сертификат. Мой опыт общения с Tawte показывает, что получение сертификата занимает неделю и больше. Время которое занимает получение сертификата варьируется от того как быстро CA получит необходимые документы. Временный сертификат будет выдавать ошибку в клиентском броузере от того, что CA неизвестен и не проверен.

Для того чтобы сгенерировать сертификат годный в течение 60 дней введите следующую команду.

# openssl x509 -req -days 60 -in server.csr -signkey server.key -out server.crt

Установка ключа и сертификата
У меня все виртуальные хоты грузятся из папки.. в прошлой статье я писал как это сделать…

В конфиге хоста должно получиться примерно следующее:

    server {
        listen       443;
        server_name  zatusim.ru www.zatusim.ru;
 
    ssl on;
    ssl_certificate      /usr/local/nginx/server.crt;
    ssl_certificate_key  /usr/local/nginx/server.key;
 
    ssl_session_timeout  5m;
    ssl_prefer_server_ciphers on;
    ssl_session_cache    shared:SSL:1m;
    ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL;

Заходим на свой домен с https в итоге, так как сертификат у нас не подписан «спец службами» в ФФ мы получим что сертификат не подписан, считываем его и добавляем в доверенные. ИЕ скажет что не безопасно мы то знаем что все пучком… заходим и видим что прекрасно соединились…

ДЛя тех кто настраивает под apache + mod_ssl

Когда Apache и mod_ssl установлены — создаются несколько поддиректорий в конфигурационной директории Apache. Их расположение зависит от того, как компилировался Apache. Если использовать мои инструкции, компилируя Apache, конфигурационная директория будет /usr/local/apache/etc Директории, которые создает mod_ssl содержат в себе файлы ssl.crt, ssl.csr, и ssl.key Это хорошее место для хранения сертификатов, запросов на подпись и приватных ключей. Если у вас будет несколько хостов с SSL хорошей практикой стать включение в имена этих файлов имен защищаемых хостов.

Добавляя виртуальные хосты к веб-серверу, я обычно предпочитаю хранить их конфигурации в отдельном файле. Это дает уверенность, что все конфигурации могут быть быстро найдены, и, заодно, не позволяет основному конфигурационному файлу разрастаться. Если все виртуальные хосты сохранены в файле ssl.conf, то для того чтобы Apache нашел его и прочитал надо включить в основной конфиг следующюю строку:

# Include /usr/local/apache/etc/ssl.conf

Конфигурирование виртуального хоста, использующего SSL.

Обширные примеры конфигурации SSL для виртуальных хостов включены в файл /usr/local/apache/etc/httpd.conf.default, который устанавливается вместе с mod_ssl. Ознакомьтесь с документацией на mod_ssl для того чтобы получить более подробную информацию о возможностях конфигурации. Простой хост использующий SSL в конфигурационном файле может быть прописан так. SSL Virtual Hosts

ServerAdmin webmaster@zatusim.ru
DocumentRoot /usr/local/apache/share/htdocs
ServerName www.zatusim.ru
ScriptAlias /cgi-bin/ /usr/local/apache/share/htdocs/cgi-bin/
SSLEngine on
SSLCertificateFile /usr/local/apache/etc/ssl.crt/server.crt
SSLCertificateKeyFile /usr/local/apache/etc/ssl.key/server.pem
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
CustomLog /usr/local/apache/var/log/ssl_request_log \
"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"

Не забудьте скопировать ваш сертификат туда куда указали путь в апаче или же пропишите свой.

Этот пример создаст виртуальный хост с именем. который доступен через порт 443 (стандартный порт для протокола https) сайты с IP адресом вашего сервера. Можно создать столько дополнительных виртуальных хостов для вашего сервера сколько IP адресов он обслуживает. Просто добавьте дополнительные конфигурационные блоки между директивами.

По архитектурным причинам протокол SSL не позволяет создавать name-based (HTTPS 1.1) виртуальные хосты. Для того чтобы создать новый виртуальный хост с поддержкой SSL на другом IP адресе просто замените _default_на новый IP.

Посте добавления виртуального хоста к конфигурационному файлу Apache должен быть остановлен и вновь запущен для того чтобы новый виртуальный хост заработал. К несчастью это один из тех случаев когда простая отправка сигнала HUP не сработает. После перезапуска в зависимости от того какой (шифрованный или нет ) ключ был использован Apache может спросить у вас пароль или пароли. Введите пароль, и всё заработает.

Теперь вы можете использовать ваш любимый броузер для просмотра содержимого только что созданного виртуального хоста защищённого SSL . Не забудьте использовать префикс https:// вместо http://. Вы получите окно с предупреждением, если вы использовали самоподписанный сертификат. Подтвердите согласие и страница продолжит загружаться уже защищенная с помощью SSL . Статусная строка вашего броузера должна содержать иконку в виде замка которая показывает что страница защищена. Вот и всё.

Все три способа используют CSS.

Предварительно заключите счетчики в теги

<div class='counters'> код счетчиков </div>

Назвать класс ‘counters’ можно по-другому.

В стилях CSS пишем:

Способ 1.

.counters
{
display: none;
}

Способ 2.

.counters
{
visibility: hidden;
}

Способ 3.

{
position: absolute;
left: -1000px;
}

Всё.