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

[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]

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

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

[Palych]

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

Какие проблемы с этим?

Наконец, при этом должны вроде как работать два движка, что тоже наверное, не лучше для производительности.

Не два движка, а два участка кода. Никакого влияния на производительность не набдюдаю. Преимуществ же - масса: возможность выбирать формат в зависимости от шаблона использования.
Что приводит меня (видного специалиста в области СУБД) к логичному и научнообоснованному выводу:

MySQL RULEZ!!!

[tengiz]

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

Code: Select all

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

При етом просмотр топика - самая популярная операция. Она кроме указанноро апдейта содержит кучу селектов.

А покажите весь код просмотра отдельной дискуссии? Я так понимаю, что там вначале для обеспечения deadlock free a-la MySQL должны быть заблокированы все таблицы посредством замечательной инструкции LOCK TABLES включая запрос на эклюзивную блокировку phpbb_topics. Откуда фактически получается полная сериализация доступа и многопользовательская СУБД преврещается в строго однопользовательскую даже для просмотра. Да, это, мягко говоря, не очень не очень хорошо.

[Palych]

А покажите весь код просмотра отдельной дискуссии?

Code: Select all

SELECT *
   FROM phpbb_config
-- --
SELECT t.topic_id, t.topic_title, t.topic_status, t.topic_replies, t.topic_time, t.topic_type, t.topic_vote, t.topic_last_post_id, f.forum_name, f.forum_status, f.forum_id, f.auth_view, f.auth_read, f.auth_post, f.auth_reply, f.auth_edit, f.auth_delete, f.auth_sticky, f.auth_announce, f.auth_pollcreate, f.auth_vote, f.auth_attachments
   FROM phpbb_topics t, phpbb_forums f
   WHERE t.topic_id = 30
      AND f.forum_id = t.forum_id
      
-- --
SELECT u.*, s.*
         FROM phpbb_sessions s, phpbb_users u
         WHERE s.session_id = '63326857c88170869c27a0d59906133f'
            AND u.user_id = s.session_user_id
-- --
UPDATE phpbb_sessions 
                  SET session_time = 1082948574, session_page = 3 
                  WHERE session_id = '63326857c88170869c27a0d59906133f'
-- --
DELETE FROM phpbb_sessions 
                  WHERE session_time < 1082944974 
                     AND session_id <> '63326857c88170869c27a0d59906133f'
-- --
SELECT *
      FROM phpbb_themes
      WHERE themes_id = 1
-- --
SELECT u.username, u.user_id, u.user_posts, u.user_from, u.user_website, u.user_email, u.user_icq, u.user_aim, u.user_yim, u.user_regdate, u.user_msnm, u.user_viewemail, u.user_rank, u.user_sig, u.user_sig_bbcode_uid, u.user_avatar, u.user_avatar_type, u.user_allowavatar, u.user_allowsmile, p.*,  pt.post_text, pt.post_subject, pt.bbcode_uid
   FROM phpbb_posts p, phpbb_users u, phpbb_posts_text pt
   WHERE p.topic_id = 30
      
      AND pt.post_id = p.post_id
      AND u.user_id = p.poster_id
   ORDER BY p.post_time ASC
   LIMIT 0, 15
-- --
SELECT *
   FROM phpbb_ranks
   ORDER BY rank_special, rank_min
-- --
SELECT word, replacement
      FROM  phpbb_words
-- --
SELECT c.cat_id, c.cat_title, c.cat_order
      FROM phpbb_categories c, phpbb_forums f
      WHERE f.cat_id = c.cat_id
      GROUP BY c.cat_id, c.cat_title, c.cat_order
      ORDER BY c.cat_order
-- --
SELECT *
         FROM phpbb_forums
         ORDER BY cat_id, forum_order
-- --
UPDATE phpbb_topics
   SET topic_views = topic_views + 1
   WHERE topic_id = 30
-- --
SELECT * FROM phpbb_smilies
-- --

[Privet]

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

1. Вариант с InnoDB меня, честно говоря, заинтересовал. Переходить на MS SQL можно будет только после запуска нового сервера, который откладывается из-за того, что микросхема с BIOS прошилось криво и сейчас motherboard скорее мертва, чем жива. ПОка мы живём на том, что есть и надо попробовать эффективно использовать имеющиеся ресурсы. Я постораюсь что-нибудь сделать в субботу-воскресенье. Попробую создать клон форума на InnoDB. Наверно, всё-таки в воскресенье. Надо немного отойти от работы. 60-часовая безрезультатная рабочая неделя несколько выматывает.

2. Что касается CGI, то у меня давно на него аллергия. До какого-то времени я всё-таки надеялся, что PHP SAPI будет доведён до ума. Увы... Прилаживать левые ускорители я бы не хотел, но, если найду ссылки на интересный опыт, подумаю. Насчет Апачи тоже подумаю и поэкспериментирую с proxy на IIS, который гоняет .NET. Рекомендации на этот счет я получил. Кто найдёт дополнительнуюинформацию - дайте знать.

Ситуация, как я понимаю, не так уж и плоха. ПОймать блокировку нам удаётся не каждый день.

[Palych]

1. Вариант с InnoDB меня, честно говоря, заинтересовал. ... Попробую создать клон форума на InnoDB. Наверно, всё-таки в воскресенье.

Consider this:

BTW, Lanzer, are you working with MyISAM or InnoDB tables?

Right now basically anything that gets updated in less than a second is running InnoDB:

users table
topics table
search wordlist
search results
privmsgs table and text
posts table and text
forums table

The rests are still MyISAM since they are so much faster to scan.

http://www.phpbb.com/phpBB/viewtopic.ph ... =40#847981

[Privet]

Наверное, так и сделаю. Там ещё предлагаются некоторые модификации. Я посмотрю, что я могу использовать.

Любые советы и комментарии будут полезны. Даже если я не отвечаю, я просматриваю топик и принимаю многие вещи к сведению. Если считаете что-то важным, то я я не возражаю, если это будет повторено в топике несколько раз.

[Palych]

2. ... Насчет Апачи тоже подумаю и поэкспериментирую с proxy на IIS, который гоняет .NET. Рекомендации на этот счет я получил. Кто найдёт дополнительнуюинформацию - дайте знать.

Code: Select all

(httpd.conf)
...
# not sure if it's required on Windows, but it won't hurt anyway....
LoadModule rewrite_module modules/mod_rewrite.so
...
# Whatever is root...
DocumentRoot "C:/opt/apache2/Apache2/htdocs"
...
<Directory "C:/opt/apache2/Apache2/htdocs">
    RewriteEngine On
    RewriteBase   /
    RewriteRule   ^dotnetsite/(.*)$  http://privet.com:3333/dotnetsite/$1 [R]
.
.
.

http://httpd.apache.org/docs-2.0/mod/mo ... ewriterule

This is a bit tricky. Let me know if you'll run into problems.

[Privet]

Ок. Настроить прокси для .NET сайта проблем не составило.

Завтра, если будет время, попробую InnoDb

[Palych]

Ок. Настроить прокси для .NET сайта проблем не составило.

Оно что уже под Apache бегает?

[vovap]

Оно что уже под Apache бегает?

Так вот если бегает - то эту причину можно спокойно отвести. Я сегодня видел несколько классических торможений в добой основательной манере.

[Siberian Cableman]

Тут на RSDN появилась статья проливаюшая немного света на работу MS SQL Server. Она наверное поможет и общему пониманию DB
Deadlocks. Что такое взаимоблокировки и как с ними бороться http://www.rsdn.ru/article/db/deadlocks.xml

[Palych]

А знаете ливы что [PHP] оказывается умеет сессии! (Я тут покопался в наших поделках)
В принципе ето может сократить хождения к серверу за статическими табличками [select * from phpnn_config; smiles, etc.]...
Естественно ето не заработает в CGI...

[A. Fig Lee]

А знаете ливы что [PHP] оказывается умеет сессии!

Конечно знаем. Какой пакедж не возьмешь, везде ето повсеместно.

[Merle]

Тут на RSDN появилась статья проливаюшая немного света на работу MS SQL Server. Она наверное поможет и общему пониманию DB
Deadlocks. Что такое взаимоблокировки и как с ними бороться http://www.rsdn.ru/article/db/deadlocks.xml

Она большей частью написана под влиянием сообщений Tengiz'а, по крайней мере там, где речь идет об MSSQL, так что в данном случае лучше обратиться к первоисточнику..

[Privet]

Вопрос угас, но я хотел продолжить бы этот топик в связи с тем, что, похоже, заработал новый сервер. Я получил BIOS и он работает. После праздников продоложу.

Предполагается, что на новом сервере будет установлена БД.

Можем обсудить новую конфигурацию сервера.

P.S. Я появлюсь обратно только после праздников.