Milyen vasat ajánlotok egy webáruház alá?

Fórumok

Hali,

A véleményetekre vagyok kiváncsi, hogy milyen hardvert ajánlotok a következő paraméterekkel rendelkező webáruház alá?
Jelenleg is működik, de kicsit köhög és szerintem a vas nem bírja, az hogy mi van most alatta azt nem árulták el nekem. LOLA következő infóm van róla:

Az hogy majd frissíteni kell a rendszert, most nem ide tartozik.
Oprendszer: Archlinux 3.0.27 kernel
Szolgálatások: LAMP (Apache 2.2.22, PHP 5.3.10, MySQL 5.5.23)
Apache virtualhost: 2 (http és https)


Server Version: Apache/2.2.22 (Unix) mod_ssl/2.2.22 OpenSSL/1.0.1a DAV/2 PHP/5.3.10 with Suhosin-Patch
Server Built: Feb 8 2012 10:27:28
Server loaded APR Version: 1.4.5
Compiled with APR Version: 1.4.5
Server loaded APU Version: 1.4.1
Compiled with APU Version: 1.4.1
Timeouts: connection: 60    keep-alive: 5
MPM Name: Prefork
MPM Information: Max Daemons: 250 Threaded: no Forked: yes
Server Architecture: 64-bit
Server Root: /etc/httpd
Config File: /etc/httpd/conf/httpd.conf
Server Built With: 
 -D APACHE_MPM_DIR="server/mpm/prefork"
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
 -D APR_USE_SYSVSEM_SERIALIZE
 -D APR_HAS_OTHER_CHILD
 -D AP_HAVE_RELIABLE_PIPED_LOGS
 -D HTTPD_ROOT="/etc/httpd"
 -D SUEXEC_BIN="/usr/sbin/suexec"
 -D DEFAULT_ERRORLOG="logs/error_log"
 -D AP_TYPES_CONFIG_FILE="conf/mime.types"
 -D SERVER_CONFIG_FILE="conf/httpd.conf"

php.ini


session.auto_start = 1
short_open_tag = On
error_reporting  = E_ALL & ~E_NOTICE
max_execution_time = 60
max_input_time = 120
memory_limit = 300M
max_input_vars = 2000
register_globals = Off
magic_quotes_gpc = Off
register_long_arrays = Off
register_argc_argv = Off
display_errors = Off
post_max_size = 128M
allow_url_include = On
file_uploads = On
upload_tmp_dir = /tmp
upload_max_filesize = 128M
max_file_uploads = 50
extension = bcmath.so
extension = bz2.so
extension = gd.so
extension = iconv.so
extension = imap.so
extension = mcrypt.so
extension = mssql.so
extension = mysqli.so
extension = mysql.so
extension = openssl.so
extension = pdo_mysql.so
extension = posix.so
extension = soap.so
extension = tidy.so
extension = xmlrpc.so
extension = xsl.so
extension = zip.so

my.cnf


bind-address                    = 0.0.0.0
port                            = 3306
socket                          = /var/run/mysqld/mysqld.sock
pid-file                        = /var/run/mysqld/mysqld.pid
log-error                       = /var/log/mysql/mysqld.err
basedir                         = /usr
tmpdir                          = /mnt/database/tmp
datadir                         = /mnt/database/mysql
skip-external-locking
back_log                        = 50
max_connections                 = 200
max_connect_errors              = 100000
wait_timeout                    = 7200
interactive_timeout             = 7200
connect_timeout                 = 10
net_buffer_length               = 16384
table_open_cache                = 200000
table_definition_cache          = 200000
max_seeks_for_key               = 1000
group_concat_max_len            = 1024
max_allowed_packet              = 256M
binlog_cache_size               = 1M
read_buffer_size                = 1M
join_buffer_size                = 1M
read_rnd_buffer_size            = 2M
sort_buffer_size                = 4M
thread_cache_size               = 1024
thread_concurrency              = 16
concurrent_insert               = 2
query_cache_type                = 1
query_cache_size                = 256M
query_cache_limit               = 8M
query_prealloc_size             = 262144
query_alloc_block_size          = 65536
range_alloc_block_size          = 4096
transaction_alloc_block_size    = 8192
transaction_prealloc_size       = 4096
ft_min_word_len                 = 4
default-storage-engine          = MyISAM
thread_stack                    = 256K
tmp_table_size                  = 512M
max_heap_table_size             = 512M
open_files_limit                = 8192
key_buffer_size                 = 24G
bulk_insert_buffer_size         = 8M
myisam_sort_buffer_size         = 1G
myisam_repair_threads           = 1
myisam_recover
skip-innodb

Átlagos napi látogatók száma: 9000

Nincs sehol too many connection, nincsenek hibák, csak néha baromi lassú. MySQL-ben kb. 3000 tábla van, külön fájlokban, a legnagyobb 30GB, kb. 10 tábla 1-10GB közötti, a többi 1GB alatti, összesen 130GB.
Néha a query/sec:30 ezer is lehet, de átlagban 12 ezer közül van.

Néhány MySQl adat, igaz csak 2 órás üzemidő.


Questions since startup: 49,825,059
ø per hour:  25,954,307
ø per minute:   432,572
ø per second:     7,210

Traffic               ø per hour
Received:  20.3 GiB   10.6 GiB
Sent:     107.9 GiB   56.2 GiB
Total:    128.2 GiB   66.8 GiB

Connections:                       ø per hour  %
max. concurrent connections  33    ---         ---
Failed attempts               1    0.52        <0.01%
Aborted	                      0    0           0%
Total                       299 k  155.76 k    100.00%

Statements		# 	 ø per hour	%
change db		38,446 k 20 M		77.16%
select			9,226 k	 4,806.1 k	18.52%
set option		569 k	 296.2 k	1.14%
begin			525 k	 273.6 k	1.05%
commit			525 k	 273.6 k	1.05%
update			277 k	 144.1 k	0.56%
insert			116 k	 60.3 k		0.23%
replace			56,518	 29.4 k		0.11%
delete			44,031	 22.9 k		0.09%
insert select		37,069	 19.3 k		0.07%
show status		934	 486.5		<0.01%
show fields		642	 334.4		<0.01%
show slave status	557	 290.1		<0.01%
show master status	557	 290.1		<0.01%
show processlist	383	 199.5		<0.01%
show table status	322	 167.7		<0.01%
show tables		107	 55.7		<0.01%
replace select		83	 43.2		<0.01%
optimize		70	 36.5		<0.01%
show variables		53	 27.6		<0.01%
show binlogs		5	 2.6		<0.01%
show databases		4	 2.1		<0.01%
show grants		1	 0.5		<0.01%
show plugins		1	 0.5		<0.01%


Created tmp disk tables: 28.3 k
The number of temporary tables on disk created automatically by the server while executing statements. If Created_tmp_disk_tables is big, you may want to increase the tmp_table_size value to cause temporary tables to be memory-based instead of disk-based.

Handler read rnd: 36.2 M
The number of requests to read a row based on a fixed position. This is high if you are doing a lot of queries that require sorting of the result. You probably have a lot of queries that require MySQL to scan whole tables or you have joins that don't use keys properly.

Handler read rnd next: 531 M
The number of requests to read the next row in the data file. This is high if you are doing a lot of table scans. Generally this suggests that your tables are not properly indexed or that your queries are not written to take advantage of the indexes you have.

Select full join:109
The number of joins that do not use indexes. If this value is not 0, you should carefully check the indexes of your tables.

Slow queries:295
The number of queries that have taken more than long_query_time seconds.Documentation

Sort merge passes:253
The number of merge passes the sort algorithm has had to do. If this value is large, you should consider increasing the value of the sort_buffer_size system variable

Table locks waited:105.8 k
The number of times that a table lock could not be acquired immediately and a wait was needed. If this is high, and you have performance problems, you should first optimize your queries, and then either split your table or tables or use replication.

Amit én ezekből leszűrök, hogy az adatbázis a szűk keresztmetszet, és eléggé meg van hajtva, azt mondják, hogy a top process a mysqld és kb. 60% CPU-t folyamatosan eszik.
Ezek alapján én valamilyen Xeon E5-ös 8 magos 3GHz szervert, leglalább 64GB RAM-al, SAS 15k-s diszkekkel pakolnék alá.

Hozzászólások

Ezek az információk semmik... statisztikai adatok kellenének leginkább (memoria, swap, cache, buffer, CPU terhelés, iowait, olvasás/írás etc...) mi az h. 60% CPU -t eszik?

Leginkább az sql és a cache SSD -re pakolásával lehetne segíteni meg a megfelelő beállításokkal finomhangolni. Persze legyen azért 32GB RAM meg elég CPU.

Amíg nincsen megfelelően tervezve, méretezve a várható ill. valós terheléssel addig csak szócséplés az egész :-)

A top szerint a mysqld a CPU-kat 60%-ban terheli. A CPU 4 magos 32GB van alatta, disk io alig van, szerintem az SQL többnyire a memóriában dolgozik.


$dstat --disk-tps --top-io-adv --disk-util --top-bio-adv 1
-dsk/total- -------most-expensive-i/o-process------- sda- sdb- sdc- sdd- sde- sdf- ----most-expensive-block-i/o-process----
reads writs|process              pid  read write cpu|util:util:util:util:util:util|process              pid  read write cpu
   0     0 |mysqld               6424   54M  14M 59%|   0:   0:   0:   0:   0:   0|mysqld               6424    0  560k 59%
   2     0 |mysqld               6424   82M  20M 54%|   0:   0:   0:   0:2.00:   0|mysqld               6424    0  564k 54%
   1     0 |mysqld               6424  150M  27M 57%|   0:   0:   0:   0:1.00:   0|mysqld               6424    0  956k 57%
  22   214 |mysqld               6424   78M  22M 57%|13.0:13.0:4.00:   0:   0:   0|sync_supers          24      0  688k  0%
  66     6 |mysqld               6424   99M  26M 66%|2.00:2.00:11.0:   0:9.00:   0|mysqld               6424  320k 604k 66%
  11     0 |mysqld               6424   86M  14M 62%|   0:   0:   0:   0:11.0:   0|mysqld               6424    0  644k 62%
  27     0 |mysqld               6424  253M  15M 70%|   0:   0:6.00:   0:5.00:   0|mysqld               6424  104k1140k 70%
   2    88 |mysqld               6424   75M8663k 68%|   0:   0:   0:   0:2.00:   0|mysqld               6424    0  688k 68%
   1     0 |mysqld               6424   15M  12M 54%|   0:   0:   0:   0:1.00:   0|mysqld               6424    0 4288k 54%
   3   344 |mysqld               6424   48M  33M 68%|10.0:12.0:9.00:   0:   0:   0|mysqld               6424   12k3948k 68%

$cat /proc/meminfo 
MemTotal:       33000876 kB
MemFree:          880764 kB
Buffers:          625936 kB
Cached:         24930600 kB
SwapCached:         6952 kB
Active:         15593256 kB
Inactive:       13083932 kB
Active(anon):    2861852 kB
Inactive(anon):   234676 kB
Active(file):   12731404 kB
Inactive(file): 12849256 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:       8388540 kB
SwapFree:        8373456 kB
Dirty:             31352 kB
Writeback:             0 kB
AnonPages:       3028120 kB
Mapped:            33792 kB
Shmem:             62264 kB
Slab:            3045704 kB
SReclaimable:    3020560 kB
SUnreclaim:        25144 kB
KernelStack:        1496 kB
PageTables:        37964 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    24888976 kB
Committed_AS:    8340656 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      152480 kB
VmallocChunk:   34359564984 kB
HardwareCorrupted:     0 kB
AnonHugePages:         0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:       11904 kB
DirectMap2M:    33525760 kB

nginx + rendes I/O alá és százszorozod a teherbírást.

Mondjuk 3000 tábla elég betegnek hangzik egy webshophoz. Ráadásul napi 9000 látogatóhoz 30.000query/sec? Ott valami nagyon komoly programozási hiba van abban a webshopban (ciklusban selectben ciklusban selectben ciklusban select?)

Ez csak annyit jelent, hogy sok munkaórával fog járni. Ne azt képzeld, hogy ezt bárki áttoldozza jóra... Szarból nem lehet várat építeni(ezt ne vedd magadra, nem téged akarlak minősíteni). Ilyenkor le szokás ülni, specifikálni hogy mi kell(minden ami van, meg ilyenkor megjelennek a dejólennehamégeztis igények), terveznek, majd felépítenek egy rendszert, amibe ha a tesztek rendben mentek, migrálják az adatbázist egy szép pénteki éjszakán, hogy aztán hétfőre biztosan fusson.

Első körben mindenképpen próbálj meg megmérni minél több paramétert működés közben, mert enélkül nem fogsz tudni viszonyítani.
Ha csak hardvercserét engednek, akkor SSD, nginx, APC, Xcache, stb. Nem ragoznám írtak nagyon jókat: http://hup.hu/node/135716#comment-1787113
Lehet nem engedik a rendszert újraírni, de ha szép komótosan bevezettek apróbb dolgokat és mellékeled a mért számokat, hogy a kód fejlesztése százalékosan többet hozott mint a hardvercsere, akkor lehet hagyni fogják, hogy rendesen megcsinálja valaki.

"Átlagos napi látogatók száma: 9000. MySQL-ben kb. 3000 tábla van, külön fájlokban, a legnagyobb 30GB, kb. 10 tábla 1-10GB közötti, a többi 1GB alatti, összesen 130GB. Néha a query/sec:30 ezer is lehet, de átlagban 12 ezer közül van."

Ennek eléggé félretervezett "szaga" van, valószínűleg nincs az a hardver, amivel ez jól fog működni... :/
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Mielőtt csillióbilliót fogtok HW-re költeni:

- MySQL-ből a régi, fölösleges adatok törlése vagy archiválása (gyanítom, hogy borzasztó mennyiségű adatot küld vissza a MySQL a php-nak...)
- MySQL tuning, pl. a query cache tekintetében
- PHP-nál Opcode cache (XCache, APC ízlés szerint) beállítása és egyéb apró tuningok (file cache idők és méretek)
- Szintén PHP-nál megvizsgálni, hogy fastcgi+php-fpm -re át lehet-e térni
- Fölösleges Apache és PHP csomagok kikapcsolása
- A borzalmas mennyiségű mysql query okát meg kell vizsgálni, mert szinte biztos vagyok benne, hogy a fejlesztők tudnak rajta faragni/optimalizálni.

Ha ezek megvannak, akkor kell nézni valamilyen vasat, de egyébként egy single CPU E5 jó lehet, bár erős overkill lesz elsőre.

Milyen bolti keretrendszer van alatta?

szerintem forditva ulod meg a lovat, mert az alkalmazas mellett kene lenni annak az infonak, hogy a hw igenye ez es ez. Aztan ha 'kohog a vas', ahogy irod, akkor nem az az 1. lepes, hogy 2x akkora vasat teszel ala, hanem eloszor azt szoktak megkeresni, hol a bottleneck?

Sorrendben:

#1: az alkalmazas koser-e?
#2: a kapcsolodo alkalmazasok (elsosorban apache, mysql es php) rendben vannak-e? Pl. tablakon ertelmes indexek, etc. A mysql optimalizalas onmagaban egy kulon topik lehet
#3: az OS megfeleloen van-e beallitva, pl. max open files, etc.

Ha pedig az elobbiek mar mind ki vannak maxolva, ami az optimalizalast illeti, akkor johet a vegyunk meg memoriat, ssd-t, ...

Ha van 10-30k sql query / sec, akkor erdemes lenne memcached vagy hasonlo beiktatasan elgondolkodni. Vagy pl. elore legyartani par kritikusabb query eredmenyet (a google sem hajtja vegre 200 csillio pornora valo select-et, hanem legyartjak a query eredmenyet, aztan neked mar csak az elore elkeszitett eredmenyt adjak oda). De ehhez tudni kene, hogy miket kerdezel le, lehet-e ertelmesen cache-elni, etc. Es persze ehhez az alkalmatast is modositani kell.

Ha mar mysql, akkor erdekes, hogy egy webaruhaznal miert van 20M "change db" query. Ill. a myisam-ot preferalod az innodb, etc. helyett. Erdemes lenne az adatokat es a felhasznalast is figyelembe veve elgondolkodni, hogy ez jol van-e igy? Lehet, hogy az jon ki, hogy igen, de esetleg az is lehet, hogy nem.

Ugy latatlanban ennyi kezdeskent.

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

Most min fut, milyen hardver?
Slow queries log van, azt nézted?

Sakk-matt,
KaTT :)

Értem én, hogy mit írtok, meg tudom is, hogy mi a probléma. A kérdés az volt, hogy szerintetek milyen vas szolgálja ezt ki? Ugyanis meg kell győzni a vezetőséget, hogy vagy optimalizálással és hibakereséssel folglalkoznak ("ami szerintük időpazarlás és nem hoz pénzt") vagy erősebb vas kell alá.

Remélem így már értitek, hogy mi a kérdésem? Mert szerintük a mostani vas teljesen jó és biztos valami el lett állítva.
Azt hittem a kérdés egyértelmű, mert nem azt kérdeztem, hogy mit lehet javítani rajta? Azzal én is tisztában vagyok.

Hát a vas tuningban egy nginx webszervert próbáljatok apache2 helyett, és SSD-t szerintem. De a baj az, hogy a szoftverben nem kis optimalizálni való van, hanem nagyon-nagyon-nagyon-nagyon-NAGYON durva tervezési hiba.
Az általad említett látogatószámnak egy $99-s robotos TV játékoson el kellene mennie (ha nincs benne online GD-s kép manipuláció), de ha egy közepes fejlesztő csinálja, akkor is 1 darab Xeonnak 2G RAM-mal nevetve vinnie kellene. Ennyire nagy a szoftveres baj.

meg kell győzni a vezetőséget, hogy vagy optimalizálással és hibakereséssel folglalkoznak ("ami szerintük időpazarlás és nem hoz pénzt") vagy erősebb vas kell alá.

azt is mondd el nekik, hogy ha egy kalap kakamassziv optimalizalas szukseges a webaruhazon, akkor az konnyen lehet, hogy nem tudja megfeleloen kihasznalni azt sem, ha 2-3-4x akkora hw eroforrast tolsz ala, ami igy csak penzkidobas lesz, es ugyanott vagytok, hogy meg mindig 'kohog a cucc'...

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

" A kérdés az volt, hogy szerintetek milyen vas szolgálja ezt ki? "
Ha nem jó a kód, akkor semmi nem fogja kiszolgálni mert idővel kimerít bármit. Kb. mintha a csöpögő csap problémáját egy nagyobb fazék alárakásával szeretnéd megszüntetni. Nem fog menni. Ha neked nem hisznek, linkeld nekik a topicot. Bár az azért elég meredek, hogy egy vezető a 10 éves rendszert ne legyen hajlandó felülvizsgálni. Egyrészt 10 éve is lehetett nagyon jó minőségű kódot írni, másrészt azóta születtek olyan megoldások, amik csak segítik a folyamatot. Sajnos sok vezető képtelen rendszerben gondolkodni és megérteni, hogy a programozó olyan dolgokat tud megoldani, amit a puszta hardver vásárlása nem oldana meg. Ha a szoftver és a hardver nincsenek összehangolva, akkor nem lesz optimális megoldás.
Ha a vas szerintük jó és a 10 évvel ezelőtti rendszer is jó, akkor hagyd rájuk.

Csináltattam rendszert. Ott kezdődött, hogy a programozók egy hónapig _tervezték_ az adatbázist a követelménjegyzék meg a speckó alapján. Kívülről annyit lehetett látni, hogy álló nap kávéznak. Sok vezető ezt a részt nem képes elfogadni, mert az a kényszerképzetük, hogy a programozás megállás nélküli kódolásból áll. Amelyik programozó nem kódol éppen, az lopja a napot. Ja, meg ugye a másik fixa-ideájuk, hogy a bikavas mindent megold. Mindent.

"Nincs végtelen ciklus, csak gyenge a processzorod" :D

Én hobbi szinten scriptelek, de még az is nagyon sokat számít, hogy az SQL-ben milyen a WHERE feltétel sorrendje. Plusz a kezdő/lusta/buta fejlesztők előszeretettel kérdezik le a teljes táblát, válogatják ki PHP-val ciklusban, majd ugyanebben a ciklusban kérdeznek le meg komplett táblát és válogatnak benne és így tovább... A JOIN, HAVING, WHERE, GROUP BY, LIMIT esetleg prepared statementek mesébe sincsenek... Pedig ezek még alap dolgok.

Rossz a megkozelites. Javitani azon tudsz, amit meg tudsz merni. Ha valakit meg akarsz gyozni nem art ha ugyanazt a nyelvet beszeled, amit ok.

"Tests at Amazon revealed similar results: every 100 ms increase in load time of Amazon.com decreased sales by 1% (Kohavi and Longbotham 2007). Experiments at Microsoft on Live Search showed that when search results pages were slowed by 1 second: (Kohavi 2007)"

" Shopzilla found that by moving their page load time from 4 - 6 seconds to around the 1 second mark resulted in a 7 - 12% increase in conversion rate."

http://www.websiteoptimization.com/speed/tweak/psychology-web-performan…
http://assets.en.oreilly.com/1/event/29/Shopzilla%27s%20Site%20Redo%20-…

Ha a "penz" a fenti mutatoknak is a fuggvenye, akkor miert nincsenek ezek is merve?
Miert nincs minden egyes funkciohoz es muvelethez "koltseg" (eroforrashasznalat, kesletetes, sql lekerdezesek szama, stb) rendelve?

"Ugyanis meg kell győzni a vezetőséget, hogy vagy optimalizálással és hibakereséssel folglalkoznak ("ami szerintük időpazarlás és nem hoz pénzt") vagy erősebb vas kell alá."

Fontos kérdés: van tesztkörnyezet, ahol lehet szabadon játszani?
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Mert szerintük a mostani vas teljesen jó

Hát, 4 core és 32GB RAM eléggé úgy hangzik, mint ami bármire elég, már ha nem meteorológiai vagy atomrobbantás szimulációkról beszélünk, mert arra az világ összes CPU-ja sem elég.
Diszk I/O szintjén ha most nincs benne SSD, akkor azzal azért sokat lehet dobni a gép tudásán (ergó legyen), a 30k meg 12k query/sec-eken viszont az sem segítene.

és biztos valami el lett állítva.

Látatlanban azt mondom, hogy igen, valami biztosan el lett állítva, mégpedig az alkalmazás architektúrája.
Ezt már csak az is alátámasztja, hogy egy >10 éves, php-ban megírt, azóta toldozgatott-foldozgatott alkalmazáshoz szinte biztos, hogy architektúra szintjén hozzá kellene nyúlni (a sok query/sec is erősen errefelé mutat).
Azon lehet elmélkedni, hogy súlyos műtét (gerinc- és agyátültetés szintjén), vagy mint a cigánygyerekes viccben: kidobni és csinálni újat. Ha nincs meg az a csapat, aki tervezte/álmodta/írta a jelenlegi php-s kódot, és/vagy azóta se fejlődtek szakmailag, akkor valószínűleg az utóbbi megoldás a nyerőbb...

Mit csinalnak a mysql threadek? aka. Poor Man Profiler gdb alapon:


#!/bin/bash
nsamples=1
sleeptime=0
pid=$(pidof mysqld)

for x in $(seq 1 $nsamples)
do
gdb -ex "set pagination 0" -ex "thread apply all bt" -batch -p $pid
sleep $sleeptime
done | \
awk '
BEGIN { s = ""; }
/^Thread/ { print s; s = ""; }
/^\#/ { if (s != "" ) { s = s "," $4} else { s = $4 } }
END { print s }' | \
sort | uniq -c | sort -r -n -k 1,1

Az adatok (tablak) particionalasa nem feltetlen az ordog muve - kulonosen ha gyors a (be- es kiaramlo) adatfolyam.
50k+ tabla felett mar izgalmasabb az elet a rengeteg metaadat miatt, ami mar nem feltetlen fer el memoriaban.

Ha mar a hatarokat feszegetjuk, erdemes ezt a projectet is megemliteni (~34h ideig futott, ~8000 tabla / sec amit elert):

"The Billion Tables Project

Aka how long a "\dt" takes on a 1B tables database

Usually “large” databases are considered as such for the high number of records they hold, reaching billions or even more than that. But what about creating a billion... tables?"

http://www.pgcon.org/2013/schedule/events/595.en.html

Ennyibol (legalabbois szamomra) nem derul ki, h mi a szuk keresztmetszet, igy nem is lehet megmondani, h mi szolgalna ki. Ha vaktaban alateszel vmit, attol nem lesz jobb feltetlenul.
Ha a HW-t akarjatok fejleszteni, akkor nezd meg, mi a szuk keresztmetszet es azon fejlessz.

Ezert kapsz mindenkitol olyan valaszt, amilyet. Meg lehet erobol is oldani, de ahhoz is utana kell jarnod.

Köszönöm mindenkinek a hozzászólását. Úgy nézki, hogy kód és adatbázis optimalizálás lesz ebből.

Az átlag napi 9000 felhasználó mellett nem lehet még napi kismillió keresőrobot, spamrobot, jelszó próbálgatás,...?
A statisztikák (Google analitika,...) ezeket ki szokták szűrni, viszont az adatbázis terhelésben (is) látványosan megjelenhet.
Mivel azt írod, sok termék van, azaz sok oldal,... ez biztosan jelentős terhelés lehet.

Persze a 3000 tábla még így is elgondolkodtató...

Azt már többen is kifejtették. Lehet, hogy minden terméket külön táblában tartanak :)

Viszont ha ki tudják szűrni a felesleges/káros robotok nagy részét (ha jelenleg nincs így), jelentősen csökkenne a szerver terhelése.
Arról nem írt, hogy mennyi az adatbázis műveletet is érintő oldal letöltések száma. A napi 9000 (webshop) látogató nem akarom elhinni, hogy túl tud terhelni egy mai szervert.
Fail2ban, ipset, különböző szűrések a webszerveren... csodákra képesek, ha az a gond, amit írok.

Hát már hogyne tudna, a fejlesztők mindenre képesek. Nekem a kedvenc példám egy konkrét webáruház, ami olyan 1Mbit/sec kimenő forgalomhoz (tehát képekkel, javascripttel, css-el, html-el és minden kutyafülével együttes 1Mbit/sec-ről beszélünk) olyan 4-5Mbit/sec MySQL adatbázis forgalmat generál. Mindezt úgy, hogy az előző fejlesztő csapat 30-40db fölöslegesnek ítélt lekérdezéstől megszabadította a lapletöltést. Természetesen a jelenlegi forgalom nagyon kényelmesen fut, de ha véletlenül megszalad a látogatók száma, akkor azért már feltorlódnak a juzerek és érezhetően lelassul. Külön bónusz, hogy a kliens oldalt is szivatják, mert nem használnak (még) CSS vagy JS aggregálást és +20 hit a szerver felé, valamint olyan 10 féle ilyen beépülő google statisztika szerint cucc van.

Nulladik körben itt érdemes megnézni, hogy mit mond a weboldalról: http://tools.pingdom.com/fpt

Szerk: A robokat nem lehet érdemben szűrni, csak időszakosan és hellyel-közzel. A referük szinte biztosan változik vagy eleve teljesen összevissza IP címekről és normál kliensnek "álcázva" jönnek.

Azért remélem a példád elég szélsőséges.
Amióta a Google nyomja a "gyorsítsuk fel a webet", és adja hozzá az ötleteket, eszközöket, szerintem sokat javult a helyzet. A CSS, JS aggregálás, a böngésző oldali gyorsítótárazás,... is egyre jobban terjed.

Van olyan oldalunk, amit kb fél éve folyamatosan bombáznak olyan kérésekkel, amik tartalmazzák a action=login részt. Könnyű szűrni. Fogalmam sincs miért nem kopnak le (lehet vagy napi 50000 kérés, ha kikapcsoljuk a szűrést), mert semmit nem érnek el. Lehet hasonló probléma ott is. De csak egy ötletnek szántam, mert többször találkoztunk ilyennel.
Tény, hogy nem mindent lehet könnyen szűrni, de a saját tapasztalat az, hogy jelentősen lehet javítani a helyzeten.

Azon kivul hogy egyetertek a kod/adatbazis optimalizalas elsobsegevel, mert mar megtalaltad a leggyengebb lancszemet, van valami amit nem ertek.

"hogy mi van most alatta azt nem árulták el nekem"

Hogyan varja el barki hogy megjavits valamit amirol azt sem tudod hogy nez ki, pontos spec es foleg monitoring nelkul az egesz vaktaban talalgatas, tudni kell hogy a HW melyik resze a kritikus IO / MEM / CPU stb, aztan hogy milyen aranyban zabaljak fel az processek az eroforrasokat, stb stb.

Szerverenkent legalabb 2-300 metric az ami alapjan lehet felelos dontest hozni, lehetoleg hosszabb mintavetel alapjan.
Es csatlakozva kiuka hozzaszolasahoz itt egy gondolatebreszto http://puppetlabs.com/presentations/puppet-camp-london-2014-how-measure…