Есть ли разница в производительности PHP при работе с однобайтовой и мультибайтовой кодировками?

Question

[ReFeRy]

Перевёл сайт с win-1251 на utf-8. На сайте приличная посещаемость и довольно много работы с текстами. До этого не было даже намёка на то, что предел производительности сервера близко, а после этого сервер начал притормаживать (на сервере только мои сайты, обсуждаемый сайт создаёт 95% нагрузки). Администрирование это совсем не моё, поэтому узкое место найти затрудняюсь. Наплыва посещаемости не было, проблемы начались сразу после перехода на новую кодировку.

Сильно ли отличается производительность PHP при работе с win-1251 и utf-8?
Или мне надо искать причины тормозов совсем в ином месте...

Comments

[ReFeRy]

Neoline: не всё так просто, сайту 12 лет, самопис на голом пхп, там кода на пару мегабайт :)

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

Я прочитал ваш профиль, но с таким объемным проектом вы вряд ли возьметесь связываться задешево.

[Sergej]

лет 10 не слышал про win1251 =) вы мне подарили минуты сомнительной ностальгии )

Answer 1

[index0h]

Кодировка влияет на производительность примерно так же, как форма лица на аэродинамику бегуна.
Копайте в сторону индексов БД, очень вероятно проблема зарыта где-то там.

Comments

[ReFeRy]

Тормозов mysql не замечал. Индексы практически все числовые, по текстовым полям индексов очень мало, но посмотрю, спасибо.

[index0h]

ReFeRy Вообще для анализа производительности есть всякие крутые штуки, типа xhprof, которые явно показывают, в чем у вас лаги. 95% нагрузки, что вы указали - это ни о чем не говорит. Нагрузки обычно на CPU/RAM/IO/NET

[ReFeRy]

index0h: Придётся этим заняться, да. Спасибо.

Answer 2

[65536]

Уже лет 10 как, всё должно быть в ютф, если нет каких-то внешних требований. Иначе может резко упасть ваша производительность, а не сервера. Проблемы с разгадыванием и конвертацией кодировок могут добавить несколько дней бесплатаной работы.

Если по теме, то нагрузка может возрасти когда выбирается (и используется!) весь миллион записей с текстовыми полями когда они не нужны, то есть где-то было сделано select * и пхп считывает каждую. Но даже если так, то нагрузка возросла бы всего в 4 раза, или в 5, не помню (по текстовым полям если считать).

Answer 3

[xmoonlight]

Скорее всего, всё дело в ПОЛНОМ циклическом переборе символов в тексте.

Comments

[ReFeRy]

Подобное есть в одном месте. Этот скрипт вызывается не особо часто.

[xmoonlight]

ReFeRy: не важно как часто он вызывается - важно как просела скорость его работы.

[ReFeRy]

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

[xmoonlight]

ReFeRy: значит нужно смотреть там, где iconv*-функции (поиском по файлам): php.net/manual/ru/book.iconv.php
Возможно, оно тратит время на автоматическую конвертацию, т.к. выходной буфер веб-сервера - не настроен на UTF-8.

Answer 4

[toxa82]

Функции для работы с текстом mb_* намного тормознутей их аналогов без префикса mb_. Но общая производительность зависит от кол-ва их использования.