Сервер для Привета

[Palych]

На чём Вы пробовали? На WIndows? Можно счетчики сравнить?

Windows 2000 SP4.
Счетчики ставить не умею.... Завтра посмотрю...

[f_evgeny]

IMHO лучший способ обеспечить мирное сосуществование IIS и Apache - URL rewriting.
e.g. обьяснить IIS чтобы все запросы на privet.com/forum/.... он отвечал redirectом на privet.com:1333/forum/...

Или наоборот...

a smysl?
тот же цги, только хуже. Вообще, IIS i CGI - етоп крайняк. Там же все на тредах.
Ето ж не апач.
IIS-u ISAPI dll - то, что нужно.

Апач 2.xx тоже на тредах, видимо специально для Виндовс. Мы тут уже обсуждали, что модуль ISAPI PHP для IIS не рекомендуется, ввиду неотработанности, а так, это конечно было бы идеальным решением.

[Privet]

...
Второй совет будет - поставить на UNIX, скорее всего Линукс, или FreeBSD, есть такое народное поверье, что веб-сервер с PHP надо ставить на UNIX. Поскольку на UNIX здесь похоже аллергия, я и не упоминаю даже. Но с CGI-то все ясно.
...

Мне кажется, Вы несколько отклонились от темы. Как специалисты мы далеки от поверий. Сейчас стоит задача выяснить конкретно, шаг за шагом механизм деградации производительности того программного обеспечения, которое работает на сервере. Выявим слабое звено - будем думать что делать дальше.
CGI - одно из слабых звеньев и его надо убирать, но пока это не тот критический элемент, который опрокидывает сервер. Прежде, чем что-то предпринимать, хорошо бы найти главного виновника.

CGI оказалось на сервере относительно случайно. Мы только перешли с Perl на PHP и PHP на то время был сыроватым продуктом. Я понял документацию так, что ISAPI версия подоспеет буквально через пару недель-месяцев. Улучшение скорости по сравнению с Perl тогда было значительное и меня не особенно волновало некоторая некорректность с CGI. Увы, решение вопроса с ISAPI несколько затанулось и теперь объём и трафик форума заставляют искать другие решения, что мы и делаем. Я сейчас делаю новый сервер. Надеюсь, он нам поможет. Что на него ставить вопрос пока открытый. Пока известно, что на нём будет стоять база данных. Какая база и на чем пока я не знаю. У меня есть некоторые причины отказываться от MySQL. Администрацие её оставляет желать лучшего. За несколько лет пользовательский интерфейс застыл на одном месте и улучшения не предвидится. С MS SQL я работал практически. Он мне понравился ясностью и удобством пользовательского интерфейса. Смешно сказать, наша проблема всего лишь в том, что мы не можем посмотреть какие запросы создают проблемы. Посмотреть, наверно можно, но мы все пока не знаем как. Кнопки, на которую надо ткнуть, нет. Надо читать доки и выискивать команды, которые могут подойти.
Переходить на MS SQL тоже пока страшновато. Это многочасовая работа по переносу данных, которая неизвестно чем закончится.

Что касается UNIX, то пока у нас нет надёжной информации о том, как UNIX будет выглядетьпо сравнению с W2K. Поверья, естественно в счет не идут. Нам хотелось бы покороче и в цифрах.

[A. Fig Lee]

приближает к глубокомысленному и научно обоснованному выводу:
MySQL SUXXX!!!

2001:
MySQL at Yahoo!
Some Technical Details:
Operating system used: FreeBSD and Linux, synchronized using MySQL Replication
Size of database: 25 GB
Average number of concurrent connections: 60
Max number of concurrent connections: 250

[A. Fig Lee]

может просто перед каждым обращением к MySQL file lock добавить? Не самое ли простое решение? Или не решение?

[Palych]

Я тут еще один тест нарисовал. (Ей богу, в следующей жизни буду тестером!)
Чтобы исключить влияние JDBC, а так же "форумной логики", собрал все запросы относящиеся к viewtopic в один php и натравил на него тот же тест.
Повесить пока не удалось (тестирую на рабочей машине, здесь база меньше).
Заметил что в варианте CGI при обвальном тесте с 10 потоков среднее время отклика составило 1900 мс, в случае модуля - 330мс. Впрочем пока ето не важно. Надеюсь на домашней машине воспроизвасти зависание...

[testuser]

А почему нельзя переконвертировать базу в InnoDB? Вроде бы проблем особых не должно быть ... Вот линк:
http://dev.mysql.com/doc/mysql/en/Conve ... nnoDB.html

Насколько я понимаю пользоваться MyIASM не советуют уже давно (еше четыре года назад, когда я использовал MySQL в мануале писали о том, что лучше использовать InnoDB).

Quote from MySQL site:

InnoDB is used in production at numerous large database sites requiring high performance. The famous Internet news site Slashdot.org runs on InnoDB. Mytrix, Inc. stores over 1TB of data in InnoDB, and another site handles an average load of 800 inserts/updates per second in InnoDB.

[Palych]

А почему нельзя переконвертировать базу в InnoDB? Вроде бы проблем особых не должно быть ... Вот линк:
http://dev.mysql.com/doc/mysql/en/Conve ... nnoDB.html

Сначала надобно воспроизвести проблему в текущей конфигурации.
Затем переконвертировать/поменять/подстроить, и только потом убедиться что проблема ушла. Заодно подщитать економический еффект от внедрения прогрессивных технологий.


А иначе будет неинтересно - поменяем и будем гадать, помогло или нет, а если помогло - что именно?

[A. Fig Lee]

Послали сюда:

http://www.google.com/search?sourceid=n ... ning+mysql

[testuser]

Сначала надобно воспроизвести проблему в текущей конфигурации.
Затем переконвертировать/поменять/подстроить, и только потом убедиться что проблема ушла. Заодно подщитать економический еффект от внедрения прогрессивных технологий.


А иначе будет неинтересно - поменяем и будем гадать, помогло или нет, а если помогло - что именно?

Возможно поменять не получится, если причина в том, о чем писали выше. InnoDB должна устранить ети проблемы автоматически.
Устанавливать причину - все равно что пытаться устранить проблемы в старой машине перед тем как приобрести новую. Может быть интересно, но смысла особого не имеет.

[Palych]

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

Как ето нет? Как же мы узнаем что новая машина лучше старой?
А может и не стОило брать новую? Может всего-то и нужен был подержаный маслопроводный шланг?
Если серьезно - как я понимаю вопрос о замене может скорее решитсься в пользу MS SQL...
Хотя мне было бы интересно посмотреть насколько InnoDB будет лучше чем MyISAM...
В качестве же замены по принципу "махнуть не глядя" я бы поставил Linux + Apache + PHP + MySQL/InnoDB
на ОДНОМ сервере, без всяких pconnect, с соединениыем через сокеты... Однако ето не покатит, поскольку нужен .Net...

[testuser]

Как ето нет? Как же мы узнаем что новая машина лучше старой?
А может и не стОило брать новую? Может всего-то и нужен был подержаный маслопроводный шланг?
Если серьезно - как я понимаю вопрос о замене может скорее решитсься в пользу MS SQL...
Хотя мне было бы интересно посмотреть насколько InnoDB будет лучше чем MyISAM...
В качестве же замены по принципу "махнуть не глядя" я бы поставил Linux + Apache + PHP + MySQL/InnoDB
на ОДНОМ сервере, без всяких pconnect, с соединениыем через сокеты... Однако ето не покатит, поскольку нужен .Net...

Here is a good article about that:

http://www.mysql.com/news-and-events/ne ... 00091.html

Some quotes:
"MyISAM tables are really good for large constant tables or logging tables (concurrent insert feature allows MyISAM tables to perform inserts even while table is being read). They are also often good choice for tables with relatively infrequent updates or fast selects - these will not lock the table for the long time and so will not reduce performance."

"InnoDB tables are good for intensively updated tables, which can have many long selects running at the same time. They are also good choice for storing sensitive information, such as user registration information or financial data, and of course you should use these tables if you need ACID transactions. In case you have really large table with many indexes it could be worth to have it in InnoDB type - you will not have to recover the table in case of unclean shutdown, which could take hours"

"In typical web application MyISAM table could be used for logging and search, InnoDB tables for registration information and banner system, while Heap table for temporary tables and pre generated news headlines and other data for high load pages."

I don't know the data model of the forum, may be we could change just one table to InnoDB and everything would work fine after that.

[Palych]

I don't know the data model of the forum, may be we could change just one table to InnoDB and everything would work fine after that.

I believe it's a great place to start with!
I'll try to draw up some chart with tables and operations being performed for typical activities...

[Palych]

С ходу мне видится первый кандидат на перевод в InnoDB: phpbb_topics.

Ета операция выполняется при каждом просмотре топика:

Code: Select all

UPDATE phpbb_topics SET topic_views = topic_views + 1 WHERE topic_id = ${TopicID}

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

Что скажут мэтры по этому поводу?

[vovap]

Что скажут мэтры по этому поводу?

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