WooCommerce Bookings hébergement qui ne vend jamais la même fente deux fois.
La disponibilité est recalculée sur chaque vue du calendrier, et deux personnes peuvent atteindre pour la dernière fente dans la même seconde. Ces deux sont des problèmes d'infrastructure avant qu'ils ne soient des problèmes de plugin.
Tout ce qu'un calendrier de réservation demande à un hôte.
Le calendrier est la chose la plus chère sur le site et la moins cacheable. La pile est configurée autour de cela plutôt que malgré elle.
Calendriers qui chargent pendant que les gens choisissent
La demande de disponibilité est un appel AJAX qui lance une vraie requête sur chaque réservation existante dans la plage. Il est exclu du cache de page et donné PHP tête de séance ainsi le calendrier se remplit immédiatement.
Deux clients, une fente, un gagnant
Checkout écrit sont enveloppés de sorte que la vérification de disponibilité et l'insert de réservation se produisent comme une seule opération verrouillée. Le deuxième client est dit que la fente a disparu plutôt que d'être vendu ainsi.
Recherches de disponibilité tenues en mémoire
Les réservations cachent ses calculs de disponibilité. Conservés dans Redis plutôt que dans le tableau des options, ces recherches cessent de concurrencer les écrits qui créent de nouvelles réservations en même temps.
Réservations en attente qui expirent réellement
Les cales non payées sont libérées par un emploi programmé. Conduit par le système cron il fonctionne à l'heure, de sorte que les fentes ne restent pas bloqués par les commandes abandonnées jusqu'à ce que le prochain visiteur arrive.
Sauvegardes nocturnes du calendrier
Réservations, clients et commandes dans un seul instantané, reproduits hors de l'origine, restituables du tableau de bord sans demander à quiconque de réserver.
Regardez le calendrier, pas le serveur.
Les sites de réservation échouent de manière à ne rien ressembler du tout à rien : une cale qui ne sort jamais, une cron qui s'arrête, un calendrier qui s'est ralenti à mesure que la saison se remplit.
- Connexion admin à un clic, pas de mot de passe partagé
- Temps de réponse au paramètre de disponibilité suivi
- Plugin et mises à jour de base avec statut par article
- Restaurer toute sauvegarde quotidienne depuis le tableau de bord
Un calendrier complet se charge comme un vide.
Le coût de disponibilité augmente avec le nombre de réservations déjà prises, ce qui signifie que le mois le plus occupé de l'année est aussi le plus lent - à moins que les recherches ne soient en mémoire.
Ce que nous changeons pour WooCommerce Bookings
Ceux-ci diffèrent d'un site standard WooCommerce sur le même plan, car un magasin de réservation vend une chose finie que deux personnes peuvent essayer d'acheter simultanément.
| Paramètre | Notre configuration | Pourquoi |
|---|---|---|
| Disponibilité AJAX | Exclus du cache de page et donné PHP worker reserved headroom | Chaque vue de calendrier déclenche une requête en direct dans les réservations existantes dans la gamme, de sorte qu'elle ne peut pas être servie à partir d'un cache et qu'elle ne peut pas être autorisée à faire la file d'attente derrière les requêtes de pages ordinaires pendant qu'un client attend que des dates apparaissent. |
| Disponibilité transitoire | Stocké dans Redis plutôt que dans la table d'options | Réservations écrit sa disponibilité en cache constamment, et garder que curn dans la table des options le met en conflit direct avec les inserts mêmes qui créent de nouvelles réservations. |
| Opérations de paiement | Insert de vérification et de réservation de disponibilité enveloppé dans une transaction à clé unique | Sans une serrure tenue sur les deux marches, deux commandes simultanées peuvent chacune lire la même fente que libre avant d'écrire, et le magasin confirme un rendez-vous qu'il ne peut pas honorer. |
| max_execution_time | Élevé pour les paramètres qui évaluent les grandes plages de dates | Un client qui ouvre une vue de douze mois demande un calcul sur chaque ressource et chaque réservation existante dans cette fenêtre, ce qui est un ordre de grandeur plus de travail que toute autre demande que le site sert. |
| Nettoyage en attente de la réservation | Relâché par le système cron sur un calendrier fixe | Non payé détient bloc de l'inventaire réel, et sous wp-cron ils ne sont libérés que quand un visiteur arrive - donc les heures les plus calmes sont exactement quand les commandes abandonnées garder fentes hors vente le plus long. |
Des tarifs simples et transparents.
Chaque offre comprend la migration gratuite, les sauvegardes quotidiennes, le SSL et l’assistance 24 h/24, 7 j/7.
- 1 site WordPress
- 10 Go de stockage NVMe
- SSL gratuit
- Sauvegardes quotidiennes
- Déploiement en un clic
- Assistance par tickets
- 5 sites WordPress
- 50 Go de stockage NVMe
- SSL gratuit
- Sauvegardes quotidiennes
- Déploiement en un clic
- Assistance prioritaire par tickets
- 20 sites WordPress
- 200 Go de stockage NVMe
- SSL gratuit
- Sauvegardes quotidiennes
- Déploiement en un clic
- Assistance dédiée
Questions fréquentes.
Deux clients peuvent réserver la même fente à la fois?
Pourquoi mon calendrier de réservation prend-il autant de temps à charger?
Puis-je mettre le calendrier derrière une page cache ?
Les réservations non payées se libèrent-elles automatiquement?
Est-ce que cela fonctionne avec Amelia ou Bookly à la place?
Exécutez WooCommerce Bookings sans sur-vente de votre calendrier.
Migration libre, disponibilité qui se charge instantanément, et verrouillage qui se tient à la caisse.