prestashop 1.7 Server Einstellungen für Importe

[tenga]

Hallo Liebe Community

wir betreiben einen Shop Version 1.7.2 aktuell und haben 3 Lieferanten von denen wir regelmässig eine CSV Datei erhalten.

Aktuelle haben wir einen Converter gebaut der die Preisstaffelung sowie die Parameter neu Konvertiert das dauert in der Regel einig Stunden.
Der Import wird über das Shop System gestartet und bei ca 140000 Artikel dauert das Stunden bis zu Tagen dabei ist der Server kaum am Arbeiten.

 

Server ist ein Intel XEON E5 mit 96 GB RAM und 4 SSD als RAID 10
Debian 8 mit Apache NGinx und OPcache PHP 7.2

 

Wir haben schon einige Tutorials Probiert paar sachen haben geholfen aber es ist denoch einfach zu langsam
An welcher Schraube kann man noch drehen, damit das schneller geht?

[TimmeHosting]

Gibt es irgendwelche Fehlermeldungem im Error-Log der Website? Wenn ihr den Import nicht unterbrecht, würde er tatsächlich Stunden oder Tage laufen und wird dann fertig? Läuft er nicht irgendwann in Timeouts vom PHP oder vom Webserver?

Wie sieht es aus, wenn ihr den Import in mehrere kleinere Chunks aufteilt?

[Claudiocool]

1. Warum macht ihr das nicht auf einem lokalen Rechner und schiebt das Ergebnis dann hoch? Das sollte am Schnellsten gehen.

2. Hast du Serverzugänge (SSH) und Berechtigungen, im System Änderungen durchzuführen? dann kannst du z.B. live sehen, was der Server gerade macht während einer solchen Aktion. Es gibt halt jenseits der php.ini noch viele andere Dinge, die man Einstellen kann/muss, um dem Server Beine zu machen.

[tenga]

Er macht das ohne Probleme den Import die Timeouts sind sehr hochgesetzt,

nur das dauert uns trotzdem zulange, Laut Server auslastung geht beim Import mysql etwas höher , CPU Auslastung generell nur 10% Auslastung
alles läuft auf https

Wir haben auf dem Server Plesk drauf mit PHP 7.2 und Opcache  Nginx mit Apache
Mysql Parameter haben wir schon diverse Probiert

SSH ist vorhanden.

[Claudiocool]

wenn du ssh hast, dann kannst du ja mit "top" nachsehen, was der Server so macht und eventuell, wo er noch Ressourcen frei hat. Die 10% würde ich an der Stelle nicht alleine bewerdten, weil es ja sein kann, dass der Server kurze Lastspitzen hat, die da kaum abgebildet werden.

Wenn du deine Nginx Konfiguration (/etc/nginx/nginx.conf) mal durchsiehst, findest du vielleicht auch ein paar kleine Flaschenhälse...

[tenga]

wir sind schon so einiges durch aber so richtig der WOW Effekt blieb aus, vielleicht liegt es an PHP selbst das er die Anfragen nicht schneller abarbeiten darf oder ich habe in mysql noch nen hänger auslastung ist aber nicht viel auf der Kiste.

#user  nginx;
worker_processes  auto;

#error_log  /var/log/nginx/error.log;
#error_log  /var/log/nginx/error.log  notice;
#error_log  /var/log/nginx/error.log  info;
error_log /var/log/nginx/error.log crit;

#pid        /var/run/nginx.pid;

include /etc/nginx/modules.conf.d/*.conf;

events {
    worker_connections  8096;
    multi_accept        on;
    use                 epoll;
}

worker_rlimit_nofile 100000;

http {
    include       mime.types;
    default_type  application/octet-stream;

    #log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
    #                  '$status $body_bytes_sent "$http_referer" '
    #                  '"$http_user_agent" "$http_x_forwarded_for"';

    #access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    tcp_nopush     on;

    #keepalive_timeout  0;
    keepalive_timeout  30;
	keepalive_requests 100000;
	send_timeout 2;
	client_body_timeout 10;
	reset_timedout_connection on;
        tcp_nodelay        on;
	client_max_body_size 100M;
	fastcgi_temp_file_write_size 10m;
	fastcgi_busy_buffers_size    512k;
	fastcgi_buffer_size          512k;
	fastcgi_buffers           16 512k;
	fastcgi_read_timeout 1200;
	ssl_session_cache shared:SSL:20m;
	ssl_session_timeout 180m;
	open_file_cache max=200000 inactive=20s; 
	open_file_cache_valid 30s; 
	open_file_cache_min_uses 2;
	open_file_cache_errors on;
	access_log off;

    #gzip_proxied any;
    #expires modified 6d;
    #gzip_types text/plain text/css text/javascript text/xml application/json application/javascript application/

    server_tokens off;

    include /etc/nginx/conf.d/*.conf;
}

# override global parameters e.g. worker_rlimit_nofile
include /etc/nginx/*global_params;

# * Fine Tuning
#
performance_schema                    = OFF
innodb_lock_wait_timeout              = 120
default_storage_engine                = InnoDB
thread_handling                     = pool-of-threads
thread_pool_size                    = 48 

# * Fine Tuning
#
key_buffer		= 128M
max_allowed_packet	= 16M
thread_stack		= 192K
thread_cache_size                               =360
thread_concurrency                              = 8
table_open_cache = 65000
table_open_cache_instances = 64
table_definition_cache	= 4096
join_buffer_size	= 256M
# This replaces the startup script and checks MyISAM tables if needed
# the first time they are touched
myisam-recover         = BACKUP
max_connections        = 300
table_cache            = 4096
#thread_concurrency     = 10
read_buffer_size                      = 2M
read_rnd_buffer_size                  = 2M
sort_buffer_size                      = 4M
tmp_table_size                        = 256M
max_heap_table_size                   = 256M
table_definition_cache                = 8192
open_files_limit = 65000
#
# * Query Cache Configuration
#
#query_cache_type 	= 1
#query_cache_limit	= 512K
#query_cache_size        = 128M 
#
# * InnoDB
innodb_buffer_pool_size               = 20G
#innodb_sort_buffer_size		      = 8M	
innodb_buffer_pool_instances          = 40
innodb_log_file_size                  = 10G 
innodb_log_files_in_group             = 2
#innodb_open_files		      = 102400
innodb_log_buffer_size                = 128M
innodb_flush_log_at_trx_commit        = 0
innodb_thread_concurrency             = 32
innodb_read_io_threads                = 16
innodb_write_io_threads               = 16
innodb_flush_method                   = O_DIRECT
innodb_file_per_table                 = 1
innodb_io_capacity                    = 300000
innodb_io_capacity_max 		      = 600000
innodb_file_format                    = Barracuda
innodb_buffer_pool_dump_at_shutdown   = ON
innodb_buffer_pool_load_at_startup    = ON
innodb_checksum_algorithm             = crc32
innodb_log_compressed_pages           = 0
# SSD
innodb_flush_neighbors                = 0
#innodb_random_read_ahead = 0
# Mutex contention
#innodb_adaptive_hash_index_partitions = 16
#innodb_adaptive_flushing		= OFF
#innodb_doublewrite			= OFF
#innodb_stats_on_metadata = OFF
#innodb_autoinc_lock_mode =2
#innodb_page_size 	= 4k
innodb_sync_array_size              = 48
#
# InnoDB is enabled by default with a 10MB datafile in /var/lib/mysql/.
# Read the manual for more InnoDB related options. There are many!
# * Logging and Replication
#
# Both location gets rotated by the cronjob.
# Be aware that this log type is a performance killer.
# As of 5.1 you can enable the log at runtime!
#general_log_file        = /var/log/mysql/mysql.log
#general_log             = 1
#
# Error log - should be very few entries.
#
log_error = /var/log/mysql/error.log
#
# Here you can see queries with especially long duration
slow_query_log_file = /var/log/mysql/mysql-slow.log
slow_query_log      = 1
long_query_time = 10
log_queries_not_using_indexes

Wir haben knapp 140000 Artikel  und ca 2000 Kategorien

 

[Claudiocool]

Und was sagen die logs?

[tenga]

Die Logs sagen garnicht es gibt ja keinen Fehler er macht ja alles sauber durch nur der ist mir zulangsam beim Import.
Laut Server Statistik gibt es kaum Auslastung.

Daher auch so meine Frag in die Runde ob jemand vielleicht ein paar Einstellungsschrauben kennt.
Der Rödelt heute schon beim Import von ca 10 Uhr bis jetzt 1 Durchlauf und ist gerade mal 42800/54720

Es muss doch möglich sein das ding in ein paar Minuten druchzujagen
Wir nutzen den eigenen Prestashop Importer oder gibt es einen der besser und schneller ist.