Hi all!

My company has a workflow right now where 2+ developers may be working on one Wordpress site at the same time. Due to the nature of our setup, we have remote developers as well so we cannot just run a server within the office that everyone can work off, unfortunately.

Currently, to handle this, we have a remote database server that we all connect to via an ssh tunnel that binds to address 127.0.0.0:5555 locally. We then configure our WP Config files to use that address as well as the proper db name, username, password for the remote server.

This does work and allows for a secure connection to the database server, however, the second we start to actually add content, plugins, pages, etc, our page load speeds locally seem to plummet. I’m talking sometimes 10 - 20 seconds for a page to load. These databases aren’t getting large by any means, the largest we are working with is probably 100mb or less.

I’m wondering if anyone has a similar workflow, and has any suggestions on how we could improve this on our end. Should we ditch the SSL tunnel and opt for a different method to allow all of our developers to connect?

Appreciate any help or tips!

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

×
2 answers

Great question @HelloCharlie

It reminds me of pre VM development, however working on a server in production, would not be something I would recommend,

I would say to your developers to setup a local instance of MySQL, you could go one step better and use docker to host and run Docker locally on each developers machines, using docker would make it very easy to keep versions the same as production.

https://www.digitalocean.com/community/tutorials/how-to-install-wordpress-with-docker-compose

Regards

Simon
SnapShooter
DigitalOcean Wordpress Backups SnapShooter

by Kathleen Juell
WordPress is a free and open-source Content Management System (CMS) that is widely used to launch new websites. Running WordPress typically involves installing a LAMP or LEMP stack by hand, work that you can simplify with tools like Docker and Docker Compose. This tutorial will show you how to set up a multi-container WordPress installation with an Nginx reverse proxy. It will also show you how to obtain TLS/SSL certificates for your application domain.
  • Hi @snapshooter

    I appreciate your response!

    We are not actually working off the production database, it’s the initial development version of the database.

    Basically we would just be kicking off a project, and everyone would be connected to the same database. This way we can all be making pages, adding plugins, adding custom fields etc.

    We need to all be working off 1 database to ensure we are all working with the same content, plugins activated etc.

    Cheers!

I would suggest your db issue is a config one. Can you post the contents of your my.cnf config file?

A

  • @andmoo sure thing! to be clear this is my `/etc/mysql/mysql.conf.d/mysqld.cnf/ file contents as the my.cnf was just importing this one.

    [mysqld]
    #
    # * Basic Settings
    #
    user            = mysql
    pid-file        = /var/run/mysqld/mysqld.pid
    socket          = /var/run/mysqld/mysqld.sock
    port            = 3306
    basedir         = /usr
    datadir         = /var/lib/mysql
    tmpdir          = /tmp
    lc-messages-dir = /usr/share/mysql
    skip-external-locking
    skip-name-resolve
    #
    # Instead of skip-networking the default is now to listen only on
    # localhost which is more compatible and is not less secure.
    #bind-address            = 0.0.0.0
    
    #
    # * Fine Tuning
    #
    key_buffer_size         = 512M
    max_allowed_packet      = 16M
    thread_stack            = 192K
    thread_cache_size       = 8
    # This replaces the startup script and checks MyISAM tables if needed
    # the first time they are touched
    myisam-recover-options  = BACKUP
    #max_connections        = 100
    #table_cache            = 64
    #thread_concurrency     = 10
    
    tmp_table_size          = 50M
    table_definition_cache  = 2048
    
    
    #
    # * Query Cache Configuration
    #
    query_cache_limit       = 16M
    query_cache_size        = 0
    
    #
    # * Logging and Replication
    #
    # Both location gets rotated by the cronjob.
    # Be aware that this log type is a performance killer.
    # As of 4.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
    #log_slow_queries       = /var/log/mysql/mysql-slow.log
    #long_query_time = 2
    #log-queries-not-using-indexes
    #
    # The following can be used as easy to replay backup logs or for replication.
    # note: if you are setting up a replication slave, see README.Debian about
    #       other settings you may need to change.
    #server-id              = 1
    #log_bin                        = /var/log/mysql/mysql-bin.log
    expire_logs_days        = 10
    max_binlog_size   = 100M
    #binlog_do_db           = include_database_name
    #binlog_ignore_db       = include_database_name
    #
    # * InnoDB
    innodb_buffer_pool_size      = 1024M
    innodb_log_file_size         = 128M
    innodb_buffer_pool_instances = 1
    
Submit an Answer